Capturing The
Requirements
By Darren Quichocho
CEN 4020
Software Engineering
1
Requirements
What is a requirement?
◦ An expression of desired behavior
◦ Deals with objects or entities, the states they can be in, and the
functions that are performed to change those states and
characteristics
◦ It is important to note that the requirements focus on the
customer and the problem, not on the solution or
implementation
2
Forms of Requirements
Requirements can loosely be prioritized into three categories
◦ Essential – requirements that must be absolutely met
◦ Desirable – requirements that are highly desirable but not necessary
◦ Optional – Requirements that are possible but could be eliminated
We’ll use a credit card billing system as an example
◦ Essential – list current charges, sum them, and request payment
◦ Desirable – the ability to separate the charges by purchase-type
◦ Optional – Printing the credits and debits in different colors
3
Steps of Capturing
Requirements
The requirements are usually decided by a Requirements Analyst or a Systems
Analyst
The end result is a Software Requirements Specification (SRS)
◦ Used to communicate to other software developers how the final product should behave.
4
How Users and Developers
View Each Other
Identifying the requirements
that the user or customer
wants is not always easy.
Often, the customer does not
actually know what they want
or simply cannot accurately
describe their needs. In the
same way, developers may not
always understand business
concerns or jargon. As a result,
the process of eliciting
requirements can be lengthy.
5
Types of Requirements
Functional – describes required behavior in terms of required activities
such as reactions to inputs or the state of each entity before and after
an activity occurs
Quality or Nonfunctional – describes some quality characteristic that
the software solution must process such as fast response time, ease of
use, high reliability, or low maintenance cost
Design Constraint – a design decision, such as choice of platform or
interface components, that has already been made and that restricts
the set of solutions to the problem
Process Constraint – a restriction on the techniques or resources that
can be used to build systems
6
Requirements Documents
Requirements Definition – a complete listing of everything the customer
wants to achieve
◦ Aimed at a business audience, such as clients, customers, and users
◦ Typically written jointly by the client and the requirements analyst
◦ Written entirely in terms of the environment, describing how the
environment will be affected by the proposed system
Requirements Specification – restates the requirements as a
specification of how the proposed system shall behave
◦ Aimed at a technical audience, such as designers, testers, and project
managers
◦ Also written in terms of the environment, except that it refers solely
to the entities that are accessible to the system
◦ Written by the requirements analyst and used by developers
7
Requirements Documents
Below is a depiction of the separation between the requirements
definition and the requirements specification
8
Importance of Requirements
Analysis
If the requirement analysis phase is not completed properly or in a
sluggish manner then there might be inconsistencies in the final
product.
Top Factors of Failed Projects:
1. Incomplete Requirements (13.1%)
2. Lack of User Involvement (12.4%)
3. Lack of Resources (10.6 %)
4. Unrealistic Expectations (9.9%)
5. Lack of Executive Support (9.3%)
6. Changing Requirements and Specifications (8.7%(
7. Lack of Planning (8.1%)
8. System No Longer Needed (7.5%)
9
Characteristics of
Requirements
1. Are the Requirements Correct?
◦ Both the developer and the customer should agree on the set of
requirements
2. Are the Requirements Consistent?
◦ Requirements are inconsistent if they are impossible to satisfy
simultaneously
3. Are the Requirements Unambiguous?
◦ Requirements are ambiguous if multiple people can read them and
walk away with different but valid interpretations
4. Are the Requirements Complete?
◦ They are complete if it specifies required behavior and output for all
possible inputs in all possible states under all possible constraints
10
Characteristics of
Requirements
4. Are the Requirements Consistent (cont.)?
◦ Externally Complete – all states, state changes, inputs, products, and
constraints are described by some requirements
◦ Internally Complete – no undefined terms among the requirements
5. Are the Requirements Feasible?
◦ Feasibility comes into play when a customer requires two or more quality
requirements. For example, they want an inexpensive system that analyzes
huge amounts of data and outputs an analysis in seconds.
6. Are the Requirements Relevant?
◦ Need to stay focused on essential and desirable requirements. Requirements
that are not relevant can end up limiting the developer
11
Characteristics of
Requirements
7. Are the Requirements Testable?
◦ Testable if they suggest acceptance tests that would clearly demonstrate
whether the eventual product meets the requirements
8. Are the Requirements Traceable?
◦ The requirements should be organized and uniquely labeled for easy
reference
12
Modeling Notation
Entity Relationship Diagram (ER Diagram) – graphical notational
paradigm used to model the relationships among objects in a problem
description or to model the structure of a software application
Entity (rectangle) – objects with
common properties or
behaviors
Relationship (diamond) –
specifies type of relationship
between entities
Attribute (annotation) –
describes data or property of
an entity
13
Modeling Notation
Unified Modeling Language (UML) – collection of notations used to
document software specifications and designs
◦ Typically uses a class diagram – a sophisticated ER diagram relating
the classes in the specification. Each class has a name, a set of
attributes, a set of operations
◦ Class-scope attribute – (underlined attribute) a data value that is
hared by all instances of the class
◦ Class-scope operation – (underlined operation) operation performed
by the abstract class on a new instance
◦ Association
◦ Aggregate – “has a” association represented by a white diamond
◦ Generalization – “is a” association represented by a triangle on one end
◦ Association Class – relates attributes and operations to an
association
14
Modeling Notation
An
example
UML chart
15
Modeling Notation
Event Trace – a graphical description of a sequence of events that are
exchanged between real-world entities. Traces are preferred because of
they are relatively precise but also easy to understand
The trace on the left represents typical behavior and the trace on the
right represents the expected behavior
16
Modeling Notation
Message Sequence Charts – an enhanced event-trace notation with
facilities for creating and destroying entities, specifying actions and
timers, and composing traces
◦ Vertical line represents a participating entity
◦ A message is depicted as an arrow from the sending entity to the
receiving entity
◦ Actions are specified as labelled rectangles positioned on an entity's
execution line
◦ Conditions are important states in an entity's evolution, represented
as labelled hexagon
17
Modeling Notation
Message Sequence chart for a library loan transaction
18
Modeling Notation
State Machines – a graphical description of all dialog between the
system and its environment. Useful in representing dynamic behavior
State – each node
represents a stable set of
conditions that exists
between event
occurrences
Transition – represents a
change in behavior or
condition due to the
occurrence of an event
Deterministic – a state
machine is deterministic if
for each state and event
there is a unique response
19
Modeling Notation
UML State Chart Diagram – depicts the dynamic behavior of the objects
in a UML class. Gives a static big picture view of a problem
Uses state hierarchy to
simplify diagrams by using
superstates which combine
states with common
transitions
A superstate can be thought
of as a submachine
Submachines operate
concurrently, meaning that
an instance could at any time
receive and respond to
events of interest to either
submachine
20
Modeling Notation
Petri Nets – a form of state transition notation that is used to model
concurrent activities and their interactions
◦ Circles (places) represent activities or conditions
◦ Bars represents transitions
◦ Arcs connect a transition with its input places and its output places
◦ The places are populated with tokens, which act as enabling
conditions for the transitions
◦ Each arc can be assigned a weight that specifies how many tokens
are removed from arc's input place, when the transition fires
21
Modeling Notation
Petri Net for the behavior of a book loan
22
Modeling Notation
Data Flow Diagram (DFD) – models functionality and the flow of data
from one function to another
◦ A bubble represents a process
◦ An arrow represents data flow
◦ A data store: a formal repository or database of information
◦ Rectangles represent actors: entities that provide input data or
receive the output result
23
Modeling Notation
DFD for a
library loan
system
24
Modeling Notation
Use-Case Diagram – depicts observable, user initiated functionality in
terms of interactions between the system and its environment
25
Modeling Notation
Formal Methods or Approaches – mathematically based specification
and design techniques.
◦ Model requirements or software behaviour as a collection of
mathematical functions or relations that map systems inputs to
system outputs
◦ Encouraged by many software engineers who build safety critical
systems
◦ For example, Defence Standard 00-56, a British standard for
building safety critical systems, requires that formal specification
and design be used to demonstrate required functionality,
reliability and safety
26
Modeling Notation
Decision Tables – a tabular representation of a functional specification
that maps events and conditions to appropriate responses or actions
Specification is
informal because the
inputs and outputs
may be expressed in
natural language, as
mathematical
expressions, or both.
Useful in examining
consistency and
correlations
27
Modeling Notation
Parnas Tables – tabular representations of mathematical functions or
relations. A collection of table types and abbreviation strategies for
organizing and simplifying functional and relational expressions
◦ The column and row headers are used to specify cases
◦ The internal table entries store the possible function results
◦ An entry “X” either could be invalid under the specified conditions or
the combination of conditions is infeasible
28
Modeling Notation
First Order Logic – commonly used to express properties of software
requirements. Comprising typed variables, constants, functions,
predicates, like relational operators, equality, logical connectives, and
quantifiers.
Temporal Logic – introduces additional logical connectives for
constraining how variables can change value over time
Object Constraint Language (OCL) – an attempt to create a constraint
language that is both mathematically precise and easy for
nonmathematicians, like customers, to read, write, and understand
29
Modeling Notation
A partial library
class model
with three
classes
annotated with
OCL constraints
30
Modeling Notation
Z – (pronounced “zed”) a formal requirements-specification language
that structures set-theoretic definitions of variables into a complete
abstract-data-type model of a problem , and uses logic to decompose a
specification into manageably sized modules, called Schemas.
◦ Schemas specify:
◦ The system state in terms of typed variables, and invariants on
variables values
◦ The systems initial state
◦ Operations
◦ Z offers the precision of a mathematical notation, such as being able
to evaluate specifications using proofs or automated checks
31
Model Notation
Library example specified in Z
32
Prototyping Requirements
Throwaway Prototype – software that is developed to learn more about
a problem or about a proposed solution and is never intended to be
part of the delivered software
Evolutionary Prototype – software that is developed not only to help us
answer questions but also to be incorporated in the final product
Rapid Prototyping – both throwaway and evolutionary prototype are
sometimes referred to as rapid prototyping because they involve
building software in order to answer questions about the requirements
33
Prototyping Requirements
A slightly more
developed
calendar-based
prototype
A simple
representation
of a key-board
entry
prototype
A more sophisticated
prototype that will
most likely provide
the fastest selection
34
Documenting Requirements
It is important to keep a set of documents that defines the
requirements. These documents need to be clear and contain precise
diagrams so that both the customer and the developer may refer back
to them throughout the development process. Consistency is key in
documenting requirements.
As we discovered before there are two main documents:
◦ Requirements Definition
◦ Requirements Specification
35
Documenting Requirements
Requirements Definition
1. Outline general purpose and scope of the system
2. Describe background and rationale for proposal
3. Describe essential characteristics and core functionality of solution
4. Describe the environment in which the system will operate, taking
into account the background and capability of the intended user
5. Evaluate customers proposal for the problem checking for design
constraints
6. Describe any assumed environmental conditions that could cause the
system to fail
36
Documenting Requirements
Requirement Specification
1. Document system interface, describing all inputs and outputs in
detail, including sources, destinations, data formats, and timing
constraints.
2. Restate the required functionality in terms of the interfaces inputs
and outputs. This can include data-flow diagrams, state machines, event
traces, and entity-relationship diagrams.
3. Devise fit criteria for the quality requirements to demonstrate
whether the system meets the needs of the customer.
37
IEEE Standards for
Requirements Specification
An IEEE SRS should follow the general format
below. To the right is a more detailed example
using classes and objects.
1. Introduction
◦ Purpose
◦ Scope
◦ Definitions, acronyms, and abbreviations
◦ References
◦ Overview
2. Overall description
◦ Product perspective
◦ Product functions
◦ User characteristics
◦ Constraints
◦ Assumptions and dependencies
3. Specific requirements
1. Introduction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
2. General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
4. Appendices
38
Participants and Their Roles
Clients: pay for the software to be developed
Customers: buy the software after it is developed
Users: use the system
Domain experts: familiar with the problem that the software must
automate
Market Researchers: conduct surveys to determine future trends and
potential customers
Lawyers or auditors: familiar with government, safety, or legal
requirements
Software engineers or other technology experts: design the system
39
Validation and Verification
It is essential for the requirements to meet the customers needs. As a
result we must verify and validate them before starting development.
Requirements Validation – checks that our requirements definition
accurately reflects the customers needs.
Requirements Verification – we check that one document conforms to
another, that is, we check that the code conforms to the design, and
that the design conforms to the requirements specification.
In short, validation checks that we build the system right, and
verification checks that we build the right system.
40
Validation and Verification
Validation
Walkthroughs
Readings
Interviews
Reviews
The table provided
lists techniques
that can be used
validate and verify
requirements
Checklists
Models to check functions and
relationships
Scenarios
Prototypes
Simulation
Formal inspections
Verification
Cross-referencing
Simulation
Consistency checks
Completeness checks
Check for unreachable states of
Checking
transitions
Model checking
Mathematical proofs
41
Measuring Requirements
Measuring requirements usually focuses on 3 aspects:
1. Product
2. Process
3. Resources
It is also important to track:
◦ Requirements size – give us a sense of the size of the system
◦ Requirements Change - the number of changes can indicate and
unstable system or an uncertain understanding of the system.
◦ These should both be tracked by requirements type.
42
Measuring Requirement
Each requirement can also be rated on a scale of 1 to 5
1. You understand this requirement completely, have designed systems
from similar requirements, and have no trouble developing a design
from this requirement
2. Some elements of this requirement are new, but they are not
radically different from requirements that have been successfully
designed in the past
3. Some elements of this requirement are very different from
requirements in the past, but you understand the requirement and
can develop a good design from it
4. You cannot understand some parts of this requirement, and are not
sure that you can develop a good design
5. You do not understand this requirement at all, and can not develop a
design
43
Choosing Specification
Techniques
Criteria for selecting specification techniques:
◦ Verifiability
◦ Applicability
◦ Runtime Safety
◦ Implementability
◦ Tools Maturity
◦ Testability
◦ Looseness
◦ Checkability
◦ Learning Curve
◦ Maintainability
◦ Technique Maturity
◦ Modularity
◦ Discipline
◦ Level of Expressability
◦ Soundness
44
Sources
http://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf
http://modeling-languages.com/how-users-and-programmers-seeeach-other/
Software Engineering: Theory and Practice
S. L. Pfleeger and J. M. Atlee​
Prentice Hall, Latest Edition
45