1

Prepared By:
Eng.\ Tarig Ahmed Khalid, M.Sc., PMP, CEC, CBAP
I T/ Project Management/ Business Analysis Consultant & Trainer

Software Requirements
2
Introduction
The Software Requirements Knowledge Area (KA) is concerned
with:
1. Requirements Elicitation
2. Requirements Analysis
3. Requirements Specification
4. Requirements Validation

It is widely acknowledged within the software industry that
software engineering projects are critically vulnerable when these
activities are poorly performed.
3
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
4
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
5
1.1 What is a Requirement?
A requirement

is:
1. A condition or capability needed by a stakeholder to:
a. solve a problem, or
b. achieve an objective
2. A condition or capability that must be met or possessed by a
solution or solution component to satisfy a :
a. contract,
b. standard,
c. specification, or
d. other formally imposed documents
3. A documented representation of a condition or capability as in
(1) or (2)

IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology
6
1.2 What is a Software Requirement?
Software requirement is a property which must be exhibited in
order to solve some problem in the real world.

Software requirement is a property which must be exhibited by
software developed or adapted to solve a particular problem.

An essential property of all software requirements is that they must
be verifiable

7
1.3 Importance of Requirements
Requirements Management can be an extremely complex
discipline because of:
1. the numbers of stakeholders involved in the development
process
2. the precious use of resources.

Let us compare the following projects in terms of specifications
complexity:


Building a
Building a
VS.
8
Poor requirements management is likely to lead to some very
costly mistakes.

9
Requirements are classified into:
1. Business Requirements
2. Stakeholders Requirements
3. Solution Requirements
4. Transition Requirements

Business
requirements
Stakeholder
requirements
Solution
requirements
Transition
requirements
Requirements evolve!
1.4 Types of Requirements
10
1.4.1 Business Requirements
Are higher-level statements of the goals, objectives, or needs of the
enterprise.

They describe :
1. The reasons why a project has been initiated
2. The objectives that the project will achieve
3. The metrics that will be used to measure its success.

Business requirements describe needs of the organization as a
whole, and not groups or stakeholders within it
Related to the organizations executives & BOD
11
1.4.2 Stakeholders Requirements
Are statements of the needs of a particular stakeholder or class of
stakeholders.
They describe:
1. the needs that a given stakeholder has
and
2. how that stakeholder will interact with a solution.

Stakeholder requirements serve as a bridge between business
requirements and the various classes of solution requirements.
Business
Requirements
Solution
Requirements
Stakeholders
Requirements
12
1.4.3 Solution Requirements
They describe the characteristics of a solution that meet business
requirements and stakeholder requirements.

They are frequently divided into:
a. Functional Requirements
b. Non-functional Requirements
13
a. Functional Requirements
They describe the behavior and information that the solution
will manage.
They describe capabilities the system will be able to perform in
terms of behaviors or operationsspecific information
technology application actions or responses.

b. Non-functional Requirement
They capture conditions that do not directly relate to the
behavior or functionality of the solution describe
environmental conditions under which the solution must remain
effective Qualities that the systems must have.
They are also known as quality or supplementary requirements.
These can include requirements related to capacity, speed,
security, availability and the information architecture and
presentation of the user interface.
14
1.4.4 Transition Requirements
They describe capabilities that the solution must have in order to
facilitate transition from the current state of the enterprise to a
desired future state.
They will not be needed once that transition is complete.



They are differentiated from other requirements types because:
1. They are always temporary in nature implementation project
2. They cannot be developed until both an existing and new
solution are defined
Examples: data conversion, skill gaps, etc.

Current
State
Future
State
Transition
Requirements
15
1.5 Emergent Properties
Requirements which cannot be addressed by a single component,
but which depend for their satisfaction on how all the software
components interoperate.
Examples of emergent properties:
Reliability
Maintainability
Performance
Usability
Security
Safety

16
1.6 Quantifiable Requirements
Software requirements should be stated as clearly and as
unambiguously as possible, and, where appropriate, quantitatively.

It is important to avoid vague and unverifiable requirements which
depend for their interpretation on subjective judgment (the
software shall be reliable; the software shall be user-friendly).

This is particularly important for nonfunctional requirements.


17
Requirements Measures
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K Bytes
Number of RAM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
18
1.7 System Requirements &
Software Requirements

System means:
an interacting combination of elements to accomplish a
defined objective. These include hardware, software, firmware,
people, information, techniques, facilities, services, and other
support elements, - as defined by the International Council on
Systems Engineering (INCOSE).

System Requirements:
are the requirements for the system as a whole. In a system
containing software components, software requirements are
derived from system requirements.

19
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
20
2.1 Process Models
The objective of this topic is to provide an understanding that the
requirements process:
is not a discrete front-end activity of the software life cycle,
but rather a process initiated at the beginning of a project and
continuing to be refined throughout the life cycle
needs to be adapted to the organization and project context

In particular, the topic is concerned with how the activities of
elicitation, analysis, specification, and validation are configured
for different types of projects and constraints.
21
A simplified representation of a software process, presented from
a specific perspective.

Examples of process perspectives are
1. Workflow perspective - sequence of activities;
2. Data-flow perspective - information flow;
3. Role/action perspective - who does what.

22
Adaptive vs. Predictive Process Models
Agile Iterative
Waterfall
Adaptive/ Change-Driven Predictive/ Plan-Driven
Waterfall: since 70s till today;
Aims to predict all aspects (requirements, risks...),
The solution is accomplished at the end of the process
Iterative: since 80s (as opposed to Waterfall) till today;
The solution features are developed incrementally,
Components of the solution may be ready at the complition of the first
iterations
E.g: RUP, UP
Agile: since 90s till today;
Similar to Iterative, but the iteration duration is few weeks
Each iteration may be managed according the waterfall approach
E.g: Agile UP, Scrum, Crystal Clear, Extreme Programming, etc
23
2.2 Process Actors
The roles of the people who participate in the requirements
process.

Interdisciplinary process The requirements specialist needs to
mediate between the domain of the stakeholder and that of
software engineering.

Many people involved besides the requirements specialist, each of
whom has a stake in the software.

The stakeholders will vary across projects, but always include
users/operators and customers .
24
Examples of software stakeholders

1. Sponsor
2. Users
3. Customers Who represent the softwares target market.
4. Market analysts Market needs customers.
5. Regulators Software Compliance
6. Software engineers Profiting from reusing !!!
7. Others (Direct or Indirect!!!)

25
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
26
3.0 Definitions
Requirements elicitation is concerned with:
1. where software requirements come from
2. how the software engineer can collect them.
It is the first stage in building an understanding of the problem the
software is required to solve.
It is fundamentally a human activity Relationships between the
development team and the other stakeholders.
Also known as requirements capture, requirements discovery,
and requirements acquisition.
Needs good communication between users and software engineers.
Requirements specialists may mediate between the domain of the
software users (and other stakeholders) and the technical world of
the software engineer.
27
3.1 Requirements Sources
Requirements have many sources in typical software
It is essential that all potential sources be identified and evaluated
for their impact on the software.

Sources include:
1. Goals objectives of the software value vs. priority vs.
cost of goals Feasibility Study
2. Domain knowledge: The software engineer needs to acquire,
or have available, knowledge about the application domain.
+ve Interaction assess the trade-offs
3. Stakeholders ( Process Actors) identify, represent, and
manage different viewpoints/interests/agenda


28

4. The operational environment observing constraints in
real-time software interoperability constraints in an
office

5. The organizational environment support a business
process impact of the structure, culture, and internal
politics of the organization.

29
3.2 Elicitation Techniques
Requirements sources are identified eliciting requirements
techniques for getting human stakeholders to express their
requirements Difficulties


Elicitation is not a passive activity:
Software engineers need to work hard to elicit the right
information.

Communication skills are highly needed
30
Making calls
Sending SMS
__
No internet used
No multimedia needed

Needs


VS.


Wants
Requirements
Scope
Challenge: Needs VS. Wants
31
Communication Basic Model
Encode. To translate thoughts into a language that is understood by
others.
Message. The output of encoding.
Medium. The method used to convey the message.
Noise. Anything that interferes with the transmission and
understanding of the message (e.g., distance).
Decode. To translate the message back into meaningful thoughts or
ideas.
32
Communication Modes
33
1. Document Analysis
2. Interface Analysis
3. Prototyping
4. Observation
5. Interviews
6. Brainstorming
7. Focus Groups
8. Requirements Workshops
9. Survey/Questionnaire

Techniques
34
About Elicitation Techniques
Is this a single or multi-stakeholder environment?
o More difficult in multi-stakeholder environment
o Challenging if no consensus
o The SE role is not to make decisions about which
requirement is right, but to create the right conditions and
to facilitate the sessions
Are all the stakeholders located together?
Is this a well understood business environment?
Is it brand new to the Stakeholders ?

35
Different Techniques For Different Stakeholders
1. Working With Executives:
Need to be more conservative with the time they need to spend
with the project
Need to be flexible with scheduling
2. Working With The Users Of The System:
May need to spend time with them while they are performing
their work
May need to show them different scenarios in a prototype
3. When Exploring Regulatory Requirements:
Focus on exploring/reviewing existing documentation
Interviewing SMEs

36
One of the best way to prepare for upcoming events
Provides information about the As Is, no requirements about the
To Be.
Source of information:
System documentation
Enhancement requests
Problem logs
User manuals
Training manuals
Product documentation
Very time consuming process, maps/SME input about how to work
with the documentation is of big help
3.2.1 Document Analysis
37
Most of the systems built today will need to interface other
systems.

May not be enough to only ask the stakeholders about it, they
may be concerned with their part of the system only. Be
proactive and creative

Types:
1. User interface
2. External interface
3. Hardware interface
3.2.1 Interfaces Analysis
38
Dramatically reduces abstractness (unlike other techniques)
Establish realistic objectives about the prototyping scope
Establish realistic expectations, it is just a prototype
You may use 2 types of prototypes regarding how it will evolve:
1. Evolutionary the prototype will gradually get refined and
eventually becomes the final product
2. Throwaway
2 types of prototypes regarding scope:
1. Horizontal shallow but broad the purpose is to include
the many of the functions although a high level of detail
2. Vertical the prototype focuses on a small portion of the
system, but going down into a lower level of detail.
Dont over-engineer the prototype, you may go to a non-
functional prototype.
3.2.3 Prototyping
39
3.2.4 Interviews
May be self-standing technique or a part of another technique
Can be:
Open ended the interviewer starts with predefined questions and
continues the interview based on the input
Close ended (a survey) interview the entire interview is guided by
the list of questions
Look at the interview as a formal event:
Agenda
Objectives
Research and prepare the interview
List the questions
Brief the people prior to the interview
Send the questions ahead of time
Good to have interviewer and scripter
Either Structured or Unstructured
40
Types of Questions
Open ended (tell me about ...) introduce topics that the interviewer
may not have been aware of.
Risks: Stakeholder may loose focus or may not be comfortable with.
Close ended (Do you perform XYZ today?) they keep the
interviewee focused. Many of these questions will come naturally as a
result of the interview progress (active listening)
Probing questions (What do you mean by zero defects?) when there
is a need to clarify/to probe something
Validating questions (Does this flow chart correctly represent this
process?) Stop periodically and rectify/baseline input provided during
the interview
Typical sequence would be:
1. Start with open ended questions
2. Narrow down answers with close-ended
3. Clarify with probing questions
4. Get commitment with validating questions
41
Can be done
Actively (interacting with the stakeholder)
Passively (using video records or one-way mirrors)
Primary used with the end-users of the System being defined to
understand what do they do on daily basis.
Often users are not comfortable of being shadowed they may
do the work differently then they normally do it when not
observed.
You must build trust before applying this technique
It may be very time consuming
You primarly acquire knowledge about the As-Is situation
3.2.5 Observation
42
Work with group of stakeholders to discover (they are advising, not
decision makers)
Used typically to find out what features the most of the user population
is interested in
Needs good facilitation
Set expectations upfront, the participants must be aware that their
recommendations may not end up in the solution
Keep short in time frame to be effective (1-2 hours)
6-12 participants
May work with
Homogeneous group e.g. on a process definition use flowcharting
Heterogeneous group e.g. on a process definition use swim lanes
activity diagrams

3.2.6 Focus Group
43
Typical steps can be:
Clearly state the problem to keep focus
Define the ground rules for the session, e.g. no disagreements are
allowed etc
Start the brainstorming make sure to capture all ideas, it is fine to
clarify ideas, but not to question them
Run the session for a pre-determined amount of time, or until the
team is running dry on ideas
Normalize the list :
1. Combine any duplicates
2. Remove ideas upon agreement
3. Cluster similar ideas
Identify conflicting ideas and make decision
Organize the findings in an easy-to-read-format
3.2.7 Brainstrorming
44
May be used with any other technique
Use the group synergy to generate a lot of ideas and then take the
maximum value out of them
Filter the good ideas at the end
During the session watch out for group dynamics, try to involve all
participants
6-8 participants
45
Facilitated Workshops
JAD = Joint Application Design/Development (IBM, 70s)
Used for capturing, documenting and modeling requirements in a
multi-stakeholder environment
Excellent to build consensus and define requirements
Requires stakeholder buy-in into the process
There must be willingness from the Sponsor to delegate authority
to the group. The group must be authorized to make decisions
(unlike focus group)
JAD session takes significant planning training, and dedication of
resources to be successful.
JAD success depends on the Group
3.2.8 Requirements Workshops
46
Workshop Roles
Facilitator see below
SE/Analyst to ask the right question, works closely with the
facilitator
PM to ensure the project elements are addressed and balanced
(triple constraint)
Scribe makes sure everything to value has been captured,
provides double check for consistency
Participants:
Customer
SME
The Sponsor
47
The Facilitator
To sense how the team is working
To guide the team when the team is struggling
To ensure participation by all stakeholders
The facilitator should be neutral to the outcomes of the project,
should not have interest in the result
The good facilitator will be invisible, the bad facilitator will be
noticed
Key competences:
Strong listening skills
Good speaker
Able to read people (speech and body language)
Calm
48
Good for situations where:
1. there are a large number of stakeholders
2. logistics make it difficult to get together in person.
Help the stakeholders to stay focused on the topic of discussion
Assure the quality of the answers and the return rate (quantity)
Make it short, to the point
Unlike interviews, here you can not ask probing questions
Make questions:
Not ambiguous the stakeholder will understand them correctly
Dont guide to ambiguous answers you will understand them
correctly
You can use a number of question types- MCQs, Rating on scale,
Sequencing, Open answer etc.
3.2.9 Survey
49
Provide a scale for rating. May decide not to include middle
(neutral) value on the scale to encourage decision making
You will likely get not fully representative answers, typically you
will get answers from those:
Who really like you
Who really hate you
Decide on whether to keep it:
1. anonymous (with good quality answers)
2. named (with possibility to follow up if clarification is needed)

50
Technique Synonym When used
Brainstorming Earlys tages - to stimulate creative thinking for ideas generation
Gather large number of ideas (but must keep focus)
Document
Analysis
Review existing
documentation
Understand As-Is. Pre work to Customer interview and other
techniques
Technology change with old business processes
Focus Group Gather a lot of ideas without committing to implementation
Early phase of project
Interface
Analysis
External Interface
Analysis
Understand the big picture. Understand project impact
(May involve people from outside the project team)
Interviews All situations (often is a subset of other techniques)
Observation Job Shadowing Stakeholder requirements; Business analyst new to the domain;
(Requires time committment from both BA and observed)
Prototyping Storyboarding,
Navigation Flow, Paper
Prototyping, Screen
Flows
Reduce abstractness. Bridge language gaps
Do throughout requirements process (used with other techniques)
Requirements
Workshops
Elicitation Workshops,
Facilitated Workshops,
JAD session
Multi stakeholder environment;
Consensus building needed (Large undertaking, requires formal
planning)
Survey /
Questionaire
Wanting to reach a large population; Geographically disbursed
population;
Wanting consistency in interviewing (Realistic expectations on return
rates)
51
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
52
53
4.0 Definitions
This topic is concerned with the process of analyzing
requirements to:
1. Detect and resolve conflicts between requirements
2. Discover the bounds of the software and how it must interact
with its environment
3. Elaborate system requirements to derive software
requirements

Care must be taken to describe requirements precisely enough to
enable the requirements to be validated, their implementation to
be verified, and their costs to be estimated.
54
4.1 Requirements Classification
Requirements can be classified on a number of dimensions.
Examples include:
1. Functional or nonfunctional
2. Derived from high-level requirements or an emergent property, or
imposed directly by a stakeholder or some other source.
3. Product or process requirements
4. The requirement priority meeting the overall goals
Mandatory, Highly desirable, Desirable, or Optional Balanced
against the cost of development and implementation.
5. The scope of the requirement impact on the product
global scope strongly affect the software architecture
narrow scope offer a number of design choices .
6. Volatility/stability: estimate the likelihood of the requirement
changes impact analysis.
55
4.2 Conceptual Modeling
The development of models of a real-world problem is key to
software requirements analysis.

The purpose is to understand the problem not to design a
solution relationships & dependencies.

Several kinds of models data and control flows, state models,
event traces, user interactions, object models, data models

56
4.3 Architectural Design
At some point, the architecture of the solution must be derived.

Architectural design the requirements process overlaps with
software or systems design impossible to decouple the two
tasks.

In many cases, the software engineer acts as software architect
the process of analyzing and elaborating the requirements demands
that the components that will be responsible for satisfying the
requirements be identified.

Architectural design is closely identified with conceptual
modeling.
57
4.4 Requirements Negotiation
Also known as conflict resolution.

Resolving problems with requirements:
conflicts may occur between:
two stakeholders requiring mutually incompatible features
requirements and resources
functional and non-functional requirements
Etc..

Dont make unilateral decisions consensus on trade-offs.
For contractual reasons:
Decisions Customer Responsibility Requirements Validation

58
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
59
5.0 Definitions
The term specification refers to the assignment of numerical
values or limits to a products design goals.
Typical physical systems have a small number of such values.
Typical software has a large number of requirements

Software Requirements Specification production of a document
can be reviewed, evaluated, and approved.
For complex systems, particularly those involving substantial non-
software components, as many as three different types of
documents are produced: system definition, system requirements,
and software requirements.
For simple software products, only the third of these is required.
60
5.1 The System Definition Document
This document (also known as the user requirements document or
concept of operations) records the system requirements.
It defines the high-level system requirements from the domain
perspective. Its readership includes representatives of the system
users/customers (marketing may play these roles for market-driven
software) depends on the domain area.
It lists the system requirements + background information about
the overall system objectives, its target environment, constraints,
assumptions, and non-functional requirements.
It may include conceptual models designed to illustrate the system
context, usage scenarios and the principal domain entities, as well
as data, information, and workflows.
61
5.2 System Requirements Specification
Developers of systems with substantial software and non-software
components. A modern airliner, for example, often separate the
description of system requirements from the description of
software requirements.

In this view, system requirements are specified, the software
requirements are derived from the system requirements, and then
the requirements for the software components are specified.

System requirements specification is a systems engineering
activity.

62
5.3 Software Requirements Specification
Software requirements specification establishes the basis for
agreement between customers and contractors or suppliers on
what the software product is to do, as well as what it is not to do.

For non-technical readers, the software requirements specification
document is often accompanied by a software requirements
definition document.

Software requirements are often written in natural language, but,
in software requirements specification, this may be supplemented
by formal or semi-formal descriptions.


63
IEEE/ANSI 830-1993 Standard Documentation
1. Introduction
1.1 Purpose of requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
Covering functional, non-functional and interface requirements.
4. Appendices
Index

64
Writing Essentials
1. Requirements are read more often than they are written. You
should invest time to write readable and understandable
requirements
2. Do not assume that all readers of the requirements have the
same background and use the same terminology as you
3. Allow time for review, revision and re-drafting of the
requirements document

Writing Guidelines
1. Define standard templates for describing requirements
2. Use language simply consistently and concisely
3. Use diagrams appropriately
4. Supplement natural language with other description of
requirements
5. Specify requirements quantitatively
65
Document Usage
System Customers
Specify requirements and read them to
check that they meet the changes. They also
specify changes to the requirements
Managers
Use the requirements documents to plan a
bid for the system and to plan the system
development process.
System Engineers
Use the requirements to understand what
system is to be developed.
System Test Engineers
Use the requirements documents to develop
validation tests for the system.
System Maintenance
Engineers
Use the requirements documents to
understand the system and the relationships
between them.
66
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
67
6.0 Definitions
Requirements validation is concerned with the process of
examining the requirements document to ensure that it defines
the right software (that is, the software that the users expect).
The requirements documents is subject to validation and
verification procedures.
Requirements are validated to ensure that:
1. The software engineer has understood the requirements
2. The requirements document conforms to company
standards, and that it is understandable, consistent, and
complete
Different stakeholders should review the documents.
Requirements documents are subject to versioning
68
Verification VS. Validation
Verifying Doing the things right

Validating Doing the right things
Verifying Methodologies are OK

Validating Objectives are OK
69
6.1 Requirements Reviews
The most common means of validation is by inspection or reviews
of the requirements documents.

Reviewers should look for errors, mistaken assumptions, lack of
clarity, and deviation from standard practice.

The composition of the group is important (at least one
representative of the customer should be included for a customer-
driven project, for example)

It may help to provide guidance on what to look for in the form of
checklists.
70
6.2 Prototyping
Is also used to validate the SEs interpretation of the software
requirements
Advantage: they can make it easier to interpret the software
engineers assumptions and, where needed, give useful feedback
on why they are wrong.
Ex: The dynamic behavior of a user interface can be better
understood through an animated prototype than through textual
description or graphical models.
Disadvantage: the danger of users attention being distracted from
the core underlying functionality by cosmetic issues or quality
problems with the prototype Several people recommend
prototypes which avoid software, such as flip-chart-based
mockups.
Prototypes may be costly to develop feasibility
71
6.3 Characteristics of Good Requirements
It is essential that the requirements should be Complete,
Clear, Correct, and Consistent (4 Cs).
The requirement is fully stated in one place with no missing information. Complete
The requirement is concisely stated without jargon, & acronyms (unless
defined elsewhere). It expresses objective facts, not subjective opinions.
It is subject to one and only one interpretation.
Vague subjects, adjectives, prepositions, verbs and subjective phrases are
avoided.
Negative statements and compound statements are prohibited.
Clear
If a requirement contains facts, these facts should be true. Correct
The requirement does not contradict any other requirement and is fully
consistent with all authoritative external documentation.
Consistent
72
Other Characteristics
The requirement addresses one and only one thing. Unitary
(Cohesive)
The requirement is atomic, i.e., it does not contain conjunctions. E.g.,
"The postal code field must validate Sudanese and Egyptian postal
codes" should be written as two separate requirements:
1. The postal code field must validate Sudanese postal codes
2. The postal code field must validate Egyptian postal codes
Non-Conjugated
(Atomic)
The requirement meets all or part of a business need as stated by
stakeholders and authoritatively documented.
Traceable
The requirement has not been made obsolete by the passage of time. Current
The requirement can be implemented within the constraints of the
project.
Feasible
The implementation of the requirement can be determined through:
inspection, demonstration, test, and/or analysis.
Verifiable
73
6.4 Acceptance Tests
Software requirement is validated vs. finished product

Requirements which cannot be validated just wishes

An important task is to plan how to verify each requirement
designing acceptance tests

Identifying and designing acceptance tests may be difficult for
non-functional requirements quantitative analysis
74
1. Software Requirements Fundamentals
2. Requirements Process
3. Requirements Elicitation
4. Requirements Analysis
5. Requirements Specification
6. Requirements Validation
7. Practical Considerations
75
7.0 Introduction
Activities & processes are not always linear
The requirements process spans the whole software life cycle.
Change management and the maintenance of the requirements are
key to the success of the software engineering process.
Not every organization has a culture of documenting and managing
requirements:
It is frequent in small companies, driven by a strong product
vision and limited resources, to view requirements
documentation as an unnecessary overhead.
As these companies expand, in terms of customers and products,
they discover that they need to recover the requirements that
motivated product features in order to assess the impact of
proposed changes
76
7.1. Iterative Nature of the Requirements
Process

There is general pressure in the software industry for shortening
the development cycles competition

Most projects are constrained by their environment

It is, sometimes, impractical to implement the requirements
process as a linear, deterministic process in which software
requirements are elicited from the stakeholders, base-lined,
allocated, and handed over to the software development team.

It is certainly a myth that the requirements for large software
projects are ever perfectly understood or perfectly specified.
77
7.2. Change Management
Change management is central to the management of
requirements

It describes the role of change management, the procedures
that need to be in place, and the analysis that should be
applied to proposed changes.


78
7.3 Requirements Attributes
Requirements should consist not only of a specification of what
is required, but also of information which helps manage and
interpret the requirements.

This should include the various classification dimensions of the
requirement and the verification method or acceptance test plan.

It may also include additional information such as a summary
rationale for each requirement, the source of each requirement,
and a change history.

The most important requirements attribute, is an identifier
which allows the requirements to be uniquely and
unambiguously identified.

79
Requirement Attribute:
Requirement ID
[Insert unique identifier for the Requirement, e.g. RQ_xxx_yyy; xxx - project code; yyy - progressive
number ]
Requirement [state the requirement]
Priority
[Specify the relative importance of a requirement to the solution, Common scales include "critical, high,
medium, low" and "must, could, should, would" (MoSCoW method).]
Owner [The stakeholder(s) with the authority to approve a requirement. Owners help determine the priority of the
requirement, since they are responsible for the benefits the requirement will deliver if implemented. Critical for
requirements change management. The owner may or may not be the source.]
Source [The stakeholder(s) from whom the requirement was elicited. Sources may not be owners of the requirements
they provide (e.g. End Users or Customers). Critical for project change management]
Status [State the status of the requirement: draft, reviewed, approved, rejected. Status captures the change or
progress of the requirement within the project and across projects.]
Rationale [Captures the reason why the requirement exists. If project objectives change, the rationale helps provide an
understanding impact of the change on the requirement]
Dependency [Depicts the relationships between requirements where one is dependent on another]
Parent
requirement ID
[Defines a hierarchy of requirements]
Category [A logical grouping of requirements.]
References [References to illustrating material, documents, pictures etc.]
80
7.4 Requirements Traceability

Its purpose is to create and maintain relationships between
business objectives, requirements, other team deliverables, and
solution components to support business analysis or other
activities.

Relationships
After examining and organizing the set of requirements,
record the dependencies and relationships for each of the
requirements.

81
Types of Rraceability:
Backward Traceability Derivation
Forward Traceability Allocation
Comp_1
Comp_2
Comp_3
Comp_n
R1
R2
R3
R4
Requirements
Allocation
Derivation
System Components
82
Traceability is very important in case of:
Change Management:
Impact analysis is performed to assess/evaluate the
impact of a change.
Traceability is a useful tool for performing impact
analysis.
When a requirement changes, its relationships to other
requirements or system components can be reviewed.

Requirements Management System:
A specialized requirements management tool is generally
needed to trace large numbers of requirements.
83
7.5 Measuring Requirements
Practically, it is useful to have some concept of the volume of
the requirements for the software product.

This number is useful in evaluating the size of a change in
requirements, in estimating the cost of a development or
maintenance task, or simply for use as the denominator in other
measurements.

Functional Size Measurement (FSM) is a technique for evaluating
the size of a body of functional requirements.


84
Requirements Volatility:
Is a measure of how much programs requirements change once
coding beings.
Projects for which the requirements change greatly after coding
begins have a high volatility, while projects whose
requirements are relatively stable have a low volatility.

Requirements Volatility Index (RVI):


A = No. of requirements added
D = No. of requirements deleted
M = No. of requirements modified
Approved = No. of initial approved requirements
85