2. Software Requirements
Software System Behavior
Relationship between Features and Software
Requirements
The Requirements Dilemma
• Excluding Project Information
• Excluding Design Information
Requirements VS Design
Iteration between Requirements & Design
Characterization Of Requirements
• Functional Requirements
• Non-Functional Requirements
• Design Constraints
Engr. Ali
Presentation
Outline
4
3. Looking Deeper into
Software
Requirements
5
A software requirement is defined as a software capability that must be met or
possessed by a system or a system component to satisfy a contract, standard,
specification, or other formally imposed documentation
Since now, we've been speaking of these requirements things as features and use
cases at a fairly high level of abstraction. It was sufficient to understand the system at a
macro-level view.
However, as we get closer to implementation, additional specificity is required.
Software requirements are those things that the software does on behalf of the user.
The first place to look for Software requirements is around the boundary of the
system, in
addition certain characteristics like performance, reliability etc. also needs to be considered.
4. Software System Behavior
6
Davis [1999] suggests that we need five major classes of things in
order to fully describe the behavior of a software system (Figure 1).
Inputs to the system— not only the contentof the input butalso, as
necessary, the details of input devices and the form, look, and feel of the input.
Outputs from the system— a description of the output devices, such as voice-
output or
visual display, that must be supported, by the system.
Functions of the system— the mapping of inputs to outputs, and their various
combinations.
typica
l
non-
behavioral
requiremen
ts
as reliability,
Attributes of the system—
such maintainability, availability,
etc.
Attributes of the system environment— such additional non-behavioral
requirements as the ability of the system to operate with other applications, loads,
and operating systems.
6. Relationship between Features and
Software
Requirements
8
There is a mapping relationship between features and software
requirements.
Vision Document Feature Software Requirements
Features are simple descriptionsof
systems services described in a
brief form.
Software requirements, represented in any
form, express those features in much more
detailed terms.
The Vision Document cites features
in user’s
language.
The Software Requirements express those
features in technical terms, using one or
more specific Software requirements that
must be fulfilled by the developer in order
to provide the features to the user
7. Relationship between Features and
Software Requirements
9
For example, suppose we are developing a defect-tracking system for a
software development organization.
Table 1 shows the relationship between one of the features identified in
the Vision
document and its associated set of requirements.
This mapping will form the backbone of a requirements management
concept known as "traceability“.
Table 1:: Prioritized Features List
Vision Document Feature Software Requirements
Feature 30: The defect-tracking system will
provide trending information to help the user
assess project status.
SR30.1:Trending information will be
provided in a histogram report showing
time on the x-axis and number of defects
on the y-axis
SR30.2: The user can enter the trending
period
In units of days, weeks or months.
SR30.3: An example trending report is
shown in Attached Figure1.
9. The
Requirement Dilemma : What Vs
How
11
As we have seen, requirements tell the developers what their system must do.
But there's a lot of other information that the requirements should not contain, they
should avoid specifying any unnecessary design or implementation details, or testing
and information associated with project management.
This is "what versus how" paradigm,
where what represents the requirements, and
how represents the design or other project information that is to be implemented to
achieve this objective.
10. The Requirements Dilemma
12
Excluding Project Information
Project-related information (such as schedules, configuration
management plans, verification and validation plans etc.) is
sometimes bundled into the set of requirements for the convenience
of the project manager. In general, this must be avoided since
changes in this information increase volatility and the tendency for
the "requirements" to be out of date.
Schedul
es
Verification and
Validation
11. The Requirements Dilemma
13
Excluding Project Information
The budget could be seen as requirement too; however,
this is another type of information that doesn't fit our
definition and therefore doesn't belong with the overall
system or software requirements.
12. The Requirements Dilemma
14
Excluding Project Information
Information describing how we'll know that the requirements
have actually been met — test procedures or acceptance
procedures— also don't meet the definition and therefore
don't belong in the requirements.
13. The Requirements Dilemma
15
Excluding Design Information
The requirements should also exclude information about the system
design or architecture. Otherwise, you may accidentally restrict your
team from following whatever design options make the most sense for
your application.
Suppose, for example, that the requirement in Table 1 had been worded
like this: "Trending information will be provided in a histogram
report written in Visual Basic, showing major contributing causes
on the x-axis and the number of defects found on the y-axis"
(Figure 2).
Figure 2:: Pareto Chart
14. The Requirements Dilemma
17
If a technical developer decides to insert a reference to Visual Basic because of a
preference for the language, it obviously has no legitimate place in the list of
requirements.
If the customer refuses to pay for a system unless it's written in Visual Basic, the best
course of action is to treat it like a requirement, although we will place it in a special
class, called design constraints.
Nevertheless, it's an implementation constraint that has been imposed on the
development team.
15. Requirements versus Design
18
So far, we have treated software requirements, design decisions, and design
constraints as if they were distinct entities. That is, we have stated or implied
the following.
Requirements (mostly) precede design
Users , because they are closest to the need, make requirements decisions.
Technologists make design decisions because they are best suited to pick, among
the many
design options, which option will best meet the need.
16. Iterating Requirements and
Design
19
In reality, the requirements
versus
desig
n
must be iterative
.
Requirements discovery,
definition, and
desig
n
activities
decisio
ns
are circular.
The
process is a continual give and take, in
that
17. Requirements Specification
21
Two terminologies specification & documentation are used
interchangeably
During elicitation, we informally write the requirements
Now we have to write it in some formal way
We write it formally so that
We can have agreement with customer
We can carry out validation activity
And as a result we can develop software solutions
18. Writing Requirements
22
This document is a starting point for design and development of the software
system.
Typically, requirements documents are written in natural languages (like,
English, Japanese, French, etc.)
Natural languages, by their nature, are ambiguous.
For the help of natural languages, structured languages can be used to
specify requirements
20. University of Toronto Department of Computer Science
Purpose
Communication
explains the application domain and the
system to be developed
Contractual
May be legally binding!
Expresses agreement and a commitment
Baseline for evaluating the software
supports testing, V&V
“enough information to verify whether
delivered system meets requirements”
Baseline for change control
20
Audience
Customers & Users
interested in system requirements…
…but not detailed software requirements
Systems (Requirements) Analysts
Write other specifications that inter-
relate
Developers, Programmers
Have to implement the requirements
Testers
Have to check that the requirements
have been met
Project Managers
Have to measure and control the project
Software Requirements Specification
How do we communicate the Requirements to others?
It is common practice to capture them in an SRS
But an SRS doesn’t need to be a single paper document...
21. University of Toronto Department of Computer Science
Valid (or “correct”)
Expresses the real needs of the
stakeholders (customers, users,…)
Does not contain anything that is not
“required”
21
Unambiguous
Every statement can be read in
exactly one way
Complete
All the things the system must do…
…and all the things it must not do!
Conceptual Completeness
E.g. responses to all classes of input
Structural Completeness
E.g. no TBDs!!!
Understandable (Clear)
E.g. by non-computer specialists
Consistent
Doesn’t contradict itself
Uses all terms consistently
Ranked
Indicates relative importance /
stability of each requirement
Verifiable
A process exists to test satisfaction
of each requirement
Modifiable
Can be changed without difficulty
Good structure and cross-referencing
Traceable
Origin of each requirement is clear
Labels each requirement for future
referencing
Desiderata for Specifications
Source: Adapted from IEEE-STD-830-1998
27. Modern SRS Package
23
Historically the most popular technique for documenting requirements was to use
natural language.
This technique was revised and improved and eventually a number of standards
developed for these documents, including IEEE 830 standard for Software
Requirements Specification.
The modern SRS package plays no of crucial roles::
It serves as a basis of communication among all parties
It represents an agreement among all parties
It serves as a project manager’s reference standard
It serves as input to the design, implementation and testingteams
It controls the evolution of the system throughout development phase of
the project
28. Modern SRS Package
24
Software Requirements
Specification
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
30. Modern SRS Package
26
Table of Contents
1 Introduction
This section should provide an overview of the supplementary
specification and should contain the following subsections
1. Purpose
Specify the purpose of this SRS. The document collects and organizes
all the requirements of the system. These include functional
requirements, nonfunctional requirements, and design constraints.
2. Scope
State the scope of the document and any systems or subsystems to
watch it applies.
31. Modern SRS Package
27
3. Definitions, Acronyms, and Abbreviations
Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the specification document. This information may be provided by reference
to a project glossary.
4. References
This subsection should
Provide a list of all documents referenced elsewhere in the specification
Identify each documentby title, report number (if applicable), date, and
publishing
organization
Specify the sources from which the references can be obtained
32. Modern SRS Package
28
5. Assumptions and Dependencies
List any assumed factors (as opposed to known facts) that could affect the requirements
stated in the SRS. These could include third-party or commercial components that you plan
to use, issues around the development or operating environment, or constraints.
The project could be affected if these assumptions are incorrect, are not shared, orchange.
Also identify any dependencies the project has on external factors, such as software
components that you intend to reuse from another project etc.
33. Modern SRS Package
29
2 Use Case Model Survey
This section provides an overview of the use case
model
This section lists for each use case
The Use case name
Brief description explaining use case’s function
A list of actors for the use case
Diagram of the use case model
3 Actor Survey
This section lists the following information for
each actor
The Actor’s name
Brief description of the actors
34. Modern SRS Package
30
4 Requirements
4.1 Functional Requirements
Itemize the detailed functional requirements associated with the features of vision
document
These are the software capabilities that must be present in order for the user to
carry out the
services provided by the feature.
Include how the product should respond to anticipated error conditions or invalid
inputs. Requirements should be concise, complete, unambiguous, verifiable, etc.
Each requirement should be uniquely identified with a sequence number or a
meaningful tag of
some kind.
REQ-1:
REQ-2:
35. Modern SRS Package
31
4 Requirements
4.2 Non-Functional
Requirements
produc
t
should be
listed
All the non functionalrequirements
associated with the here
The Non- Functional Requirements can be of the
following::
Usability
Reliability
Performanc
e
Supportabili
ty
Safety
Security
36. 32
5
Use
r
Documentati
on
and
Hel
p
Syste
m
Requireme
nts
use
r
Describes the requirements if any for
online documentation, help
systems, help notices and so on
6 Design
Constraints
This section includes any design constraints on the
system being built.
Design constraints represent design decisions that
have been mandated and must be adhered to.
Examples include software languages, prescribed
use of developmental tools, specific architectural
constraints, mandated use of class libraries, and
so on.
Modern SRS Package
37. 33
7 Purchased Components
This section describes any purchased components to be used with
the system
8 Interfaces
the
interface
s
tha
t
mu
st
be
supporte
d
by
th
e
This section
defines application
1. User Interfaces
2. Hardware
Interfaces
3. Software Interfaces
8.4 Communication
Interfaces
Modern SRS Package
38. 34
9 Licensing and Security
Requirements
This section includes any licensing
requirements
and accessibility, encryption
of
This section may also define
requirements for security source code or user
data, and so on.
disclaimers, including
warranties,
10 Legal, Copyright, and Other
Notices
This section includes any necessary
legal copyright notices, patent notices, or logo.
the
specific
11 Applicable Standards
This section includes by reference
any sections of any such standards
that apply
applicable standards
and to the
system being built.
Modern SRS Package
39. 35
is provided to assistthe reader in
locating
concepts and topics that occur
throughout the
Index
The
index
the key
documen
t
Glossar
y
Define all the terms necessaryto properly
interpret
the SRS, including acronyms and abbreviations or
other
project or company specific terms necessaryfor
the
understanding of this document and the
application
Appendixes
It includes the details of use case diagrams (Flow of
events, additional paths, preconditions, post
conditions etc.)
Also include other diagrams like ERD diagrams, class
diagrams, state-transition diagrams, Sequence
diagrams etc.
Modern SRS Package