Software Requirements
Specification
CS 4310
Fall 2012
Davis, A., Software Requirements. Prentice Hall, 1993.
Peters, J. and W. Pedrycz, Software Engineering An
Engineering Approach. John Wiley and Sons, 2000.
Requirement




A requirement is a user need or a necessary
feature, function, or attribute of a system that can
be sensed from a position external to that
system.
Describes what and not how.
Uses the word shall.
Examples:


The system shall display the current location of a ship.
The system shall generate a dial tone within 5 seconds after a
person picks up the receiver.
Software Requirements Specification (SRS)
SRS is a document containing a complete
yet concise description of the entire external
interface of the system with its environment
including other software, communication
ports, hardware, and human users.
 Carves universe into two sets



All systems satisfying user’s real needs
All systems that do not satisfy user’s real needs
SRS-1
 Communication
among customers,
users, analysts, and designers
Defines external behavior of system (cannot be
ambiguous)
 May give design to help with understanding but
developers are not bound by design

SRS-2
 Support for system testing activities
 Primary input to system test planning and
generation
 Test to check if system meets requirements
 Means
of controlling evolution of
system

Check if modification is new refinement or
existing
Structure of an SRS
IEEE Std. 830-1993
 Review of template

Types of Requirements
 Behavioral:
define what the system
does; inputs, outputs, and
transformation of inputs to outputs
 Nonbehavioral: define the attributes
of the system as it performs its job,
e.g., efficiency, reliability, security,
maintainability, portability, and
standards of compliance
Groupings of Requirements
 Related
to same class of user
 Related to same real-world object
 Related to same external
stimulus/response
 Related to same system feature
 Related to same class of function
 Weakest
of all groups
Attributes of a Well-Written SRS-1
 Correct
iff every requirement stated
therein represents something required
of the system to be built.
 Unambiguous iff every requirement
stated therein has only one
interpretation.
Attributes of a Well-Written SRS-2
 Complete if it possesses the following:
 Everything that the software is suppose to do is
included in the SRS.
 Definitions of responses of software of all
realizable classes of input data in all realizable
classes of situations are included
 All pages are numbered, all figures and tables
are numbered, named, and referenced; all terms
and units of measures are provided.
 No sections are marked TBD
Attributes of a Well-Written SRS-3
Verifiable (SRS) iff every requirement stated
therein is verifiable. A requirement is
verifiable iff there exists some finite costeffective process with which a person or
machine can check that an actual as-built
software product meets the requirements.
 Example requirements that are not
verifiable:




The product shall have an easy-to-use interface.
The program shall not enter an infinite loop.
Avoid words such as “usually”, “generally,” or “often”
Attributes of a Well-Written SRS-4

Consistent iff no requirement stated therein
is in conflict with other preceding documents
and no subset of requirements stated
therein conflict.




Conflicting Behavior: Specify different stimuli to induce a
response or different responses to the same stimuli
Conflicting Terms: Terms used in different contexts to
mean the same thing.
Conflicting Characteristics: Demand the product to
exhibit contradictory traits
Temporal inconsistency: Demand the product to obey
contradictory timing characteristics
Attributes of a Well-Written SRS-5
 Traced
if origin of requirements is
clear.
 Traceable if the SRS is written in a
manner that facilitates the referencing
of each individual requirement stated
therein.
Nonbehavioral Specifications
Non-behavioral Characteristics
Portability
 Reliability
 Efficiency
 Human Engineering
 Testability
 Understandability
 Modifiability

Portability
Degree to which software running on one
host computer environment can be
converted to run on another.
 Not necessary for all applications
(embedded systems, single-use systems).
 Some applications, it is essential.

Problems with specification

May be impossible to quantify: “The
maximum time to port to host system X
shall be …”
We don’t know what the next generation will
be;
 The maximum time is not useful: it doesn’t
affect the design of the system.

Approaches to Specifying
Portability



Source language
 Java: JVM ported to lots of platforms
 Ada: DoD certifies – no extentions, no subsets
 Ideally, language is a design issue, but if its
effect on portability is critical, it’s a
requirement
 Language selection tends to be political in
organizations
Host operating systems
 Say which ones up front, if you know
Compiler selection
 Ansi Standard compilers
Reliability


This is difficult in software:
“The system shall be 99.999% reliable.”
 What does this mean?
 It could mean that the phone system may lose
a call now and again, but the entire system
must not fail for more than 5 minutes a year.
 In a patient monitoring system, it may mean
that if it does go down, it alerts staff. It must
not make a mistake in monitoring more than
one patient in 100,000.
Traditional reliability
(hardware)



Mean Time to Failure (MTTF)
 MTTF of system is well defined in terms of MTTF
of components.
 Redundant components improve reliability
because failure of components is independent.
Hardware degrades in its environment.
Bathtub curve for electronics over entire population of
products.
Burn-in
failures
time
MTTF and Software

Software doesn’t degrade over time.

Suppose you run a program for 10 years
without failure, then it suddenly fails. Why?
 Software
was changed.
 Software was used a new way.
Bugs



Failure: Software does not do what is required
(specified). Behavior is different from that
needed.
Fault: A cause of a failure.
 Not all faults result in failure.
 All failures result from faults.
 A state in which there is a fault without a
failure is a hazard state.
Error: A design or implementation flaw.
Testing
The purpose of testing is not to
demonstrate correct execution of the
program.
 The purpose of testing is to discover faults.

Problems specifying reliability in
terms of bugs


Assume quality is designed in from the start:
 The software testing shall require no more
than two months.
 Software testing shall discover no more than
10 bugs.
The software shall have no more than one bug
per thousand lines of code.
 We want zero bugs, so this must be better
than 5 per 1000.
 How do we know how many there are? Wait
until software is retired, then count them.
Fault Seeding
Before testing, insert some bugs
 Track how many of these are found in
testing.
 Total bugs in system =
(#seeded *
total_detected)/seeded_detected

Example
Secretly seed 10 bugs.
 Test team discovers 120 bugs, 6 of which
are seeds.
 Bugs = 10 * 120 / 6 = 200 bugs
 # bugs remaining = 200 – 120 = 80, 4 of
which are “known”.

Notes

Not all bugs are equal
Equally difficult to find
 Equally difficult to repair


Seeding is harder than it looks.
Intuitive
 Measure of testing effectiveness

Reliability

Levels of criticality
 Cause mild inconvenience
 Cause minor financial loss
 Cause major embarrassment
 Cause major financial loss
 Injure people
 Kill a few people
 Kill many people
 Destroy humankind
Example Reliability Requirement



No more than five bugs per 10K lines of
executable code shall be detected during
integration and system testing.
No more than ten bugs per 10K lines of
executable code shall remain in the system after
delivery, as calculated by the Monte Carlo
seeding technique defined in Appendix III.
The system shall be 100% operational 99.9% of
the calendar time during its first year of
operation.
Efficiency


The utilization of scarce resources.
 Memory
 CPU
 Disk
 Communication
Easy to specify if limits are given
 Example: Air Traffic Control system: The
system shall trace the movements of up to fifty
aircraft.
Need to say how it will degrade:

What if there are 51 aircraft? Possibilities:
Software fails.
 Track first 50, ignore 51st.
 Software notifies 51st pilot to leave area.

Human Engineering: Levels of
Specification
The system shall have an easy-to-use
human interface.
 The system shall be menu driven.
 The system shall be menu-driven.
Appendix A shows sample menus.
 The system shall be menu-driven.
Appendix A shows all menus to be used.

Human Engineering: Error
Messages
Unless there is a sound understanding of
the types of error messages the system
can generate, there is insufficient
knowledge of the system’s expected
normal behavior.
 It is a good idea to have an appendix that
specifies the text of all error messages.

Testability, Modifiability,
Understandability
Very difficult to quantify.
 These are important contributors to cost
(maintenance).
 One suggestion is to specify conformity to
a set of programming standards.

Programming standards specify







Naming conventions
Invocation conventions
 Calls, interrupts, synchronization
 Message formats
Component headers
 Format and content
In-line documentation style
Use of global constructs and variables
Use of named constructs
Modularity standards
TEAM WORK
(modified from IEEE SE Problems)

Irbis is gathering the requirements for a softwarecontrolled furnace. After interviewing several users, Irbis
obtained the following requirements:





R1: Gas intlet valves shall always be open when furnace is
heating.
R2: Heating shall stop when furnace temperature reaches
150°C.
R3: Furnace temperature should increase gradually when
heating.
R4: The gas inlet valves shall be closed when the temperature
goes above 200°C.
In teams of 3, for each of the requirements:



identify the requirement’s defects.
Provide a fix to address the requirement’s defects.
Indicate in which section of the SRS will you place the