Software Requirements
By Pete Sawyer
Presented by Ehsan Ghaneie
EEL6883 – Software Engineering II
Software Requirements
 Software requirements concern the
specification of software systems
 Software systems are always derived from
some business problem
 They are always embedded in an operational
context
 They have interfaces to human users,
business process elements, or other
hardware/software systems
Software Requirements
 Derivation of software requirements can
rarely be isolated from underlying business
problem
 Software requirements are not a discrete
area of software engineering
 They are part of the system engineering
process known as requirements engineering
Why is it important?
 An effective RE process that minimizes
occurrences of requirement errors is critical to
success of any development project
 The cost of rectifying errors in the
requirements increases significantly as
development proceeds
Requirements and Constraints
 A Requirement defines a property or capability that the system
must exhibit in order for it to solve the business problem for
which it was conceived
 Functional Requirements describe a function that the
system must perform
 Nonfunctional (Extra-Functional) Requirements describe
the qualities of a system


How well the system operates within its environment
The quality of delivery of functional requirements
 Some requirements are emergent properties and dependant on
a wide range of factors some of which are hard to analyze and
control
 Satisfying such requirements depends upon how the whole
system operates within its environment, and not just a particular
system component
Requirements and Constraints
 Requirements are specified at several points
on a spectrum that ranges from those with a
business focus to those with a technical focus
 At the highest level are the goals of a system
that set out in very broad strategic terms what
is needed to solve some business problem

Identifying these needs usually motivates a
development project
Requirements and Constraints
 The next level of requirements define what must be
observable in a black-box system that solves the
business problem

These are called user requirements
 Stakeholder requirements
 System requirements
 The technically focused requirements exist only to
make it possible to satisfy the business focused ones
 Constraints are like negative requirements and act to
limit the set of possible solutions
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Engineering Process
 Is a process that must transform a business
problem into a specification of the properties
of a system that will provide an appropriate
solution to the problem, through a set of
activities
What are the activities?
 The properties that the system must exhibit
must be elicited
 Elicited requirements must be subjected to
analysis to establish a set of requirements
that are correct, complete, and feasible
 This set of requirements must be then
recorded in a specification document that
communicate the requirements to the people
who will use them to develop the software
Requirements Engineering Process
 The documented requirements must be then
validated to ensure the software they specify
will meet the needs of the people whom from
the requirements were elicited
 As development proceeds requirements need
to be managed so that changed are
controlled
Requirements Engineering Process
 This process begins with scoping the system
which involves understanding the underlying
problem that the system is to address,
identifying the goals of the system, and
outlining how it will operate in its environment
 Then the system requirements are elicited
from their sources, analyzed, and validated
 For each software component, further
analysis of the allocated requirements is used
to derive the requirements that fully specify
the software
Requirements Engineering Process
 It is not always possible to capture all the
requirements
 If the product’s environment is volatile, the
requirements will also be volatile

When software products are developed to
compete in the market, the requirements are
likely to evolve with the market
 Other factors such as meeting the release
dates can also affect the RE process
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Elicitation
 Requirements elicitation is the process of
discovering the requirements
 The requirements engineer must identify the
sources of requirements, collect information
about the problem from these sources, and
synthesize requirements from this information
Requirements Elicitation
 Requirements elicitation is not a passive
learning process about what stakeholders
want
 Instead, the requirements engineer must dig
beneath the stakeholders’ accounts for their
concerns, needs, and desires to uncover the
underlying business problem
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Sources
 First step is to identify stakeholders
 Large systems have many stakeholders and they are
usually the main sources of requirements
 Stakeholders must be classified to ensure no
significant sources of requirements are overlooked
 Role of each stakeholder must be understood and a
representative must be selected to work with the
requirement engineer
 Since these people are usually busy people, it is
important to find people who are motivated to act as
“product champions”.
Requirements Sources
 Stakeholders have viewpoints
 These are partial views of the problem
domain which are colored by the
stakeholders’ own role and experience
 This means requirements might be
inconsistent

The requirements engineer must recognize
the scope and limitations of stakeholders’
viewpoints to help resolve inconsistencies and
apply priorities
Requirements Sources
 Stakeholders are not the only sources of
requirements
 Requirements and constraints might come
from the application domain or from business
rules that exists in the organizational
environment
 Key requirements therefore might be hidden
in documents, interface specifications, and
the experience of domain experts
Requirements Sources
 It is important to identify the key requirements that
are derived from the application domain and
therefore domain expertise plays a crucial role in
successful requirements elicitation
 Although stakeholders might be good domain
experts, but they’re not good candidates mostly
because of their view points and often they find it
difficult to articulate the tacit knowledge that
underpins how the domain operates
 If the requirement engineer doesn’t have sufficient
domain expertise and can not be trained within a
reasonable time, domain experts might have to be
brought in from elsewhere to play an active role in the
RE process
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Elicitation Techniques
 Once sources are identified, the process of
collecting knowledge about the problem
begins
 This starts with understanding the
stakeholders’ role in the problem domain, or
basically understanding their jobs
 The requirements engineer must find an
effective way to get the stakeholders analyze
what they need
Elicitation Techniques
 Users’ scenarios provide a valuable tool for
socio-technical systems
 The requirements engineer asks the users to
identify their main tasks, each consisting of a
sequence of events, noting preconditions,
post conditions, communication with
colleagues, and other events that are
involved in the task
Elicitation Techniques
 Elicitation may proceed as a series of
interviews with individual stakeholders
 It is helpful to get them all together (Elicitation
workshops) especially once the problem is
understood. This helps resolving
inconsistencies
 But elicitation workshops are not always the
best solution as some people may be
unwilling or unable to participate or may find
scenarios awkward
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Analysis
 Requirements Analysis is about
understanding the problem and synthesizing
a set of requirements that specify the best
solution
 Analysis is needed to help deepen the
understanding of the problem and what is
required, and to detect and resolve problems
such as inconsistencies and incompatibility
with the requirements
 Elicitation and analysis are closely coupled
Requirements Analysis
 Requirements Analysis will result in a
baseline set of requirements, meaning
requirements that the system will implant
 These are not necessarily everything the
stakeholders asked for.
 The requirements in the baseline should be
necessary and sufficient
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
The System Boundary
 Systems are developed to address some
strategic goal or goals and these goals are
first things that need to be identified
 The scope of the project must be defined
once the goals are identified
 The scope must include a definition of the
system boundaries meaning identifying what
elements of the problem are going to be
addressed by the proposed system
The System Boundary
 Outside the system boundaries are the things
in the system’s environment hat may impose
requirements or constraints
 Within the system boundary are all the
aspects of the problem for which the
proposed system will provide a solution
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Modeling
 Engineers use models to help make sense of
complex information and visualize complex system
properties
 Requirements engineers construct models of the
problem so they can discover suitable solution
requirements
 Models are also used to help describe the proposed
system to help communicate with the developers
 If the dynamic behavior of system can not be
analyzed using static models, simulation can be used
instead
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Why derive more requirements?
 The cost and technical implications of system requirements are
often unclear and this makes them hard to assess and validate
 The requirements elicited from the stakeholders will typically be
expressed in terms of the application domain. The requirements
needed by software developers are technical
 The requirements need to be translated from domain-centric to
software-centric, from abstract to technical
 So it is usually helpful to elaborate the system requirements by
deriving new requirements that focus on more detailed
properties of the proposed system
 One of the motives for deriving more detailed requirements
is understanding the system implications
 The other one is to provide enough details for the developers
Derived requirements
 The derivation of requirements is not confined
to functional requirements
 High-level expressions of non functional
requirements need to be quantified and
transformed into a set of equivalent functional
requirements
 The requirements engineer must choose a
suitable metric and specify how the system
must score against this metric
Derived requirements
 The derivation process should stop when the
requirements are sufficiently specific for


the requirements engineer to be confident that
the requirements are fully understood
the developers to commence solution design
 Getting too detailed leads to premature
design and constraining the design
unnecessarily
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Attributes
 It is insufficient merely to record the
statements of need that express the
requirements
 Requirements have a number of attributes
that should be assigned values in order to
ease their management
 Some of these attributes are:

Identifier, source, date, rationale, type, priority,
stability, verification procedure, and status
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirement Trade-offs
 Requirements from different stakeholders are valid




but mutually inconsistent
Insufficient resources available to satisfy all the
requirements
Stakeholders must be made aware of such conflicts
and be explicitly involved in making the trade offs
Agreeing on requirements’ priorities helps the tradeoff process
Achieving agreement is often easier if stakeholders
are aware of each others’ concern
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Software Requirements Specification
 Projects may use up to three kinds of
“specification” document at different stages of
the RE process
 Concept of Operations (ConOps) document
sets out the projects vision and scope
 System requirements specification defines
the requirements for the whole system
 Software requirements specification (SRS)
specifies the requirements for a software
component or subsystem
Software Requirements Specification
 Each document has a different purpose
 System requirements specification must be
readable by the stakeholders to enable them
to validate the requirements and approve
them as the basis for subsequent
development
 The SRS, by contrast, is primarily a technical
document aimed at the developers. It must
specify the software completely and
unambiguously
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Validation
 Requirements validation can be crudely
characterized as ensuring correctness of the
requirements
 The set of requirements specified in the requirements
specification must accurately reflect what is needed
to solve the underlying business problem
 This concerns not just the correctness of individual
requirements, but the correctness, completeness,
and consistency of the specification as a whole
 The requirements must also conform to appropriate
standards, guidelines, and conventions in order to
ensure the readability, maintainability, consistency,
and other important qualities of a specification
document
Requirements Validation
 In most cases, the requirements are validated
statically
 In some cases in which complex dynamic
behavior is specified, the requirements may
need to be validated dynamically using
prototypes or simulations
 This kind of validation is costly and it should
be done well before the issue of the draft
requirements specification document
Requirements Validation
 Requirements reviews are a mechanism for
validating requirements
 Review panel must include both developer
and stakeholder representatives
 This task can be made easier by including
checklists of things to look for
Requirements Validation
 Another way to validate the requirements is to
write test cases against the requirements
 If it proves excessively hard to plan how a
requirement can be verified then there is
something wrong with the requirement
 Although non functional requirements are
inherently hard to verify, they must be
verifiable if they are to serve any useful
purpose
Requirements Validation
 Once the requirements specification
document has been validated and any
necessary changed have been made, the
requirements specification document will be
“signed off” on
 Although a formal “signing off” may not occur,
it will considerably complicates the
requirements management tasks
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirement Management
 Includes:




Change control
Version control
Requirements tracing
Status tracking
 A fundamental prerequisite for each of these
is that requirements must be uniquely
identifiable
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Change Control
 Changes will always occur after the
requirements specification document has
been signed off on
 It is crucial that change is not permitted to
occur without control
 Uncontrolled or ad-hoc changes to the
requirements will make project planning
impossible resulting in a system that is late
and/or over budget
Change Control
 A change request has to go through a formal
process and cost/benefit analysis has to be
performed before a decision is made to
accept or reject or perhaps postpone it to a
later release
 The implications of NOT approving the
change must also be considered
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Version Control
 Requirements changes must be recorded
 This includes the details of the change, the date of
approval, and the rational for the change, including
the rationale for the decision to approve the change
 Changes then need to be communicated to the
developers and this requires issuing of new versions
of the requirements specification document
 A numbering system for document versions is
essential
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Requirements Tracing
 Requirements must be traced in order to
enable change control, and status tracking
 At a minimum, requirements tracing means
recording the derivation relationships
between requirements
Requirements Tracing
 Tracing should be possible both forward and
backward


Forward tracing is necessary to assess the
impact of requirements down through its
derived requirements and into the components
in which they are allocated
Backward tracing is required so it is possible
to ensure that the system will ultimately solve
the business problem adequately if one of the
derived requirements is changed for any
reason
Software Requirements
 Requirements Engineering Process

Requirements Elicitation



Requirements Analysis








Requirements Sources
Elicitation Techniques
The System Boundary
Requirements Modeling
Derived Requirements
Requirements Attributes
Requirement Trade-offs
Software Requirements Specification
Requirements Validation
Requirements Management




Change Control
Version Control
Requirements Tracing
Status Tracking
Status Tracking
 Requirements can be classified according to
weather they are pending, approved,
rejected, deferred, validated, completed, or
cancelled
 Managing a record of requirements’ status is
important for tracking the project progress
Questions?