CSBA - Requirements chapter with my diagrams

Skill Category 5 Requirements . .5.1. Business Requirements . .5.1.1. How Requirements are defined .

5.1.1.1. What is a requirement .5.1.1.2. Separating requirements and design .5.1.2. Who Participates in Requirement Definition .5.1.2.1. Business Project Sponsor or Champion .5.1.2.2. Business Stakeholders and Subject Matter Experts (SME) .5.1.2.3. Developers . .5.1.2.4. Testers . .

5.1.2.5. Customers and Suppliers . .5.1.2.6. Business Analysts . . .5.1.3. Attributes of a good requirement . .

5.1.3.1. Correct . . .5.1.3.2. Complete . . . .5.1.3.3. Consistent . . .5.1.3.4. Unambiguous . . . .5.1.3.5. Important . . . .

5.1.3.6. Stable . . . .5.1.3.7. Verifiable . . . .5.1.3.8. Modifiable . . . .5.1.3.9. Traceable . . .

5.2. Processes used to define business requirements . .5.2.1. Joint Application Development (JAD) . . .

5.2.1.1. What is Joint Application Development . . .5.2.1.2. Who participates in Joint Application Development . . . .5.2.1.3. How is Joint Application Development conducted . . .

5.2.2. Business Event Model . . . .5.2.2.1. What is a Business Event Model . . . .5.2.2.2. How is a Business Event Model Created . . . .5.2.2.3. Using the Business Event Model . . . .

5.2.3. Use Cases . . . .5.2.3.1. What is a Use Case . . .5.2.3.2. How Use Cases are Created . . .5.2.3.3. How are Use Cases Applied . . . .5.2.3.4. Considerations for Use Case Usage . .

5.2.4. Process Models . . .5.2.4.1. Data Flow Diagrams (DFD) . . .5.2.4.2. Entity Relationship Diagrams (ERD) . . .5.2.4.3. State Transition Diagrams . . .

5.2.5. Prototyping . . . .5.2.6. Test First . . . .5.3. Quality Requirements . . .

5.3.1. Quality Factors . . . .5.3.1.1. Efficiency . . . . .5.3.1.2. Reliability . . . .5.3.1.3. Availability / Response Time . . .5.3.1.4. Integrity / Security . . .5.3.1.5. Usability . .

5.3.1.6. Maintainability . . . . .5.3.1.7. Flexibility . . . .5.3.1.8. Portability . . . . .5.3.1.9. Reusability . . . . . .5.3.1.10. Interoperability

5.3.2. Relationship of Quality Requirements . . . . .5.3.3. Measuring Business and Quality Requirements . .

5.3.3.1. Minimum Level of Acceptable Quality . .5.3.4. Enterprise Requirements . . .

5.3.4.1. Standardization . . .5.3.4.2. Accessibility . . . .5.3.4.3. Control . .

.5.4. Constraints and Trade-offs . . . .5.4.1. Constraints . . . .

5.4.1.1. Hardware . . . . . . . .5.4.1.2. Software . . . . . . . . .5.4.1.3. Policies, Standards and Procedures . . . . . .5.4.1.4. Resources . . . . . . .5.4.1.5. Internal Environment . . . . . .5.4.1.6. External Environment . . . . .

5.5. Critical Success Factors and Critical Assumptions . . .5.5.1. Critical Success Factors (CSFs) . . . .5.5.2. Critical Assumptions (CA) . . . . . . .

1 Skill 5 Requirements

5.6. Prioritizing Requirements and Quality Function Deployment . .5.6.1. Prioritizing Requirements . . . . .5.6.2. Quality Function Deployment (QFD) . . . .

5.7. Developing Testable Requirements . . . . .5.7.1. Ambiguity Checking . . . . . . . . . . . . . . .

5.7.1.1. What is Ambiguity Checking . . . . . . . . . . . .5.7.1.2. Performing Ambiguity Checking . . . . . . . . . . .

5.7.2. Resolving Requirement Conflicts . . . . . . . . . . . .5.7.3. Reviews . . . . . . 5.7.4. Fagan Inspections . . . . . .

5.7.4.1. Fagan Inspection Process . . . . . .5.7.4.2. Fagan Inspection Participants . . . . . . .5.7.4.3. Fagan Inspection Issues . . . . . . .

5.7.5. Gilb Agile Specification Quality Control . . . .5.7.5.1. Agile Specification Quality Control (SQC) Approach . . . .5.7.5.2. Using Inspection Results . . . . . . . . .5.7.5.3. Agile SCQ Participants . . . . . . .5.7.5.4. Agile SCQ Issues . . . . . . .

5.7.6. Consolidated Inspection Approach . . . . . .5.8. Tracing Requirements . . . .5.8.1. Uniquely Identify All Requirements . . . .5.8.2. From Requirements to Design . . . .

5.8.2.1. Tracing Requirements to Design . . . . . . . .5.8.2.2. Tracing Design to Requirements . . . . . . .

5.8.3. From Requirements to Test . . . . . . .5.8.3.1. Tracing Requirements and Design to Test . . . . . .5.8.3.2. Tracing Test Cases to Design and Requirements . . . . . . .

5.9. Managing Requirements . . . . .5.9.1. Create a known base . . . .5.9.2. Manage Access . . . . .5.9.3. Authorize changes . . . . . . .

5.9.3.1. Change Control Board (CCB) . . . .5.9.3.2. Change Scope: Requirement, Enhancement or New Project . . . .5.9.3.3. Establish priority . . . . . .5.9.3.4. Publish . . . . . .

5.9.4. Control results . . . . . . . .5.9.4.1 Size the effort . . . . . . .5.9.4.2. Adjust the resources or the plan . . . . . . . .5.9.4.3. Communicate . . . . . . . . . . . end


CSBA Skill 5 Topic : Requirements Functional/Business Requirements process is the heart of the software development life cycle, so too the requirements process is the heart of the Software Business Analyst’s job. Business Requirements are what the organization needs to accomplish their purpose.

5.1.1 How Requirements are definedRequirements definition should be a collaborative process, involving all of the stakeholders for a specific project. When performed in this fashion, there is the highest probability that the correct requirements will be identified. As the representation from the stakeholder population decreases, so does the probability that the requirements will be complete and correct. Requirements definition should be an iterative process, in which needs and wants are offered, evaluated, clarified and eventually accepted or rejected by the stakeholders. For small projects, with few requirements, the individual iterations or process cycles will be brief; for larger projects, they may be very time-consuming.The analogy of building a custom home is often used as a construct for building a software system; they contain many of the same issues and challenges. This is the requirements phase.

5.1.1.1 What is a requirement A Requirement is a specific and detailed statement about what a system must do or be.Often the initial statement of what the system must do or be is very high-level. These requirements will then be refined in increasing levels of detail until they are fully understood and agreed to by all the stakeholders.The sum of all of the Business Requirements identified for a specific project must reflect all the functionality desired by the stakeholders.

5.1.1.2 Separating requirements and designDesign is all about how the functionality described in the requirements will be provided. Design includes things like file and table layouts and more commonly screens and reports. Because many of the answers to provisioning Information Technology systems are so well known, they are often incorrectly supplied as requirements.This tendency to begin designing solutions before the problem is fully defined creates a wide range of problems in the attempt to deliver a quality system. It is common to see the need for a specific screen or report identified as a requirement when, in fact, these are solutions to information needs and as such are design.The Business Analyst when confronted with design elements submitted as requirements must begin the task of determining the underlying need. Find out what purpose the information fulfills for the stakeholder. Once the real need is understood, there may be many potential solutions to the problem, of which the one originally submitted as a requirement is only one.Not only do design elements included as requirements rule out other, potentially more effective, solutions; they may also mask a problem which is not properly exploredThis fundamental step in separating requirements and design is often overlooked in the rush to get the requirements and design done, so coding can begin. This emphasis on coding is a trap for the unwary; in the hurry to get there, too many errors and ambiguities are left in the requirements. In traditional Waterfall methodologies, this in turn leads to defects that must be corrected, requiring additional coding time(cost of rework). When working in the Agile methodologies creation of the test cases, prior to the coding will reduce this problem.


5.1.2 Who Participates in Requirement Definition 5.1.2.1 Business Project Sponsor or Champion 5.1.2.2 Business Stakeholders and Subject Matter Experts (SME) 5.1.2.3 Developers 5.1.2.4 Testers 5.1.2.5 Customers and Suppliers 5.1.2.6 BA’s

5.1.2.1 Business Project Sponsor or Champion

The Business Project Sponsor or Champion is the individual with the organizational authority to commit resources to the project and usually is the functional head of the project on the business side. Typically their signature will appear on the initial request to begin the project (other, higher level signatures may also appear depending upon the size and scope of the project.).The Sponsor or Champion is the individual who will make decisions. In most cases this individual fills both the roles: Sponsor and Champion.In a project that is cross-functional, involving several departments and their respective management, the area which originated the request and/or is committing the most resource will become the Project Sponsor. It is not unusual for the role of Sponsor and Champion to be split in this instance, with the Sponsor being somewhat more aloof from the project. Sponsor aloofness from the project is a very serious problem if the Sponsor is frequently inaccessible or unresponsive, the entire project will slow down, unless the Champion has adequate authority. In circumstances like this it is a good idea to determine if the problem is lack of time or lack of interest. Lack of interest in the project should raise warning flags for the entire project team.Occasionally there will be a Champion for the project in another area, because of an especially keen interest in one or more aspects of the project. Project Champions, because of their interest level are very important to the health of the project. Every effort must be made to keep them engaged in the process and to educate them as to the reasons for the emphasis on Requirements Definition.

5.1.2.2 Business Stakeholders and Subject Matter Experts (SME)

Business Stakeholders are other individuals or groups within the organization that have an interest in the project. A typical example is Accounting, which is often a stakeholder; many projects sponsored by Sales or Human Resources have tax implications involving the accounting area. In any project such as this, the Accounting Department is a key stakeholder in the requirements process. They will have significant contributions to make. Excluding themfrom the early stages of the project will result in rework throughout the project.Subject Matter Experts (SMEs) are a very important group of people. Many people know the general outlines of the process flow and the business activities. Then there are those few people who know one or more specific areas in depth. They know the details which cause business processes to fail. Their knowledge is essential to a successful project, so identifying the SMEs early is a critical part of the requirements process.It is not uncommon to find the IT support staff in the position of a SME in regards to the system they support. In some organizations the business units have completely delegated the understanding of automated processes to the IT maintenance team. This is a potential dangerous position for all concerned. Careful scheduling with these individuals is essential as they usually lack time & are busy.

5.1.2.3 Developers

Developers play a crucial role in the requirements definition process. They will be able to articulate the functionality contained in any predecessor system; they may become the SME.They will be able to identify interfacing systems and articulate the requirements for those.They also bring knowledge of how similar business problems have been solved before. While the requirements process is still about what the system needs to do or be, not how to do it; it is useful to know what is easy and what is difficult.Developers will also ask good questions about specifically how things should work. They are excellent at identifying gaps in information that will cause problems later. Having the developers participate in the requirements process has another benefit: they obtain a clear understanding, of what the project is really supposed to accomplish.

5.1.2.4 Testers

Testers bring a unique mind-set to the requirements process; they immediately begin asking “How would I test this.” When the answer to that question is not clear, there is a problem with the requirement. Testers are very analytical and detail oriented. They find things that do not work. In this capacity they lend great strength to the final requirements product. The other benefit to having the Testers involved in the Requirements Definition is ,they Can immediately begin the development of test cases. This helps to spread the testing


workload for the project over a longer period, reducing the resource crunch at the end of the project avoiding inadequate testing.

5.1.2.5 Customers and Suppliers

In this context, customers and suppliers are individuals and organizations external to the developer of the software, it is important to include them in the Requirements Definition process. External customers are especially important in the Requirements Definition process. Many organizations have an internal representation of an external customer; often in the Sales or Marketing Department. However, it is important to remember these individuals are not the actual customer. Their vision of what the customer does and does not want may be influenced by a few very vocal customers, not a representation of the majority. They may unconsciously be filtering important information about product strength and weakness.. Ensure that each customer population is adequately and appropriately represented.

5.1.2.6 Business Analysts

Business Analysts are the core of the Requirements Definition process because they are fluent in both the language of business and the language of technology; they are able to translate for both sides. They know who the SMEs are; they know who the IT support team is; based on their experience with the organization, they usually also know who additional stakeholders might be. With this knowledge they are uniquely positioned to ensure that all ofthe right people participate in the process. They bring the experience gained from previous projects and how functionality and business implications are used optimally.


5.1.3 Attributes of a good requirementNumber of attributes which together define what a “good requirement” is. Attribute Description CCCUISVMT ----- CUM IS CCTVCorrect Correctness includes accuracy. Lack of correctness may be the result of inattention to detail,

failure to step through a calculation or process flow, or merely a typographical error. Complete Incomplete requirements are often half correct. Lack of completeness will lead to missing

functionality and inappropriate system responses. Often lack of completeness is a result of making assumptions about the process, instead of verifying ,the steps, leading to defects and rework

Consistent A requirement must be both internally and externally consistent. That is, it must not contradict itself, and it must not conflict with another requirement. Checking external consistency can be more time consuming & potentially complex but is better than finding resolving defect after testing. Each requirement can be checked against each other requirement to ensure there is no conflict. A matrix structure will work well for this in smaller projects.

Unambiguous The requirement should be stated clearly and concisely, in such a way that one, and only one, interpretation is possible. Where more than one interpretation is possible, there is ambiguity and errors will be inserted in the product. Adoption of a uniform and consistent vocabulary across the organization will greatly reduce the opportunity for these kinds of errors to occur.

Important If the requirement is not important, why are resources being allocated for itTo further aid in ensuring only important requirements are implemented, the final list of requirements should be prioritized from one to n.

Stable Organization and the environment are consistently changing. A good requirement takes that into account. Defining a requirement to interface with a process or system that will be obsolete before the requirement is implemented is not cost effective.

Verifiable How can this requirement be tested? If it is not possible to answer this question, there is still work to be done on the requirement. Some literature refers to this attribute as “testability”. Waiting until the end of the project to determine the requirement is too poorly defined to develop appropriate test cases is not cost effective. Verification includes the ability to perform reviews and inspections of requirements; these can be early life cycle activities which will reduce the total project cost. Requirements Definition process will ensure questions of verifiability are raised early.

Modifiable It is unrealistic to think a system, once written, will not change. It will change; therefore, ensuring the change can be managed successfully is essential. To be modifiable, an item must be defined once, and only once, in the system. If ‘Date’ is to be used, it should be defined with a standard format and all occurrences of ‘Date’ should use that format. Eg tax % should be modifiable from one place and changes should happen at all related locations in code

Traceable Each requirement must be uniquely identifiable so that it can be traced throughout the project. Many organizations choose to use the priority ranking for the identifier, thus making it servetwo purposes. At the end of the design phase, it should be possible to identify where each requirement is implemented in the design. Likewise at the end of the coding stage, it should be possible to trace each element of the code back through the design to the original requirement(s). If there is more than one requirement tied to a specific element of code, all of the requirements must be identified.


5.2 Processes used to define business requirementsRequirements development is a discovery and invention process, not a collection process The difference between the two approaches is enormous. The mistaken idea that requirements are readily available, needing only to be collected or gathered, may be why so many organizations consistently under resource this most essential part of the process. Depending upon the size and complexity of the proposed project, there are a number of available pproaches.

5.2.1 JAD

5.2.1.1 What is Joint Application Development (JAD)The original definition of the JAD from IBM was as a technique for development of business systems requirements. The process includes a significant amount of planning and preparation prior to one or more extended (3 to 5 day) sessions dedicated to defining the requirements. The initial session(s) may be followed by other shorter sessions .JADs can be very time-consuming. This was due in part to the requirement for an external (unbiased) facilitator for the process. Consulting firms, called in to fill this roll, often became involved in the project on a long term basis. The potential high cost, coupled with the time commitment caused many larger organizations to back away from the process in the late 90s, especially as the Agile methodologies emerged but drop in requirements quality has created a renewed interest in the process for mid-sized to large scale projects. For these projects, the time invested in the process will yield significant paybacks. In a study by Capers Jones, a computer industry productivity expert, of the 60 projects he studied, those that did not use JAD missed 35% of the functionality, and that functionality represented almost 50% of the final product code. Those using the JAD process missed less than 10% of the functionality and those items had a minimal impact of the final product code. Developed in the late 1970s by Chuck Morris and Tony Crawford, both of IBM. It was called Joint Application Design (not Development), and was intended to bring IT and the customer together in a structured setting with the intent of obtaining quality requirements

5.2.1.2 Who participates in Joint Application DevelopmentOne difference between a JAD and a typical facilitated session is the number of participants; facilitated session is limited to 10-12 & in JAD especially the early sessions, the number of participants may be as high as 20-22. The specialized roles in a JAD are as follows:FacilitatorOr Session Leader

Chairs the meeting and directs the flow of activities, keeping the participants on track. The facilitator is responsible for identifying issues that need to be addressed. The facilitator traditionally contributes no content to the session.

Project Manager/Leader

This individual is explicitly included in the JAD session. It is essential that they be included in the team developed as a part of the process ,and that they are invested in the decisions that are made. It is equally important they not fill the role of facilitator; this will cause too many role/goal conflicts during the JAD sessions.

Scribe, Modeler, Documentation Specialist.

One or more of these roles will be needed for every session. The Scribe is responsible for capturing the flow of the meeting and all results. A Modeler may be there to support the use of Data Flow and State Transition Models..A Documentation Specialist may be there to speed the translation of decisions into permanent records None of these roles contribute content to the sessions.

Outside Experts Occasionally it may be desirable to include industry, financial, legal, or technology experts in the session to provide information to the participants as an information resource.

Observers - Some organizations choose to include additional members of the development team as non-participant listeners/observers. This is a very difficult role for many individuals.


5.2.1.3 How is Joint Application Development conducted (five phases, & three of those five focus on preparation) Like any facilitated session, good preparation is the key to achieving desired results.


2. Research on Requirements - The facilitator needs to be familiar with any high level requirements that exist, identify (in conjunction with the PM and BA) what the anticipated deliverables are, and what the CSF’s are expected to be. While not all of this information will turn out to be correct, it will create a reasonable context for planning the JAD sessions

3. Prepare for the Session - This includes typical activities for the session as detailed in Facilitated Sessions. One key difference here is that in classical JAD, it is recommended that a full day be planned for team building activities.This is because the projects will have a long life span and need to have the team style communication in place for the duration. Time needs to be set aside for developing a common working vocabulary. Organizations which already have a well understood common language may be able to short-cut, but not eliminate this part of the process. Preparation for the JAD session includes a pre-meeting briefing on the project objectives and limitations, as well as the expected deliverables via conference call if the participants are geographically dispersed. It is important however, they all hear the same thing at the same time to reduce later conflict about who was told what. If a number of information gathering sessions have been held, especially with external customers, it is important to provide that information to the participants in advance, so they will have the opportunity to review and analyze that material.

4. Conduct the Session(s) - The session itself brings participants into a structured, neutral (non-hostile) environment for the purpose of identifying and resolving issues about requirements. Session will have a highly structured agenda, with clear objectives, and includes a mechanism for resolving conflicts and issues. After the initial activities designed to build a collective acceptance of the roles and objectives of the team, there is usually a period for addressing language and communication issues. During this time individuals learn a little about each other’s function in the project and how they will contribute to the final outcome. Only when this has been completed is the group ready to begin the process of identification and refinement of requirements.Approaches that can be used during the process of defining the requirements, from structured or unstructured Brainstorming, to Business Event Models, Use Cases, and various flow diagrams. The process will proceed from the general idea stage to the increasingly specific level of detail needed. Depending upon the size and complexity of the project and the number of constituencies involved (the number of internal business partner areas or the customer segments) the group may need to break into sub-groups to consider some topics in detail.One of the advantages of the JAD process is that it helps to identify ambiguities early as individuals from different backgrounds interpret the suggestions presented .During one or several sessions, requirements will be identified, refined, documented and eventually prioritized for the project. It is not unusual for the team to be tasked with identifying the Critical Success Factors, Critical Assumptions, Project Risks and Risk Responses. At each stage of the process, the facilitator is responsible for ensuring the product(s) being created represent the consensus of the participants and not a vocal minority view. This may entail considerable time spent in negotiation and the construction of acceptable compromises. Because this time and effort is being expended at the “front end” of the project, it is highly visible and this is part of what has created a sometimes negative perception of the JAD process. What is often overlooked is that these issues will arise and will need to be resolved during the life of the project. By addressing these issues at the front end, later and much larger project delays and miscues can be avoided. Not all issues will be quickly and easily resolved. Despite the best efforts of the participants, there may be a need to continue to work on one or more specific items after the conclusion of the JAD sessions. In this case, it is the responsibility of the Facilitator to ensure that the items are followed to their resolution and conclusion. This may entail additional meetings with individuals not originally a part of the JAD process.

5. Prepare and Obtain Approval for Output Documents - There will be a few or many output documents. Each of thesemust be agreed to by the participants and then distributed to the appropriate areas of the organization. In some cases there are also approvals required. Great care and thought needs to be given to the issue of post-process approvals. If someone not in the process has the ability to veto some, or all, of the decisions made by the group it is rendered ineffective. If this happens on a consistent basis, individuals will be unwilling to commit the kind of time and mental energy required to produce a quality product. From an organizational morale and effectiveness position, it is far more productive to identify the acceptable constraints ahead of the JAD session. This can be done as a part of the pre-session planning and communication.

JAD Project Definition - During this part of the process, the facilitator and other members of the team will need to ensure the necessary project origination, scope and authorizations exist. This includes background information about how the project arose. These documents, if they do not exist, must be created before a meaningful session can be conducted. A general understanding of the size and complexity of the project is important in determining how many resources it is reasonable to allocate to this process. The facilitator must also work with others to gather a clear understanding of the organizational and political issues surrounding the project.Additionally, the facilitator in concert with the project manager, the business analyst and the project sponsor will need to

5.2.2 Business Event Model

The focus of the Requirements Definition process is determining the parameters of a business problem and what is needed to address that problem. The Business Analyst may have already participated in the problem definition process and perhaps in an initial Business Process Modeling activity. These both focus on what is. The Business Event Model is an excellent first step in determining what is to be.

The life of any organization contains five kinds of events: 1. Strategic Events - are decisions and activities triggered by the organization’s strategic planners. Help to shape the environment, but are internally generated. A strategic plan event may result in project activity directed toward the customer.2. System Events - are manual and automated stimuli that trigger activity sets within the organization; they originate within the organization. They are invented by the organization to meet perceived needs.3. Regulatory Events - are external to the organization and can be an activity trigger, but they do not come from the customer, and may not impact the customer in any direct way. These may arise at any point during the project, but should be identified as potential events during the risk management activities for the project. 4. Dependent Events - are typically the result of vendor relationships, often the result of outsourcing activities. They trigger responses within the organization, but once again may not directly impact the customer.5. Business Events - are triggered by the true external customer. Organizations exist to fulfil business evnt activity.

5.2.2.1 What is a Business Event ModelThe Business Event Model is a representation, from the ultimate customer’s perspective, of how the process will operate. It is an effective tool for isolating requirements from design, as it does not address at any point how a system satisfies the needs, only what the interaction will be. In this circumstances it is appropriate to think of the customer as the user of the product.Individuals within the organization may be the ultimate customer for a product or it may be someone outside the organization. The Business Event Model is a depiction of what customer will see, hear, feel, experience and/or do.In the example of a proposed purchase event from a ticket kiosk from the point of arrival at the kiosk, the interaction might look as follows: (REFER DIAGRAM FROM CBOK page 5-15 or print whole page and attach) Nothing in the Event Flow addresses where the information is stored, how it is formatted, edited, or presented. Although the introduction indicated this was to be a kiosk based system, there is nothing in the flow of the interaction specified that would prevent this from becoming a Automated Voice Response System (telephone based). It merely addresses the desired customer experience, from the perspective of the customer. In this matter it is more basic than Use Cases, and is often a useful precursor to the development of Use Cases.

5.2.2.2 How is a Business Event Model CreatedA Business Event Model represents collaboration between the Business Partner(s) and Information Technology. The Business Partner understands the functionality they wish to provide to the ultimate customer, and the more literal and detail oriented IT participants ask the “what if” questions, drawing out more details. This process leads to an understanding of alternative paths, options, and the way errors and exceptions will be handled.The process of creating the model is very straight forward. The participants, often with the Business Analyst functioning as a facilitator, begin the discussion of what the proposed product must do or be. The discussion starts at the beginning, with the first customer interaction. (Any Business Process that does not begin with a customer initiated activity is suspect.)“What does the Customer do first?” is the question to ask. After this is described, and written on a white board or poster paper under the Customer column, the discussion moves on to “What happens then?” and that information is posted under the System Response column. As the model is being constructed, it will become clear that steps have been missed or the process began sooner than was originally described. Since no code has been designed or written, making corrections to the flow at this point is easy and cost effective.Sometimes questions will arise that cannot be answered is about what responses or activities are required. These can be flagged for later clarification and included in the final version of the model. These may include legal or regulatory issues about which participants are unclear. The finished model should have a complete view of the interaction from the customer’s (i.e. the user of the product) perspective. It will describe all of the products and services provided to the customer; but at no point does it describe how those products and services are provided. That is design. For smaller systems, the Business Event Model can often be completed in a single session. For larger systems, it may be necessary to have a session for each major “chunk” of functionality. If it is necessary to “chunk it up”, one or more sessions will be needed to perform some consistency 5.2.2.3 Using the Business Event ModelThe Business Event Model should be developed very early in the Requirements Process.


Business Event model provides significant benefits in Requirements Process.• Scope -. Business Event Model begins immediately to define what is in scope and what is not .Things that are in scope are included; things that are out of scope are excluded from the project. Scope management is a project management challenge from the outset. What appears on the Business Event Model may be in scope; everything else is out of scope. In the Ticket Kiosk example, the ticket options listed include Theatre, Symphony, Football and Hockey. Already excluded from scope are Concerts, Sightseeing Excursions and Railway tickets. Functionality to provide those tickets will not be provided in this project. The completed Business Event Model will describe all of the desired functionality from the customer’s perspective.• Acceptance Test Case Development - One of the major challenges facing the Business Analyst is the management of testing resources. Historically this effort has been back-end loaded on the project; little or no involvement in the project until it is time for Acceptance Testing. Then it is a scramble to develop and run all of the necessary test cases in the limited time available. Use of the Business Event Model allows the development of functional test cases very early in the project life cycle. Early development makes some resource leveling possible, moving some activities much earlier in the project. This in turn leads to much better estimates of the testing effort that will be required.Allowing testers to participate with the Business Analyst in the development of the Business Event Model also makes it possible for them to ask the verification questions: How can I test this? How will I know if this is working correctly? This will lead directly to better requirement from the outset.• Use Case Development - Completed Business Event Models provide a jump start on development of Use Cases.

5.2.3 Use Cases was developed by Ivar Jacobson as a part of his work in Object-Oriented (OO) development Cases are intended to be free of technical jargon and devoid of design considerations. They are increasingly assumed to be a fundamental part of the Business Analyst's repertoire.

5.2.3.1 What is a Use CaseA Use Case is a technique for capturing the functional requirements of systems through the interaction between an Actor and the System. The Actor is an individual, group or entity outside the system. One key differentiator between Use Cases and the Business Event Model,is that the only interaction described with the system in the Event Model comes from a person (the customer). In the Use Case, the Actor may include other software systems, hardwarecomponents or other entities. The addition of these actors allows the Use Case to add depth and understanding to what has been simply a customer perspective.Actors can be divided into 2 groups: a primary actor which requires the assistance of the system. A secondary actor is one from which the system requires assistance.The Use Case shares a common focus with the Event Model on the goal of the interaction. It looks at what the Actor is attempting to accomplish through the system. Use Cases provide away to represent the user requirements and must align with the system’s business requirements. Because of the broader definition of the Actor, it is possible to include other parts of the processing stream in Use Case development.Use Cases describe all the tasks that must be performed for the Actor to achieve the desired objective and include all of the desired functionality. To return to the example of the systemdesigned to allow the purchase of tickets at a kiosk, one Use Case will follow a single flow uninterrupted by errors or exceptions from beginning to end.The example below continues with the Kiosk example developed in the Business Event Model. All of the identified options are listed. The actions in italics represent the flow of a single Use Case (for example Shop by Date; Select a Valid Option (Date); Ask Customer Enter Date… ): [for diagram example Refer page 5-19 of CBOK or stick printout of it here]And so on through the completion of the transaction. Where there is more than one valid path through the system, each valid path is often termed a scenario.

5.2.3.2 How Use Cases are CreatedUse Cases are created as a part of the Requirements Definition process and to provide a graphic representation . For small projects with little complexity, the Business Analyst may move directly to the creation of Use Cases, bypassing the Business Event Model. Use Cases can be developed as part of JAD process ,or any sound development method.Each Use Case is uniquely identified. Wiegers recommends usage of the Verb-Noun syntax for clarity. The Use Case above would be Purchase Tickets. An alternative flow (and UseCase) that addresses use of the Cancel Option at any point might be captioned Cancel Transaction.. In addition to the main flow of a process, Use Cases models can reflect the existence of alternative flows by the use of the following three conventions:1. <<extend>> extends the normal course, inserts another Use Case that defines an alternative path. For example, a path might exist which allows the customer to simply see what is available without making a purchase. This could be referred to as Check Availability.


2. <<include>> is a Use Case that defines common functionality shared by other Use Cases. Process Credit Card Payment might be included as a common function if it is used elsewhere.3. Exceptions are conditions that result in the task not being successfully completed. In case above, Option Not Available could result in no ticket purchase. In some cases it may be developed as special type of alternative path.

The initial development of the Use Case may be very simple and lacking in detail. One of the advantages of the Use Case is that it can evolve and develop over the life of the project.Because they can grow and change Use Cases for large projects may be classified as follows:• Essential Use Case - is described in technology free terminology and describes the business process in the language of the Actor; it includes the goal or object information. This initial business case will describe a process that has value to the Actor and describes what the process does.• System Use Case - are at a lower level of detail and describe what the system does ;it will specify the input data and the expected data results. The system Use Case will describe how the Actor and the system interact, not just what the objective is.. The general requirements for items to be included are:• Use Case Name • Summary Description • Trigger • Basic Course of Events• Alternative Events • Business Rules • Notes • Author and Date

5.2.3.3 How are Use Cases appliedUse Cases are an excellent requirements definition tool, because of their flexibility and the vision they provide into the functionality needed by the customer. They take the information derived from the Business Event Model and add more detail and greater understanding of what will be involved.Using the Kiosk example above, it becomes clear this process will require access to many kinds of information from multiple sources. Although no design decisions are ready to be made about how to access that data, the req to do so is obvious. A quick survey of entertainment purveyors (the source of the tickets) may reveal that while hockey, theatre and symphony tickets are readily accessible, football ticket are not. This may lead to a change in scope to exclude football tickets or in an upward revision of the time and cost estimates for achieving that functionality.Likewise, the Use Case provides an excellent entrée into the testing effort, to such an extent that for many organizations, the benefits of Use Cases for requirements are ignored in the effort to jump start testing! When Use Cases are the foundation of the testing effort, some additional information will need to be added to the template:

• Pre Conditions• Post Conditions• Iteration Number, Date and Author

Although Pre and Post Condition information is fairly clear, Iteration may require a little explanation. As the Use Case evolves from a purely Business Event focus to include more system information, it may be desirable to maintain several versions or levels of the Use Case.For example the initial Use Case, developed during the first JAD session(s), might be Iteration 1; as it is expanded to include systems information, it becomes Iteration 2 and when fully configured to include the remaining testing related information it is Iteration 3. Use of common Iteration levels across projects will reduce confusion and aid applicability of the Use Case.


5.2.3.4 Considerations for Use Case UsageIt is essential to remember that the development of Use Cases, in and of themselves, is not enough to ensure the organization is effectively defining good requirements. It is perfectly possible to write any number of Use Cases that, in fact, do not address the real requirements! The most common cause of this problem is, in the rush to begin design and coding, the failure to rigorously include the true customer in the requirements process. While the development of appropriate Use Cases will aid in understanding the requirements, it is possible to develop far too many, wasting valuable time and effort. Some organizations assign priority rankings to Use Cases to help maintain the focus on what is truly important.Screen and Report layouts and Data Dictionary Definitions are not part of requirements and that is design.


5.2.4 Process Models (Data Flow Diagrams, Entity Relationship Diagrams (ERD) ,State transition diagrams)Process models provide the Business Analyst with focused views into the requirements & provides additional insight about what the system must do .Because the process models are not intuitively obvious to many business people, many IT organizations simply do not share them. This of course will lead to requirements defects whenFew assumptions are made about some aspect of the process. Taking the time and effort to make the business partner comfortable with the models, the process for developing them, is job of a skilled Business Analysts. The models presented here vary in the level of technical detail and applicability to specific projects. The Business Analyst will want to choose those models which are best suited to the project at hand. They are presented in increasingly levels of complexity and detail. This is often, sequence in which they are developed.

5.2.4.1 Data Flow Diagrams (DFD)A Data Flow Diagram (DFD) is a process-oriented graphical representation of an application system .The data flow diagram represents the path of data (information) through a process or function .It shows external sources of data, the activities that transform data & where data comes to rest. DFDs is part of ensuring requirements are verifiable.Data Flow Diagrams are generally developed sequential, or “top down” much like peeling away layers of an onionThe symbolism generally used for DFDs is as follows:

Processes - are represented by circles showing processes that use data. They modify the inputs of the process to create desired outputs. Some outputs are temporary and transient, others will be permanent. The verb-noun syntax is once again recommended for use. Developing an index of names will help to ensure that name’s stay unique

Accounting Dept

External Entities or Process Terminators - are represented by rectangles. A terminator is a external entities outside the control of the system being modeled . Terminators represent where the Information comes from and where it is going to. In developing the requirements, it is not necessary to understand why the data is needed; only that it is needed. Analogous to Actors in Use Cases. It can also be another system with which system will communicate

StoresData Stores - are represented by parallel lines; these are places where data comes to rest. When creating the initial DFD, no effort is made to identify how the data is stored; this is a design issue and will be addressed later in the SDLC. Sufficient at this point is to identify that certain types of data must be stored for some period of time. That time period is often unknown in the early stages of requirements definition. Flows - arrows show the movement of data from point to point through the system.

Data Elements - Labels on arrows represent data elements; may be single element or packet.


Generate Invoice Report

Three general types of DFDs:

• Context Diagrams - defines and validates scope of the project; what is diagrammed is in scope, what is excluded is out of scope. Data represented at Context level always originates & terminates outside the scope of the project. Good practice recommends 10 or fewer data store, terminator and process elements be contained in any one DFD.

• N Level Diagrams - these decompose the context level diagram into finer levels of detail. Each DFD addresses a sub process; levels are counted down. The lowest level of detail is the zero level. Large processes may decompose into four or more levels. Smaller projects may only have one or two.• Action Level Diagrams - are the graphic and textual description of the logic used by a process to convert inputs to outputs. It ties data models to process models. As apart of this analysis, specific calculations and processing, not initially visible, will be identified as requirements.

Ed Yourdan, a pioneer in structured analysis, suggests a less intensive approach(Event Partitioning Approach) may work well with many projects. He recommends the following four step approach:1. A list of all events is made2. For each event, a process is constructed3. Each process is linked (with incoming data flows) directly with other processes or via data stores so that it has enough information to respond to a given event.4. The reaction of each process to a given event is modeled by an outgoing data flow.For the Business Analyst, the creation of the DFD serves two purposes; it refines and clarifies the requirements about how various information flows occur and it provides opportunity for the early development of test cases

5.2.4.2 Entity Relationship Diagrams (ERD)Entity relationship diagrams offer the opportunity to create a more detailed view of what is happening with the data. While DFDs are about how the data moves, ERDs are about how data relate to each other. ERDs are initially created during the Requirements phase ,but will continue into design. In requirements, they are about logical entities; in design those entities will become physical.

Like DFDs there are a number of approaches to the diagramming schemes but most have some symbols in common:

• Entities - are represented by Rectangles. An entity is a noun; a discrete object; a person, place or thing. Entities may represent a single item or a group of items. A data store may appear as an entity or as an actor. Ticket Requester (a person) and Ticket Request (a data flow) may both be entities. It is in the role of data, data elements, and data stores that entities are of prime importance in the ERD. Until this point in the Requirements process, the details about data have been fairly general. Now it is necessary to understand exactly what pieces of information are needed and how they relate to each other.


EntitiyRelationshipAttribute

• Attributes of an Entity - are represented by Ovals. A Ticket has Date, Time, Location and Price attributes. Each attribute of an entity is connected to the entity by a line. Related attributed may be joined by a single line which is then connected to the entity. For example, a ticket might also have an attribute of Color, which could be unrelated to the first four attributes. Color would have a separate line connector to the entity, Ticket• Relationships - are represented by Diamonds. Relationships are verbs, phrased in the active tense; moving, tracking, buying (or moves, tracks, buys). Relationships connect entities to each other: a Ticket Requestor (an entity) Placing (a relationship),a Ticket Request (an entity).Relationships are further described in terms of multiplicity; that is how many of each entity are a part of the relationship. There are four basic relationships types:One to one:

A B

The above is the most basic relationship; it is read as a One-to-one Relationship.The symbol means that for every item in entity A, there is one and only one item inentity B. If these entities will eventually become databases, there will be only onerow in A for every row in B and vice-versa. Notice that this one symbol reflectswhat is occurring at each end of the relationship. In this one instance, therelationship is the same for A to B and for B to A. One-to-one relationships are notcommon in most applications, although they do occur.

One to zero or one:

a b

The second relationship is both more common and more complex. The left end ofthe line, nearer the letter A, reflects the relationship of B to A. In this case eachitem in B is uniquely related to one, and only one, item in A. Reading the symbolsat the right end of the line, near the letter B, A is uniquely related to either 0 or1 item in B. If the circle were at the other end of the line, the meanings would be reversed.

One to many:

A B

The crows-foot, at right end of the line, symbolizes many. This relationship can be read as one item in A is related to one or more (perhaps many) items in B, but not zero items. Each item in B however is only related to one item in A. Clearly this relationship can be reversed. What is not allowed are many-to-many relationships. Where a many-to-many relationship appears, it must be broken down into finer detail. It would be possible to have a null value symbol at the A end of the line, indicating that there might be no match in A for some items in B.

One to zero or many:A B

The fourth symbol set allows for the possibility an item in A may relate to none ormany items in B. Each item in B however, must still have a relationship with anitem in A. This flow also can be reversed.

Sample ERD diagram below for exam purpose

5.2.4.3 State Transition Diagrams (STD)State Transition Diagrams provide a representation of all states in which an object may exist during a process. They also include a representation of how the process is initiated, limits the parameters which control the execution of the process, and how the process can be terminated.While many of these issues have been hinted


at in other requirements definition processes,nowhere are they made this explicit. Because they do require a consideration of limits on the process, previously unidentified business rules are often identified during the creation of the STD.As with the DFD and the ERD, the STD has a standard set of symbols which are used to describe the process.

• States - Rectangles with rounded corners are used to represent a state in which the object may exist. A single object may exist in multiple states within a single process, but may only be in one state at any specific point in time. It must be possible to determine how an object arrives at that state and what causes it to move to another state• Transitions - from one state to another are shown using arrows. Transitions connect state pairs to reflect allowed moves from one state to another. A single state may pair with multiple other states in a predetermined sequence• Causes - labels on arrows are causes. These causes are the conditions that must exist for an object to move from one state to another.• Guards on the process - are shown as rectangles. These are the rules that must be satisfied for a move (state change) to be allowed

/ /

• Actions taken in response to state change - are represented as slashes. A single state change may generate multiple actions.

Figure 5-6 State Transition DiagramTransitions are often troublesome in design and construction. Effective use of the State Transition Diagram will help identify issues much earlier in the process. Returning to the Kiosk example, notice in Figure 5-6 the guard box ‘No Activity for 90 Seconds’. This is a business rule that did not surface in earlier discussions. For the Business Analyst and the Tester, these are key areas to focus on when planning the Acceptance Testing Effort

5.2.5 PrototypingA prototype is a non-operational representation of a process or system. Once it is built and has served its intended purpose, it will be thrown away. For larger projects, the development of a prototype may be very cost effective as a means of identifying requirements. With the rapid prototyping tools available, customers and business partners can be shown a representation of the system that will give them much better insight into what the finished product might be.Many people in the Business community understand prototyping, however, it is always wise to preface the use or display of a prototype with the warning that this is not, and cannot be a production product. The analogy of an architect’s scale model is an apt one, the building is made of cardboard and glue, not bricks and mortar. Use of the term prototype instead of model will help in making the distinction; after all one can purchase and use a model home or the floor model of a car. It may take time and effort, but it can be done. There is no corollary for prototype


Guards on processes are shown as rectangles

State Rectangles with rounded corners are used to represent a state

Transitions - from one state to another are shown using arrows. Causes - labels on arrows are causes.

5.2.6 Test FirstMany of the techniques above grew out of the Object Oriented Methodology. Test First is a foundation of the so-called Agile Technologies, the best known of these is Extreme Programming or XP10. These approaches focus on delivering high quality products to customers in fast increments. The approach to Requirements is to focus on how it can be tested, and to develop and execute those tests before any code is written. Those tests then become a part of the overall test suite, first at the unit level and later at the systems level.This process can be especially beneficial when working on an existing system. By creating and running the test cases before the new code is written, developers will have a much clearer understanding of what will need to be changed for the new system to work correctly. This process of changing the old code to work correctly in the new context, before installing new code is called refactoring, and is a key step in delivering quality products.

5.3 Quality Requirements Business Requirements are not the entire story, there are other things to be considered. The Business Analyst must understand how well the system must perform (quality factors) and the issues that restrict the project activities (constraints). Without a full understanding of 2 areas, the best of business requirements will remain unsuccessful.

5.3.1 Quality Factors ( MICE UR FIRT)Quality Factors or Quality Requirements deal with how a system or application will perform.In some organizations these are referred to as Technical Requirements, either term is acceptable; it is the concept of Quality Requirements that is essential. According to Tom Gilb, more systems fail because of Quality Factors than for any other reason.

Quality Attributes for an Information System ( for details Refer CBOK CSBA pg 5-31)

Correctness: Level of compliance with the requirements specifications and customer needs. Metrics for correctness: No. of Defects/Bugs, No. of Missed Requirements, No. of Customer

Complaints Reliability: Period for which a product works with required accuracy; simply saying, it is the extent to

which we can depend on the product Metrics for Reliability: Mean Time Between Failures, Mean Time To Repair

Efficiency: In case of software, amount of software resources or code required to build the product Metrics for efficiency: No. of Computer resources required for the product; No. of Source Lines of

Code required to achieve a particular functionality Integrity: Level of security which can prevent unauthorized access to the data or software

Metrics for Integrity: No. of virus attacks vs. No. of times firewall is broken Usability: In many cases where excellent functionality is built in the products, but users just because

they cannot understand how to use it ? Usability is defined as the effort required learning and operating a product or program.

Metrics: Time taken to learn and operate a new product Maintainability: Many of the production support engineers might have seen that poorly documented

code is difficult to maintain. That means, Maintainability is the time required to find and fix a bug in the product

Metrics: Time to locate and fix a bug in an operational program Testability: Time required to test a product

Metrics: Testing Time Flexibility: Ease with which a program can be modified to suit the requirements

Metrics: Time to modify a program Reusability: Extent to which a program or a product component can be reused in other product

Metrics: No. of times a program is reused Interoperability: Effort needed to merge two systems or products

Metrics: Time to couple two or more products or systems Availability / Response Time : The extent to which a system or program is functionally accessible by

those intended to use it. Sometimes multi-second response time from one screen to the next can also create issues.

5.3.2 Relationship of Quality Requirements


Not all of the Quality Factors interact well. The effort to make programs more efficient will impede efforts to make them highly usable and easily maintainable.The matrix below demonstrates the general relationship among some of the Quality Requirements. The attempt to maximize efficiency will have a negative impact on all of the other attributes in this matrix. Some of the conflicts can be easily resolved; others are more difficult.

The issues with Integrity and Security are difficult. It is essential that Usability, Maintainability, and Response Time all be maintained for those who should have access. Differentiating those who should have access from those who should not takes resources. Determining precisely what level of access is allowed for each authorized individual takes more resources. The need to stay one step ahead of determined and creative hackers means that efforts do not stop with implementation, so maintainability must not only begin high, it must stay that way.In addition, attention to the issues presented by the Quality Factors must occur well in advance of the time when the impact can be seen. The resources are consumed early and often the benefits show up late. There is an enormous temptation to short change the early expenditure to save time and money. The negative impact will be correspondingly greater if this happens. Testability is a necessary attribute of all aspects of al l requirements.

5.3.3 Measuring Business and Quality Requirements


Commonly overlooked aspects of the Requirements Definition process is the need to be able to measure the result. For most Business Requirements, the measure is binary i.e requirement is either present or absent; the flag is on or off; the field is highlighted or it is not;t he calculation is correct or it is not, and so on. While the scenario route to any specific requirement may be long and complex, certain states may only be able to be achieved after multiple interactions, but the end result is either positive or negative.Quality or technical requirements are generally measured on an analogue scale; this means that there are a range of possible values. Some parts of that range may be acceptable and other parts may not. It is essential to clearly identify how the requirement will be measured. Eg Availability and Response Time Requirements begin by looking like this:

• Availability - The system will be available 99.5% of the time, measured monthly.• Response Time - The system will provide sub-second response time between screens 94% of the time, 1 to 3 seconds not more than 5% of the time. 100% of between screen response times will be less than 6 seconds. This may seem like a reasonable and achievable requirement, but it lacks the necessary clarity and definition. Where will this be measured? At the server? At the desktop? A remote laptop? The impact of that difference is clear. The measure must be clear also.

• Availability - The system will be available 99.5% of the time, measured monthly, at the server.• Response Time - The system will provide sub-second response time between screens 94% of the time, 1 to 3 seconds not more than 5% of the time. 100% of between screen response times will be less than 6 seconds, measured at the server.

While this will help the operations and network staff to understand their requirement, it does not provide the person using the desktop or the laptop with a clear expectation of what they will experience.• Availability - The system will be available 99.5% of the time, measured monthly, measured at the server. The system will be unavailable from 2:00 a.m. until 2:30 a.m., the first Sunday of each month for routine maintenance. The system will be available 98.5% for desktop and locally connected laptop users at the Main Office, measured monthly. The system will be available 99.9% of the time between 6 a.m. Monday morning and 9 p.m. Friday night for all other authorized users, measured monthly.This expanded description of what is required in terms of Availability clarifies exactly what will happen.

5.3.3.1 Minimum Level of Acceptable QualityQuality Requirements measures clearly identify what the external customer or the business partner wants and needs. But what happens if IT does not think they can deliver that level of quality, or at least not initially? Does the project stop? Does IT agree, knowing full well they cannot deliver?The answer is provided by Tom Gilb by development of the Minimum Level of Acceptable Quality, will address the issue. This is the lowest possible performance by the system that will allow it to be useful to the intended customer. Below this level of performance, the system has no value.

Quality Requirement must always include the Minimum Level of Acceptable Performance as part of measurement description. This then allows the Quality Requirement to specify what the customer actually wants and also what they are willing to accept.

This will provide IT the opportunity to talk about the relative cost of achieving alternative levels of performance. Those costs may be staff time, hardware resources, or schedule impact to other projects .It will also provide the customer or partner the opportunity to talk about the relative value of achieving alternative levels of performance. Those values may include increased revenue, reduced expenses & customer satisfaction.The result of this dialogue is often a staggered implementation of the Quality Requirement; initial implementation at or near the minimum level of performance and progressing over a specified period of time to the desired level. This approach makes clear what costs and benefits are associated with that level, so reasonable business decisions can be made and everyone will know how and why.

5.3.4 Enterprise Requirements


Each Business Unit operates under the larger umbrella of the organization or enterprise as a whole. The Business Units develop strategies and tactics to support the organizational vision and mission. Just as the individual business unit plans and projects must fit within the overall plan, so too must the requirements fit within the enterprise umbrella. Often Enterprise Requirements are defined and embedded in the IT Standards and Procedures Documentation ;in that way each project can simply refer to that section of the Standards and Procedures toincorporate those Requirements. Enterprise requirements apply to all projects, regardless of size or intent;

5.3.4.1 Standardization Standardization addresses such things as how and where ( “common look and feel” )organization logos will be used, required language(s) and acceptable images. While some of the standardization issues fall within design, such as where controls will be placed on screens, there are others which are strictly requirements.It is easy to assume that “everyone knows that,” but failure to explicitly include references to those standards may result in significant embarrassment for the project team. This is particularly important when working in a multi-cultural, multi-national environment, where some words, references or images may be offensive to parts of the organization not represented on the requirements team.Standardization is not simply a negative, it is also about who the organization is and how they wish to be portrayed. Managing that image through their system representation is very important.

5.3.4.2 AccessibilityAs computer technology evolves, individuals once excluded from participation due to physical limitations are increasingly part of the business and customer base. The requirement to address those aspects that limit participation is increasingly common. A number of governments have created accessibility standards for their own systems which are rapidly being adopted by private enterprise.The visually impaired may need to be provided with voice recognition capabilities that will allow them to talk to a system, paired with reader capabilities that provide choices verbally rather than visually. For egThe hearing impaired may need visual error clues instead of the standard beeps & may need text transcription to provide access to dialogues. The mobility impaired may need to be provided with alternative interface to commands instead of a mouse or keyboard. Each of these sets of requirements must be articulated beforehand.

5.3.4.3 ControlAppropriate controls are important from the business perspective. This need must be translated into effective system requirements. Compliance with various national legislation on the control of financial transactions is a significant part of the process. While in some countries (U.K. for example), compliance is optional, the choice not to comply must be explained, which results in few organizations electing non-compliance. Explicit statements about controls in the requirements document will ensure that those controls are properly designed into the system.

5.4 Constraints and Trade-offs


5.4.1 ConstraintsA constraint is anything that places a limit on what is possible. For IT projects, some of the constraints are constant, others change with the project. To place the requirements in the proper context, it is essential to identify the constraints and fully describe them before entering Design. 6 common CONSTRAINTS

Hardware Software Policies ,Standards , Procedures

Resources Internal Environment

External Environment

5.4.1.1 HardwareEg the amount and capacity of available servers; desktop/laptop capabilities; internal and external network capacity and data storage resources issues to name a few. Will the proposed system run on the existing hardware platform; is the proposed hardware platform capable of performing the desired functionality; does hardware to meet the requirements exist or must it be created? For each project some sub-set of these issues and others like them will need to be addressed during requirements.5.4.1.2 SoftwareSoftware constraints include the current and proposed operating system environment, the interoperability of multiple products and multiple operating systems; the need to interface with existing applications and to anticipate the arrival of new applications. Software constraints may also include required or prohibited languages and tools. Each of these will impose limitations on the final design solution.

5.4.1.3 Policies, Standards and ProceduresEach of these contributes to the structure that describes what can and cannot be done in IT and the wider organization. These may support or prohibit changes to the standard hardware and software platform; they may require or forbid specific development methodologies; they may support or exclude the inclusion of the business partner and the external customer in the development process; may encourage or ignore quality consideration.

5.4.1.4 ResourcesThis is usually what is mentioned first when the question of constraints arises. The classic duo of schedule and budget are at the top of the resource constraint list for many organizations. How many people can we have, for how long? How experienced are they? Will we have the right number of people, but with the wrong skills? Do we get to choose? What is the budget for the project, and who is in control of it? How are schedule and budget managed? Are they inflexible and arbitrary, or realistic and negotiable? As emotionally fraught as these issues are, it is essential to know the answers to these questions during requirements. They will have an enormous impact on what is a realistic set of finished requirements.

5.4.1.5 Internal EnvironmentThis addresses many issues that IT often tries to ignore: especially organizational politics. This includes as consideration of who is the project sponsor and how important is this project to them and the organization as a whole. It also includes taking cognizance of the wider issues, is the organization making money or losing it? Is there a stable, collegial environment or are shakeups and reorganizations a fact of life? What do these issues have to do with requirements? Everything! Unstable, volatile environments suggest that smaller, less risky, requirement sets might be delivered quickly, before the rules change. A more stable and supportive environment makes larger and more complex requirements set a realistic possibility.5.4.1.6 External EnvironmentThis addresses issues that originate outside the organization, but that are still important to the project. Typically included in this set of constraints are local and national legislation, either currently in force or impending; it may also include industry standards. There may be a need to interface with a dominant supplier or customer, in which case their requirements are also project requirements. The economy as a whole may be significant to the project: is there a small window of opportunity that only the nimble will be able to exploit? Are there local, national or international implications for the product? If so, each of those must be separately addressed during requirements to ensure that unwarranted conclusions are not drawn.

5.5 Critical Success Factors and Critical Assumptions


As the Requirements Definition process is being conducted, it becomes apparent not all requirements are created equal; some are much more important than others. Some are so important to the project that if they are not properly implemented, the project cannot be considered a success. There are other things, important to the success of the project, that are outside the control of the organization. All of these sets of information must be consideredwhen creating the finished requirement set.

5.5.1 Critical Success Factors (CSFs) are those factors within the control of the organization and essential to a successful project. Important element of the finished Feasibility Study. CSFs must meet all of the criteriafor good goals and objectives (Specific, Measurable, Assignable, Realistic and Time-Oriented.)

Without an effective definition of what constitutes a successful project, the team may continue to churn endlessly on trivial items. By clearly agreeing up front, during the Requirements Definition process, what it takes to “succeed,” everyone is both focused on the right things and knows when they have achieved them. Failure to define success early can create strong motivation for scope creep and make control of the project much more difficult.

The number of Critical Success Factors will vary with the size of the project, but should never be large. A small project may have one or two. Larger projects may have three to five, per delivery. Creating larger lists of CSFs for projects merely diverts the attention of the project team from what is truly important. When everything is critical, nothing is critical. This is often a difficult process for the team as they must whittle down the list of the important things to the truly essential ones. Applying techniques such as multi-voting followed by the Forced Choiceprocess will help to reduce the number of Critical Success Factors down to those that are truly critical.

Items that are not Critical Success Factors may still operate as important requirements and/or constraints for the project. Critical Success Factors should be clearly and directly linked to the Business Problem that was the originating reason for the project, and so, directly linked to the organization’s customers. Critical Success Factors that have no significance for the customer base must be scrutinized carefully to determine what purpose they serve. Occasionally, compliance with some local or national regulation will become a CSF. Failure to comply may well jeopardize the organization’s ability to serve the customer or to effectively serve the customer.Development of the project’s CSFs will help to focus the team’s attention on those things which must get accomplished. Requirements that do not support these items will have a lower priority, even though they may still be very important.

The weaker the link to the CSFs, the lower the priority will be. Some of the very lowest priority items may need to be dropped, either temporarily or permanently. They will become out of scope for the current delivery.

An example of project CSFs would be:• Required Functionality: the minimum delivered functionality will include the Sales and Inventory functions as described in Requirements 1 through 4, 8 and 9.• Required Locations: the product will be implemented in all of the EUC locations except France on or before 1 January, 20xx. Requirements 5, 7 and 12.• Required Availability: the system will be available 99.5% of the standard normal business week, as locally described, measured at the remote locations within 90 days of implementation. 90% availability as described above is the Minimum Acceptable Level of Performance for Implementation. Requirements 6 and 15. Notice the clear traceability of the CSFs to the project requirements. What is also clear is that they are tied to the most important requirements. If these criteria are met, the project is a success; otherwise, it is not. Creating reasonable CSFs will keep the team energized to achieving them.

5.5.2 Critical Assumptions (CA)Critical Assumptions are key factors for the project that are outside the control of the project team and they can make or break the project. CAs should always be complete with recommended mitigating tactics or risk responses.

The discussion about Critical Assumptions is an evolutionary one; the initial focus will be on what could jeopardize the success of the project. Many of these potential risks are within control of the organization. They can be managed using various risk techniques .Making this list as early as possible in the Requirements Definition process allows information about the CA to be collected and assessed in a structured fashion. Any project with a lengthy list of Critical Assumptions should be carefully appraised. Is the organization willing to expend the resources required on a project with this many issues outside their control?


Once the list of risks has been created, and those within control of the organization eliminated, the remainder must be scrutinized to determine how great a risk they pose to the project. Only those few, which could actually cause the project to fail, should become critical assumptions.

For example, an organization that develops Accounting Software might have the following:Critical Assumption - No substantial changes to the IRC (Internal Revenue Code) provisions for the Not-For-Profit Sector, that are required to be effective on or before the product delivery date, and that have not already been proposed, will be enacted after the final design is approved and the test cases written, but before the scheduleddelivery date.Response: In the event that this does occur, a statistical analysis of the customer base will be conducted. If the change will have a significant impact on less than 20% of the customer base, it will be deferred to the next release. If the change will impact 20% or more of the customer base, it will be added to the current phase.An estimate will be prepared for the new requirements. If the estimate will require 80 Standard Work Days (SWD) or less, additional resources will be acquired toperform the work and the date will not change. If more than 80 SWD are required, the delivery date will be changed.

In reviewing this example, there are several items of note. The window of opportunity for this event to occur has been very narrowly defined. The organization has identified the risk of changes, but has determined changes proposed prior to specific point in process can be accommodated.They have also identified an escalating series of responses, depending upon the severity of the impact.1. If the impact is not significant to customers, it will be deferred.2. If the impact is significant, but only to a small segment of customers, it will be deferred.3. If the impact is significant to a larger number of customers, it will be included in the current product.4. If the size of the change is not too large, resources will be added and the date held constant.5. Finally if the size of the change is large, the date will be moved.As with the Critical Success Factors, identifying the responses during the Requirements Process allows participants to address the issues logically rather than emotionally. Waiting until the last minute to decide what to do is always the most expensive option. A second consideration is that under pressure to do something now the necessary time to research alternatives and come up with the correct response may not be taken. This may result in a response that is inappropriate, ineffective or inefficient. Finally, experience shows that obtaining the needed approvals for the resources to address risks is often a time consuming process. Results in delays to the schedule & cost overruns.

5.6 Prioritizing Requirements and Quality Function DeploymentPrioritizing allows the most important items to be delivered first. It provides the framework for effective decision making about what to include in a project, and when to include it. The time spent in prioritizing requirements will be saved later in the project, when hard decisions must be made. One of the early situations is the sizing of the project or the initial delivery of the project. Based upon the priority and time estimates for development, it ispossible to optimize the functionality delivered using the resources available. With a complete listing of priorities, the answer is simple, look at the lower ranking items first. The alternative scenario is a “group ranking” such as ABC or High, Medium, Low. Realistically things that a ranked as C or Low rarely make it into the product. So the decisionmakers are faced with choosing among things that are all important. Often there is pressure to make a decision quickly because time is an issue; the result is often not the best choice.

5.6.1 Prioritizing RequirementsThe Requirements process does not end with the identification of all of the Requirements. Not all of those definedwill actually be used, or at least not immediately. The question is then how to decide which to choose..Two methods for developing consensus around a list of priorities: multi-voting and forced choice.The Business Analyst will need to be very comfortable with both of those methods.Sometimes there is additional work to be done in preparation for the use of those two tools.When working with multiple stakeholders, it is worthwhile to have each stakeholder go through a mini-prioritization process. This should include all of the common function requirements that will support all of the stakeholders plus the stakeholder specific requirements. During this session, it is important to maintain focus on the importance ofachieving the overall business objectives. This will help the individual groups to recognize the importance of the common functionality.At this point also it is worthwhile to talk about meaningful “chunks” of functionality, as opposed to entire processes. The goal here is to help each stakeholder group begin to develop realistic expectations about what they might be able to get in the new system and when that might be feasible. Doing this internally ,will allow


some grumbling about the need to share resources, without having to fight with another organization for those resources at the same time.Defining the functionality chunks can be a challenge. One approach to this problem is to use the Affinity Diagram process described in. Allow the participants to group the requirements into related sets, give the sets a working title, then determine the relative importance of each functional set. When working with multiple groups,the Business Analyst will want to maintain a working list of titles so there is no duplication or conflict.Once each of the stakeholder groups have completed this step, they can be brought together to begin the process of creating a consolidated list. Depending upon the size and complexity of the proposed system it may be worthwhile to extract the common functionality requirements and prioritize those first. As each group has already done some internal evaluation, this can provide a useful benchmark.

When the Affinity Group process has been used, it may be necessary to do a reconciliation of the items included in the sets. The objective is to have the sets consistently defined. Some items may need to be dropped out of a set. ‘Homes’ will need to be found for these requirements so they do not become lost.If there are multiple stakeholders, with different agendas, it will be necessary to ensure each group is appropriately represented in the multi-voting process. Failure to do this may result in one or two groups “packing the room” (that is, having more than their representative share or participants) to ensure their agenda prevails. If this has not been addressed in advance, it will be necessary for the Business Analyst to ask each stakeholder group who their “votingrepresentative” is. This will allow control of the process to be retained. Representation should be based upon what each group has at stake; in some organization it is possible to do this on a budgetary basis.

The end result of the prioritization process should be a list of requirements, numbered from 1to N. Each stakeholder should sign the finished list as confirmation they have been part of the decision-making process. Each requirement is a discrete entity that can be addressed independently. This final list will become the source control for all future discussions of requirements. The paper copy, with signatures, should be maintained securely for the life of the project. Electronic copies should be created for future use and stored with the appropriate amount of access control.Failure to go through a process like this, even though it can be difficult and time-consuming ,will lead to endless strife on the project. Each group will feel they are being treated unfairly and their expectations of the system are not being addressed. There is no way a project like this will be seen to be successful.

5.6.2 Quality Function Deployment (QFD) Japan 1960s - developed by Drs. Yoji Akao and Shigeru Mizuno The focus of QFD is to hear “The Voice of the Customer (VOC),” and to ensure what is heard is successfully translated into products that have value for the customer.

QFD is an integrated, four-stage approach which covers the entire life-cycle of product development: Product Planning, Assembly/Part Deployment, Process Planning, and Process/Quality Control.

• Product Planning - includes defining and prioritizing the customer’s needs; analyzing competitive opportunities, planning a product that responds to the perceived needs and opportunities and establishing critical characteristics and target values.• Assembly/Part Deployment - includes identifying critical parts, components and assemblies of the product, decomposition of critical product characteristics, and translation of critical components into class characteristics and target values.• Process Planning - includes determining critical processes and process flows ,development of required techniques and technology, and establishing process control targets.• Process/Quality Control - includes determining individual part and process characteristics, creating process control methods to support measurement and establishing standard inspection and testing processes.


5.7 Developing Testable RequirementsTestability is the only criterion that appears on the most commonly seen lists of critical attributes for Business Requirements and often on the list for Quality Requirements. It is one thing to say it is important, it is another to know specific approaches for accomplishing it. Discussed below are some of the most common and well respected methods for improving the testability of requirements. Each of these methods addresses one or more aspects of the quality of the requirement. These methods can be used individually or in combination, depending upon the needs of the organization. Each will require the investment of time and effort to obtain the desired result. Business Analysts and Project Managers who choose to add these steps to the process should expect to be challenged to demonstrate the cost effectiveness of the process in question.

5.7.1 Ambiguity CheckingUnambiguous is one of the top criteria for “good requirements.” But, what does it mean to be unambiguous and how can someone tell? To be unambiguous, a statement must have one, and only one possible interpretation. That is, any group of individuals reading the statement independently would come to the same conclusion/meaning.

5.7.1.1 What is Ambiguity CheckingThere are several tests that can be applied to a requirement to determine if it is clear, some are quick and easy, others require more effort. One approach is to change the focus or emphasis of the statement to see if the meaning changes. Another approach is to substitute a synonym for one or more of the key words to determine if the meaning will change. For example, the requirement for a system to be able to “punch the ticket” can be interpreted as placing a small mark or hole on a physical document, or it might mean to hit the document. There are also several slang interpretations of this phase which could further cloud the issue.

5.7.1.2 Performing Ambiguity CheckingOne place to begin the process is to do a simple test for potential ambiguity. Select a small set of related requirements. Choose a small group of qualified developers and ask them to do aquick estimate on how long it will take to implement those requirements. The resulting numbers themselves might be of little interest, what is important is the level of consistency. If the responses are all within a fairly narrow range, there is probably little ambiguity (the requirements may not be correct, but everyone interprets them same way). If there noticeable divergence, ambiguity may be an issue and the requirements set should be subject to further scrutiny.

The checking process can be done by as few as two or as many as five or six qualified professionals, at least one of whom should be representative of the stakeholder group submitting the requirement. Walking through the requirement in the group and performing restatements will provide the opportunity for ambiguities to be identified and resolved. Building this into the development process would indicate that early estimation of requirements sets, by qualified individuals, can help to identify potential areas of ambiguity.

As estimates will be needed eventually, doing them when they can contribute to the quality of the requirements makes good sense. Many organizations have limited estimating skills, with the result that only a few individualsroutinely perform the estimating tasks. In this environment, the need to have multiple estimates for a single body of requirements may meet a lot of resistance. One solution to this is to have one experienced estimator as a part of the group and include several other novices. Initially there will be wide divergences, but over time the quality and consistency will improve. The novices will learn the estimating skills while helping to identify potential ambiguities. This will help the organization to ease the estimating bottleneck.


5.7.2 Resolving Requirement Conflicts The need for consistency in requirements has been discussed earlier. Consistency means there are no internal contradictions among and between requirements statements. A conflict would mean it would not be possible to satisfy the conflicting requirements concurrently. There are two possible causes of conflict:

1) a misunderstanding or miscommunication of what is actually needed or wanted.2) an actual conflict in the underlying business rules as presented by the stakeholders, based

upon existing priorities and practices. Easier to deal with is the first category. Once identified, the incorrect or misstated requirement is repaired and everyone is satisfied that there is not a conflict. Second scenario is more difficult for the Business Analyst to resolve The initial steps are to clarify with each of the respective stakeholder groups that their requirement, as stated ,accurately reflects the existing Business Rules. It is also worthwhile to learn the underlying reason or rational for the Business Rule(s). It may be possible to resolve the conflict at this point by a determination that one group is operating from ‘old information’ or the business need has changed since the rules were implemented. In this case, all of the groups can be reconciled to meeting the new business needs and the conflict corrected.The final, and most difficult case, is that a genuine conflict exists. It may also occur in loosely coupled organizations, where each unit has a wide range of authority in adopting operating approaches. The potential solutions to this are to not share the system, to create different versions, or to go with the stakeholder with the most at stake.This situation may occur when the stakeholders represent different external customers who have different business needs. In this case, a business decision must be made about which or how many customer sets to satisfy and in what sequence. The decision is often made to satisfy the largest group in the initial release and then to create other versions to address the smaller groups. Identifying conflicts is fairly simple for smaller systems. In the process of prioritizing requirements, they will be compared against each other at a one-to-one level. The conflict should be immediately apparent.For larger systems, the possibility of overlooking conflicts is much greater. The same approach, one-to-one comparisons, can be onerous in a system with several hundred requirements. If the relative priority of the requirements is the same for each of the stakeholder groups, they may be discussed in the same prioritization session, or in sessions attended by the same people. This is an argument for having some consistency in theprioritization processes. In the case that potential conflicts may affect the health or safety of individuals, there may be no alternative but do performed detailed, one-to-one comparisons. Adequate time must be allowed.

5.7.3 ReviewsA review is properly regarded as an organizational and political event, held at the end of a major project landmark. The purpose of the review is to certify the landmark has been completely and correctly achieved. Reviews should include all stakeholders for the product, process or project subject to review. Reviews are generally not decision-making sessions. They are a recitation and ratification of decisions already made.

Reviews often feature presentations by technical experts to decision makers, describing what has been done and why. Review meetings are differentiated from status meetings primarily in the level of detail presented and the lack of technical decision making and action plan development. In a status meeting the technical team will examine the issue, determine a Requirements action plan and assign responsibility for ensuring the actions are taken. In a review meeting the management team may or may not be advised that this was necessary.

Reviews should always be conducted in a “no surprises” environment. Potentially contentious issues should have been presented to key stakeholders in advance and agreement secured to the proposed course of action. If agreement has not been reached, the review should be postponed. Public arguments are bad for projects.Requirements should be reviewed at the end of the JAD process if one was conducted. Requirements should be reviewed with each key stakeholder group prior to consolidation with other stakeholder groups, but after internal prioritization. Requirements should be reviewed at the end of the consolidated prioritization process, before design begins in earnest. At each of these landmarks, the key decision makers, sponsors, champions and stakeholder will be asked to affirm their support for the product presented. In this way there is a clear link from each point of origin to the finished product, at an organizational level.


5.7.4 Fagan Inspections

In 1974 Michael Fagan inspection technique is credited with dramatically reducing the number of defects escaping into production. The Fagan Inspection Technique, also referred to as Formal Inspections, is a rigorous, structured approach to finding defects. Initially developed and applied to code, the use of the formal inspection process has been expanded to include work products at all stages of the development process. Examples of work products would include items such as a Function Requirements Document, a Test Plan or Acceptance Test Plan, an External or Internal Design Document as well as many others. The application of the Fagan Inspection process to Requirements has proved to be extraordinarily cost effective:Karl E. Wiegers, noted Requirements expert, states inspecting requirements is the single most effective process in reducing defects and improving product quality, returning as much as 40 to 1 the time spent in Inspections.Kirby Fortenberry, another well known consultant and writer about inspections cited the following results based on his work with clients:• Inspections were three times more effective than testing in finding defects• $1600 savings/defect found prior to test• $105 cost to find/fix a defect in Requirements using Inspections• $1700 cost to find/fix in Testing• $25,000 average Inspection savings• 10 – 25% reduction, development time• 90% reduction, corrective maintenance

5.7.4.1 Fagan Inspection Process

The Fagan Inspection process has a single objective: to find defects. Fagan devised a structured approach for reviewing work products at points of stability, that is, when they are supposed to be “done.”Because the Business Analyst has been instrumental in the development of many of the work products, especially the Requirements documents and the Acceptance Test Plan document, they will be very knowledgeable about the specific product. They may be involved as a representative of the authoring group if it is a product they have worked on or in the role of a skilled, but objective, pair of eyes if this is not a project they have been working on. In either case, they will be a major asset to process of finding defects.To determine when a product is ready for inspection, the organization must have set of standards and procedures. This includes both the project management information and the development methodology details. These two provide information about the activities that must be completed for a product to be ready for inspection; these are called the entry criteria. These references must also include the level of performance for the work being examined; these are called the exit criteria. Work that fails to meet the performance standard for one or more reasons is defective. Work products are judged against both the entry criteria and the exit criteria.When inspecting requirements, defects are categorized as either major or minor. The classic definition of a major defect is that it will cause a “failure in production.” Since what constitutes a failure in production varies a great deal from organization to organization, this must be defined and agreed to by all parties. Anything that is not a major defect is a minor defect.Major and minor defects are also categorized by type: wrong, missing or extra. Of the three, wrong is the easiest to identify, missing requirements take time and effort to see the gaps where a requirement should be. “Extra” requirements tend to be the most error prone, as they do not result from a customer or business partner request, so there are no real “requirements.”While it is possible to further categorize defects, there is little reason to do so. What will be important is to track where in the development process the defect is identified. If a requirements defect escapes into design, code, test or production, some work will need to be done to determine why the defect was not found earlier.

5.7.4.2 Fagan Inspection Participants (Moderator Author Reader Recorder Inspector - MARRI)All inspections include same set of roles, though roles may be filled by different individuals for types of inspections.Moderator Moderator also participates as Inspector.

Moderator plans and conducts the inspection session(s) .Ensures the required rework is addressed.Ensures the results of the inspection are properly recorded and reported .Should be technically competent to inspect the materialMust be a skilled facilitator, well organized, and able to provide time and effort

AuthorAuthor is also an Inspector

Author is a expert /representative of the authoring group for the work product. He is able to answer questions/issues that are identified during the inspection. Author is responsible for carrying the identified defects back to the authoring group which is responsible for ensuring they are fixed.


Authors are generally the best inspectors on the team as they have the best insight into the product and the project.

Reader is also an Inspector.

Reader is responsible for reading& paraphrasing material to ensure it is unambiguous. Reader maintains the pace of the meeting.

Recorder is also an Inspector

Responsible for logging identified defects & their classification (Major/Minor/, Missing, Extra).At session end Recorder reviews all defects to ensure that there is consensus on them.Roles of Recorder and Moderator can be combined and performed by 1 individual.

Inspectorrecommended total group size is 7-8 larger becomes difficult to manage

Each Inspector is responsible for having inspected the material prior to the session and having identified as many defects as possible Unprepared Inspectors may not remain in the session as they slow the process down and have a negative impact on morale

The Moderator can be from any part of the organization, but should be technically competent to inspect the material. Often Business Analysts and Software Quality Assurance staff possess the right skill mix for this job. The Reader is one of the most demanding jobs, and initially should be performed by the most skilled individuals. The various roles for inspecting requirements should include representatives from the business unit, business analysts, developers and testers. This mix will provide the best coverage of the of the project.One fundamental rule of Inspections is that Managers may not participate. There are very sound reasons for this, the most important being that the possibility of this information becoming part of the personnel evaluation process is enough to kill the effectiveness of inspections.

5.7.4.3 Fagan Inspection IssuesFagan Inspections are a powerful tool for identifying defects early in the life cycle, however, despite this, they have not been implemented as widely as might be expected.

Barriers /Reasons why Fagan inspections are not widely implemented.

TimeInspections are labor intensive, particularly in the early stages of implementation. The history of the industry is to short-cut any process that delays the beginning of coding, regardless of how counter-productive that strategy may be in light of the pressure to deliver products quickly. The fact that Inspections will actually improve delivery time and reduce expenses is not well accepted despite numerous studies of it effectiveness.

Level of Maturity

Effective use of the Fagan Inspection technique requires organizations be at least a CMM(I) Level Two, and probably Level Three to obtain the maximum benefit on a consistent basis. The key to this is the need to have well defined processes and procedures that are employed consistently by the organization, and not jettisoned as soon as time pressures are applied

Fixing Defects The identification of defects during the session is firmly separated from the correction of the defects, which is the responsibility of the authoring group. Failure to require defects to be addressed in a consistent manner will discourage participants from investing the time/effort to find the defects. For some organizations, discipline needed to fix defects is very difficult.

Environmental Barriers

Lack of trusting environment in which finding defect does not have a negative appraisal on person.For organizations intent on finding someone to blame for every defect, Inspections are not a viable option.


5.7.5 Gilb Agile Specification Quality Control (SQC)Because of the some of the issues above, Tom Gilb has developed an alternative approach to the Inspection Process. This approach uses sampling of work products early in the life cycle to predict defect rates and to identify potentially defect laden products from being developed.

5.7.5.1 Agile Specification Quality Control (SQC) ApproachRather than attempting to perform line by line inspections of many large documents, this approach takes small, representative, samples and examines them carefully, but not necessarily line by line. The results of these examinations are then used as the basis for calculating the defects in the entire body of work, using statistical data.For the purpose of the SQC, Gilb defined a major defect as anything that can potentially lead to loss of time or product quality. Minor defects are anything that is not correct but will not lead to loss of time or product quality. This definition sets the bar much lower than the Fagan definition.

Instead of reviewing against the entire process and procedure set, Inspectors select a limited number of very important criteria to use in the inspection process, typically between 3 and 7.For Requirements Gilb recommends “clear enough to test, unambiguous to the intended readers and completeness when compared to sources.” Using a streamline rule set speeds up the process, but does leave the potential for missing other kinds of errors.Experience with this method had determined that two inspectors, working together for 30-60 minutes will find about one third (33%) of the total defects in the document of about one page.Individuals working alone will find a smaller percentage. Using either the average of all reviewers or the best average, the result of the sample inspection is then used to calculate a defect rate for the document as a whole:10 major defects identified on one page of an 80 page document would mean a defect density of 2400 for the entire document (10 * 3 * 80).Organizations establish an acceptable exit rate for defects. Initially it may be set high reduced as processes improve.5.7.5.2 Using Inspection ResultsUnlike the Fagan approach that mandates the correction of all (or almost all) defects, the Gilb approach is used to educate the staff about how to do things correctly. Following participation in an SQC session, the defect injection rate falls by about 50%, thus improving product quality.For this reason Gilb recommends using SQC very early in the process, before products are large and fully developed. He recommends the on-going sampling of products through development. This strategy will lead to the incremental improvement of the products being developed. It may indicate the need for additional training or modification of standards and procedures before the product is too badly flawed to be saved.5.7.5.3 Agile SCQ ParticipantsA minimum of two inspectors and one inspection leader are required for each 60 minute session. Depending upon the size of the material to be sampled there may be as many as five or six inspectors. Inspectors must be professionally competent to understand the material being examined. Business partners, business analysts, testers, developers and managers are all viable participants.5.7.5.4 Agile SCQ IssuesWhile this method does address many of the issues raised with the traditional Fagan Inspection, there are other issues created:• Defects are not found - The emphasis in this method is about estimating the defect density and using this information to motivate engineers to learn to avoid defect injection in the first place. Defects will still need to be found and the will still need to be addressed .Only certain kinds of defects will be identified. Others will simply be missed. One strategy is to use root cause analysis to determine the largest sources of errors, and use those rules first. As these defects types are reduced, other rules can replace them in the examination process.• No Feedback Loop - Because the emphasis is not on finding defects, the kind of process improvement loop that is typical in an organization committed to Fagan inspections is missing. While it is anticipated that individuals will do a better job of creating work products, this improvement does not necessarily become institutionalized.• No Accountability - Because there is no structure around the process, there is no way to track what happens to the defects that are discovered. This means that even relatively defect laden material can be “moved along the process,” as no one has an obligation to ensure problems are being corrected.

5.7.6 Consolidated Inspection ApproachSome organizations are reporting good results by using a combination of the two inspection approaches. The Gilb Agile SQC method is used early in the development of requirements as a diagnostic aid. Those products that exceed a specified threshold are required to undergo a full Fagan Inspection; those below a specified threshold are approved; and those in the middle are subject to on-going sampling to monitor their quality. This approach allows organization to focus their efforts on those products most in need, while conserving significant staff resources.


5.8 Tracing RequirementsReason for creating a list of requirements is that it represents what the business partner or customer needs or wants to find in the finished project. While this fact may be embarrassingly obvious, too many organizations fail to take the steps necessary to ensure that the requirements are there. These are fairly straight-forward and can be accomplished easily if a small amount of forethought is given to the process.

5.8.1 Uniquely Identify All Requirements Notice the emphasis on the word all.Many organizations track requirements that are included in the approved version of the product. This is an excellent starting place, but it is not enough. Every potential requirement that survived any requirements definition session to end up on a document should be tracked. This means there must be at least two listings for even small projects; one for the requirements to be implemented and one for those that will not be implemented.For most projects, ranking, combined with a project number is sufficient to uniquely identify each requirement. Keeping this part of the process as simple and clear as possible will save resources.Items that are not to be included in any planned release of the products are often the source of later conflict and contention. For each rejected item, there should be listed, in addition to the requirement itself, the date, the group or authority making the decision and the reason for rejection. By creating the listing of rejected requirements incrementally, and making it electronically accessible to all stakeholders, it is possible to manage down the amount of time spent cycling around pet requirements. Requirements on this list should be uniquely identified; a simple 1 to N scheme will work. Org can use an R for Rejected or N for Not Approved to preface the number. Eliminates confusion in numbering.

5.8.2 From Requirements to DesignOnce the list of uniquely identified requirements has been agreed upon, designers to begin the work of translating those requirements into solutions. The listing provides the opportunity for a two way inspection of the final design.

5.8.2.1 Tracing Requirements to DesignIt should be possible to take each requirement and see where it is addressed in the design. If it was a good requirement, the designer will have had the complete information necessary to come up with the best solution. Tracing each requirement to the design component takes time, but also ensures the product to be built will meet the customer’s wants and needs & ensure that nothing is missing from the design.5.8.2.2 Tracing Design to RequirementsThis backward flow is an essential step to ensure additional requirements have not been inserted into the design. After each element has been traced back to the source requirement, there should be nothing left over. If there is, these represent defects in the design. Providing the designer with access to the list of Rejected (Not Approved) or deferred requirements means that before inserting unspecified functionality, they can look to see if it is coming later or has been rejected.

5.8.3 From Requirements to TestThis aspect of traceability allows the Testing staff to develop the needed test cases for the functionality to be delivered. As discussed earlier, the sooner the testing effort can begin, the better the final product will be. Creating test cases early in the life cycle allows the effort to be spread out over a much longer time.

5.8.3.1 Tracing Requirements and Design to TestThe question of how to test a specific requirement will arise early and often. By the time the test plan is complete, all of the issues about how to test specific parts of the requirements should be resolved. Clearly some of those issues will not be resolved until the design is complete. Testers need to know the specific implementation that the design will create for a requirement.The requirement may be that the result of a calculation be made available to the customer. The implementation of that requirement in design may be to show the total on the screen. The resulting test cases will need to address both the initial intent to correctly perform the calculation and the subsequent decision to place that result in a specific screen after a specific set of inputs. This relationship creates a treelike structure of test cases that can be executed. Tracing the relationships will expose areas for which the needed test cases do not exist, allowing this defect to be corrected before the product is released to the customer.5.8.3.2 Tracing Test Cases to Design and RequirementsAs with the backwards flow of design, the reverse tracing of test cases can highlight potential problems. Redundant test cases waste resources. Tests for items not included also waste resources. This being said, when experienced business analysts or testers identify a “missing requirement”, they should develop the appropriate test cases and bring the issue to the attention of the project team. By ddressing traceability issues as early as in the project as possible, resources can be spent as effectively as possible.


5.9 Managing Requirements Requirements will change.

Typical reasons for changes to requirements include errors in the original requirement (missing, incorrect or extra); changes to the internal organization or its functions (added or deleted); changes to the external environment (regulatory or competitive).This means the goal of creating a fully complete, fully correct and unchanging set ofrequirements at the beginning of a multi-year project is unrealistic.

The Agile approach suggests collecting just enough requirements for the current development effort, and keeping that effort small enough to control the rate of change. It is only prudent to plan for the changes that will occur during a project, and to develop a mechanism for managing that change effectively. As with traceability, managing change entails a small set of fundamental steps. Developing a Requirements Configuration Management Process will allow the organization to maintain control over the project .

By looking at the Requirements Configuration Management activities as a process, it is possible to leverage what we know about our processes and improve the product(s). The same key concepts that historically have been demonstrated to work effectively for source code management and production control can be applied to requirements. There are two key components, a Requirements Configuration Manager, and a Requirements Change Control Board. These two work together to ensure that only properly authorized requirements areadded to the project scope. For projects of any significant size and duration, the project manager will typically identify an individual to function as a requirements configuration manager. This individual will have access to the requirements document and be able to make authorized modifications to that document. The Requirements Configuration Manager may fill that role for a single project, or for the organization as a whole. At a minimum, the configuration manager must be perceived as a team player and one upon whom the rest of the team can rely. The Business Analyst may find that there is no established “requirement configuration manager” for a specific project. In that instance, they may need to fill the gap while helping the organization understand why it is essential that the role be filled.

5.9.1 Create a known baseThe Project Owner or key stakeholders have been identified and documented in the Project Charter. The base is the approved Requirements Document for the project. This document is the result of all of the various Requirements Definition and Prioritization activities that have taken place on the project to-date. It includes the Critical Success Factors, the Critical Assumptions, as well as other significant information about the project. These documents should be accessible to the project team members and stakeholders electronically. Creating and maintaining paper based documents becomes very time consuming and labor intensive. It also opens the door for the possibility the paper copy will be lost or destroyed by accident.A fundamental component of this known base is the document that contains all of the approvals for the requirement set by the project stakeholders, champions, sponsors, and other appropriate team members. It also contains a document “change history.” This document is “proof-positive” of the approved list of requirements, the known base. Going forward, anything not included on this signed document is a change to the project and must be treated as such.


5.9.2 Manage AccessOnce final agreement has been reached on the Requirements document, it is essential to protect the integrity of the document. In this electronic age, that is readily managed through the careful application of appropriate access permissions. The document may be read by many, but only changed by a few.To make this work, there must be a process for managing access. This process must be a part of the organization’s standards and procedures. Typically, the parties authorized to submit changes provide an updated version of thematerial to the individuals actually making the change. These changes may be regarded as an update to any application system and processed via the normal “change control” process. This approach is preferable asthe network staff will require the appropriate documentation be submitted on a consistent basis. This eliminates the possibility of people “forgetting” approvals are required for changes.

5.9.3 Authorize changesThe approval process for change requests should be a subset of the original approval process, managed by the Requirements Change Control Board. Often organizations create change categories which determine what approval is required based upon the scope and impact of the changes. This is effective at keeping the approval process simple, but care must be taken that large changes are not merely being broken into pieces that can be approved at a lower level. Changes to the Requirements may or may not be a result of a defect in the process. Documentation accompanying the change request should include not only how long it will take and how much it will cost, but also the impact on the schedule. Any change request marked “no impact” should be subject to very close scrutiny .

5.9.3.1 Change Control Board (CCB)For configuration management of requirements to be effective it must be officially sanctioned at some level of the organization. The purpose of the Change Control Board is to ensure the integrity of the requirements change process, not to address or resolve technical issues. A CCB is not an inspection agency. While the team on the CCB will generally be highly skilled professionals, any move on their part to take over the roles of the project team is inappropriate.The act of “ceremonializing” a function lends it credibility and respect. The discussions about how the process will work ,and developing an agreement about how to handle specific situations brings potential issues to the surface which must be resolved. It is a mistake to jump into the process without a clear understanding of its purpose, what is to be accomplished and how much authority is available to do so.Creating a Charter for the Requirements Change Control Board will force these things to occur. The charter should specify how members of the CCB are selected; generally it will be composed of members from both the business side and the technical side of the project team.Often key stakeholders will be named as the representatives from their organization to the CCB. Typically they will delegate the responsibility for handling the routine matters to staff members and only participate directly when there are significant issues or conflicts.Because not all changes are accepted or approved, it is essential that those responsible for the Requirements Change Control Board are perceived as being fair and responsible. This starts with excellent communication skills, especially listening skills. If not listened to carefully and considerately, people requesting or suggesting the change will become disillusioned andfrustrated with the process and look for ways around it.Some level of conflict is inevitable whenever there are scarce resources; the Requirements CCB needs to be skilled at anticipating and defusing conflict when possible. They also need to be prepared to handle the conflict when it becomes unavoidable; working toward a solution which is in the best interests of the entire organization.The Charter should specify which projects are subject to the CCB process if it does not apply to all projects. In some organizations certain kinds of changes are exempted, especially when just getting started; however this is not the best method long term. Creating realistic project thresholds will improve the creditability of the process and discourage the development of creative strategies for avoiding it. The process definition should also specify what kinds of changes must be reviewed by the Board, regardless of other criteria. This is common when the project under development contains health or safety dimensionsIn larger organizations the Requirements Change Control Board may be supported administratively by the Business Analyst or the Quality Assurance organization, either of which may also function as the acting Chair for routine meetings.5.9.3.2 Change Scope: Requirement, Enhancement or New ProjectScope creep is the bane of every business analyst and project manager’s existence. The need to keep the product within schedule and budget parameters while maintaining the quality and functionality is their number one responsibility. Each suggested or requested or demanded change to the requirements challenges the team to maintain that balance.


Typically, the first aspect of the change addressed is: how big is it? It this a small change, easily accommodated? Is it a little bigger, but still not requiring any significant redesign? Or is it major, perhaps impacting work products with design, code or even testing already completed?It is essential to preserve a sense of scale regarding potential changes to the system requirements. If the organization has a reasonably effective requirements process, large, late development stage changes should be relatively uncommon; and they should come from a limited number of sources. Generally they should have been anticipated, at least in the abstract, in the Critical Assumptions.If the requested changes are approaching 10-15% of the estimated work effort at the completion of Design, some serious rethinking must be done. Is this really a part of this project, or is it a new project? When a lot of projected resources are to be consumed by a function or series of functions not strongly related to the business goal, it may be time to break them out as a separate project. If the key customers see them as essential to the project, it may be time to revisit the project definition to ensure everyone has the same understanding of the problem to be solved.As a general rule of thumb, any change that increases the original scope by 10% should be looked at as a potentially new project, requiring a separate cost-benefit analysis and associated approvals. The CCB should be asking fundamental questions about every proposed change to requirements, especially non-trivial ones; they include:• Why does this need to be done?• Must it be done now?• How is it related to the overall business objective of this project?• How is it cost justified?• Does this replace something else previously included?5.9.3.3 Establish priorityThe Change Control Board, having ensured that the same level of analysis was exercised in the development of the proposed requirement as with the original requirements, must have the authority to accept or reject the change. Because the CCB is comprised of the key stakeholders or their assignees, this should not be an issue. It may be difficult to reach consensus, but the authority is present.The process for the decision making should be a microcosm of the initial requirements development. In particular, the CCB will need to determine, based on input from all invested parties, what the priority of each of the requested changes is. The new requirement will need a unique identifier that will allow it to be tracked through the development and testing process.5.9.3.4 PublishOnce the decisions have been made, the results must be made official through publication.This includes updating the appropriate listings of accepted and rejected requirements and having them moved into the viewable space by the authorized individuals or groups. Failure to update the log of deferred or rejected items will often cause them to reappear with a new nameor sponsor. Communication is essential.

5.9.4 Control resultsThe intent of the process is to help the organization achieve the result it desires. The controls exist to combat chaos and confusion. The process provides the development team in particular with protection from random, unwarranted intrusions into the life of the project. Effective control of the final result is dependent upon the diligence of the CCB and the project team to specific areas of concern.

5.9.4.1 Size the effortThe CCB should never accept for consideration a change request that is not accompanied by a standard estimate of work to be performed. Allowing generic estimates (small, medium, large) or vague ones (3-5 staff-weeks, based on available resources), creates opportunity for defective requirements to be approved.5.9.4.2 Adjust the resources or the planWhat will be a more troublesome issue in many organizations is how to integrate an approvedchange into the existing project plan. The CCB has been provided with information about thesize and complexity of the proposed change. They also know the priority of the request. Thebasic options, mentioned earlier in this Skill Category, are few:

• Integrate the change into the plan with no change to the official schedule, resources, scope or quality.• Integrate the change into the plan and adjust schedule, budget or both. These are acceptable solutions if the adjustments are realistic. These are generally unpopular, especially with customer .• Integrate the change into the plan and cut scope to compensate for the added work.This is where the effort to estimate and prioritize both the original requirement set and subsequent changes to requirements will pay dividends.

5.9.4.3 CommunicateThroughout the process it is essential to ensure all of the stakeholders are made aware of each proposed change to the approved set of requirements. They must have the opportunity to assess the risk, the reward, the potential cost in dollars, staff, schedule, scope and quality. The decision making process must be transparent to maintain creditability. Compromises, when they are made, must be undertaken in the context of what is best for the organization as a whole, and then supported by the entire decision.


CSBA - Requirements chapter with my diagrams

Documents

Transcript of CSBA - Requirements chapter with my diagrams