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.6. Stable . . . .
5.1.3.2. Complete . . . . 5.1.3.7. Verifiable . . . .
5.1.3.3. Consistent . . . 5.1.3.8. Modifiable . . . .
5.1.3.4. Unambiguous . . . . 5.1.3.9. Traceable . . .
5.1.3.5. Important . . . .
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.6. Maintainability . . . . .
5.3.1.1. Efficiency . . . . . 5.3.1.7. Flexibility . . . .
5.3.1.2. Reliability . . . . 5.3.1.8. Portability . . . . .
5.3.1.3. Availability / Response Time . . . 5.3.1.9. Reusability . . . . . .
5.3.1.4. Integrity / Security . . . 5.3.1.10. Interoperability
5.3.1.5. Usability . .
5.3.2. Relationship of Quality Requirements . . . . .
5.3.3. Measuring Business and Quality Requirements . .
5.3.3.1. Minimum Level of Acceptable 5.3.4.1. Standardization . . .
Quality . . 5.3.4.2. Accessibility . . . .
5.3.4. Enterprise Requirements . . . 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 defined

Requirements 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 design

Design 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 explored
This 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 The Business Project Sponsor or Champion is the individual with the organizational authority to
Business commit resources to the project and usually is the functional head of the project on the business
Project side. Typically their signature will appear on the initial request to begin the project (other, higher
Sponsor or level signatures may also appear depending upon the size and scope of the project.).The Sponsor
Champion 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 are other individuals or groups within the organization that have an interest
Business in the project. A typical example is Accounting, which is often a stakeholder; many projects
Stakeholders sponsored by Sales or Human Resources have tax implications involving the accounting area. In
and Subject any project such as this, the Accounting Department is a key stakeholder in the requirements
Matter process. They will have significant contributions to make. Excluding them
Experts (SME) from 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 play a crucial role in the requirements definition process. They will be able to articulate
Developers 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 In this context, customers and suppliers are individuals and organizations external to the developer
Customers of the software, it is important to include them in the Requirements Definition process. External
and Suppliers 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 are the core of the Requirements Definition process because they are fluent in
Business both the language of business and the language of technology; they are able to translate for both
Analysts 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 of
the 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 requirement
Number of attributes which together define what a “good requirement” is.
Attribute Description CCCUISVMT ----- CUM IS CCTV
Correct 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 it
To 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 serve
two 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 requirements
Requirements 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 Development

One 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:
Facilitator Chairs the meeting and directs the flow of activities, keeping the participants on track. The
Or Session facilitator is responsible for identifying issues that need to be addressed. The facilitator
Leader traditionally contributes no content to the session.
Project This individual is explicitly included in the JAD session. It is essential that they be
Manager/Leader 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, One or more of these roles will be needed for every session. The Scribe is responsible
Documentation for capturing the flow of the meeting and all results. A Modeler may be there to support
Specialist. 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.
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
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
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
5. Prepare and Obtain Approval for Output Documents - There will be a few or many output
documents. Each of these
must 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
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 Model

The 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 Created

A 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 Model
The 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 Case

A 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, hardware
components 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 Created

Use 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 applied

Use 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 Usage
It 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 when
Few 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
onion
The symbolism generally used for DFDs is as follows:
Processes - are represented by circles showing processes that use data. They modify the
Generat inputs of the process to create desired outputs. Some outputs are temporary and transient,
e others will be permanent. The verb-noun syntax is once again recommended for use.
Invoice Developing an index of names will help to ensure that name’s stay unique
External Entities or Process Terminators - are represented by rectangles. A terminator is
Accounting a external entities outside the control of the system being modeled . Terminators represent
Dept 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
Data Stores - are represented by parallel lines; these are places where data comes to rest.
Stores 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.
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 made
2. For each event, a process is constructed
3. 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:
Attribute Relationsh Entitiy
• 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.
• 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: 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 in
A entity B. If these entities will eventually become databases, there will be only one
B row in A for every row in B and vice-versa. Notice that this one symbol reflects
what is occurring at each end of the relationship. In this one instance, the
relationship is the same for A to B and for B to A. One-to-one relationships are not
common in most applications, although they do occur.
One to zero or one: The second relationship is both more common and more complex. The left end of
the line, nearer the letter A, reflects the relationship of B to A. In this case each
a item in B is uniquely related to one, and only one, item in A. Reading the symbols
b at 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: 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
A zero items. Each item in B however is only related to one item in A. Clearly this
B 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: The fourth symbol set allows for the possibility an item in A may relate to none or
A many items in B. Each item in B however, must still have a relationship with an
B item in A. This flow also can be reversed.
Each instance of A is related to a minimum of

A B
zero and a maximum of one instance of B
Each instance of B is related to a minimum of

A B
one and a maximum of one instance of A
Each instance of A is related to a minimum of

A B
one and a maximum of many instances of B
Each instance of B is related to a minimum of

A B
zero and a maximum of many instances of A
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.
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.
Figure 5-6 State Transition Diagram

Transitions 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 Prototyping
A 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
5.2.6 Test First
Many 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 Quality

Quality 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 to
incorporate 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 Accessibility
As 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 eg
The 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 Control
Appropriate 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 Constraints
A 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 , Resources Internal External

Procedures Environment Environment
5.4.1.1 Hardware
Eg 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 Software
Software 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 Procedures

Each 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 Resources
This 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 Environment

This 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 Environment
This 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
considered
when 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 criteria
for 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
Choice
process 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
scheduled
delivery 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 Deployment

Prioritizing 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 is
possible 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
decision
makers 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 Requirements

The Requirements process does not end with the identification of all of the Requirements. Not all of those
defined
will 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 of
achieving 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 “voting
representative” 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 Requirements
Testability 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 Checking

Unambiguous 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 Checking

There 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 Checking

One 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 individuals
routinely 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 the
prioritization 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 Reviews
A 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 plans and conducts the inspection session(s) .
Moderator also Ensures the required rework is addressed.
participates as Ensures the results of the inspection are properly recorded and reported .
Inspector. Should be technically competent to inspect the material
Must be a skilled facilitator, well organized, and able to provide time and effort
Author Author is a expert /representative of the authoring group for the work product.
Author is also an He is able to answer questions/issues that are identified during the inspection.
Inspector 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 Reader is responsible for reading& paraphrasing material to ensure it is
is also an Inspector. unambiguous. Reader maintains the pace of the meeting.
Recorder Responsible for logging identified defects & their classification (Major/Minor/, Missing,
is also an Inspector 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.
Inspector Each Inspector is responsible for having inspected the material prior to the session
recommended total and having identified as many defects as possible Unprepared Inspectors may not
group size is 7-8 larger remain in the session as they slow the process down and have a negative impact on
becomes difficult to morale
manage
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 Issues

Fagan 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.

Inspections are labor intensive, particularly in the early stages of implementation. The history
Time 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 Effective use of the Fagan Inspection technique requires organizations be at least a CMM(I)
Maturity 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 Lack of trusting environment in which finding defect does not have a negative appraisal on
Barriers 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) Approach

Rather 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 Results
Unlike 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 Participants
A 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 Issues
While 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 Approach

Some 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 Requirements
Reason 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 Design

Once 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 Design
It 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 Requirements
This 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 Test

This 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 Test
The 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 Requirements
As 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 of
requirements 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 are
added 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 base

The 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 Access
Once 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 the
material 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 as
the 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 changes

The 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 and
frustrated 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 dimensions
In 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 Project
Scope 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 priority
The 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 Publish
Once 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 results
The 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 effort
The 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 plan
What will be a more troublesome issue in many organizations is how to integrate an approved
change into the existing project plan. The CCB has been provided with information about the
size and complexity of the proposed change. They also know the priority of the request. The
basic 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 Communicate
Throughout 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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSBA - Requirements Chapter With My Diagrams

Uploaded by

Copyright:

Available Formats

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.2.1.1 What is Joint Application Development (JAD)

5.2.1.2 Who participates in Joint Application Development

The life of any organization contains five kinds of events:

5.2.2.1 What is a Business Event Model

5.2.2.2 How is a Business Event Model Created

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.4.1 Data Flow Diagrams (DFD)

Ed Yourdan, a pioneer in structured analysis, suggests a less intensive approach(Event Partitioning

5.2.4.2 Entity Relationship Diagrams (ERD)

Attribute Relationsh Entitiy

Each instance of A is related to a minimum of

Each instance of B is related to a minimum of

Each instance of A is related to a minimum of

Each instance of B is related to a minimum of

Sample ERD diagram below for exam purpose

5.2.4.3 State Transition Diagrams (STD)

State Rectangles with rounded corners are

Transitions - from one state to another are

Figure 5-6 State Transition Diagram

5.3 Quality Requirements

5.3.1 Quality Factors ( MICE UR FIRT)

5.3.3.1 Minimum Level of Acceptable Quality

Hardware Software Policies ,Standards , Resources Internal External

5.4.1.3 Policies, Standards and Procedures

5.4.1.5 Internal Environment

5.5.2 Critical Assumptions (CA)

In reviewing this example, there are several items of note.

5.6 Prioritizing Requirements and Quality Function Deployment

5.6.1 Prioritizing Requirements

5.7.1 Ambiguity Checking

5.7.1.1 What is Ambiguity Checking

5.7.1.2 Performing Ambiguity Checking

5.7.4.1 Fagan Inspection Process

5.7.4.3 Fagan Inspection Issues

Barriers /Reasons why Fagan inspections are not widely implemented.

5.7.5.1 Agile Specification Quality Control (SQC) Approach

5.7.6 Consolidated Inspection Approach

5.8.2 From Requirements to Design

5.8.3 From Requirements to Test

By looking at the Requirements Configuration Management activities as a process, it is possible to leverage

5.9.1 Create a known base

5.9.3 Authorize changes

5.9.3.1 Change Control Board (CCB)

You might also like