Software Engineering Principles

Lecture 2

IEEE – Software Requirements

Specifications
 Lesson 02 - IEEE Software

About Requirements

In the last lesson, we learned about

•  The reason(s) why we need requirements
•  Formalizing and documenting requirements
•  Possible ways to gather requirements
•  The characteristics of good requirements
•  In this lesson, we will
•  Talk more about the characteristics of requirements
•  How the IEEE 830-1998 Specification can help
ensure that requirements are documented properly
The Life of a Project …

software projects run …

•  FYI … The reason that the project may be run
this way is not entirely because of lack of
requirements and poorly documented
requirements … but these definitely
contribute!
The Life of a Project:

How The Customer
Explained It
How The Project Leader Understood It
How The Analyst Designed It
How The Programmer Wrote It
How The Business Consultant Described It
How The Project Was Documented
What Operations Installed the Project
How The Customer Was Billed
How It Was Supported
What The Customer Really Needed
As we discussed in the previous lesson, in order to
avoid
•  project chaos
•  development mayhem
•  customer dis-satisfaction
we need to properly, accurately and correctly document
our Software Requirements !

You will be using the IEEE Std. 830-1998 as a format for

this assignment.
IEEE Standards
Many of the following statements are taken directly from the
standard.
The Nature of the SRS
While writing an SRS, the basic ideas and issues that you
must
address are :
•  Functionality
•  What is the software supposed to do?
•  External Interfaces
•  How does the software interact with people, the system's hardware, other
•  hardware, and other software?
•  Performance
•  What is the speed, availability, response time, recovery time, etc.?
•  Attributes
•  What are the portability, correctness, maintainability, security,
etc. considerations?
•  Design constraints
•  Are there any required standards in effects, implementation language,
policies for database integrity, resource limits, operating environments,
etc.?
Where the SRS is used in the overall Project
The SRS plays an important role in the life of a software
project and as such, it is very important that the SRS
correctly define all of the software requirements so that
anyone reading the document will know exactly
•  What the software will do
•  What the software won’t do
•  How it will operate and in what modes
•  What will happen as a user interacts with it etc.
•  Does not describe any design or implementation
details
•  Does not impose additional constraints on the
software
Characteristics of a Good SRS
› Correct
› Unambiguous
› Complete
› Consistent
› Ranked for importance and stability
› Verifiable
› Modifiable
› Traceable

In a software project, the SRS forms the cornerstone of

understanding of the software product !!
Prototyping
› In real projects, it is quite a common technique and
practice to construct (somewhat) workable prototypes
of the system / program during the requirements
gathering phase
› This is a useful idea because:
•  the customer may be more likely to view the
prototype and react to it than to read the SRS
•  it displays unanticipated aspects of the system's
behaviour
•  an SRS based on a prototype tends to undergo
less change during development
The Structure of an SRS*
› Table of Contents
› 1. Introduction › 3. Specific Requirements
› 1.1 Purpose › 3.1 External Interfaces
› 1.2 Scope › 3.2 Functions
› 1.3 Definitions, Acronyms, and › 3.3 Performance Requirements
Abbreviations › 3.4 Logical Database Requirements
› 1.4 References › 3.5 Design Constraints
› 1.5 Overview › 3.6 Software System Attributes
2. Overall Description › 4. Appendices
› 2.1 Product Perspective › 5. Index (not required for this assignment)
› 2.2 Product Functions
› 2.3 User Characteristics
› 2.4 Constraints
› 2.5 Assumptions and Dependencies
› 2.6 Apportioning of Requirements
* NOTE : These are the sec-ons that will be in your final SRS for Assignment 1
Section 1 – Introduction
This entire section and all of its subsections are about the
SRS itself
•  The purpose of the SRS
•  Who should read the SRS
•  How to read the SRS
•  Research and sources used in creating the SRS
•  Definition of terms and acronyms used in the SRS

› As a result, Section 1 is usually the smallest section in

the entire SRS
1.1 - Purpose
›
Should:
•  Delineate the purpose of the SRS
› Why is this document being written ? Should mention the
system / product being documented and perhaps a brief
description of why this system needs to be created.
•  Specify the intended audience for the SRS
› Who should be reading this document ? Executives,
customers, product managers, developers, etc. ?
1.2 – Scope

› Should:
•  Identify the product to be produced by name
•  Brief explanation what the product will and, if necessary, will
not do
•  Describe the application of the software being specified,
including relevant benefits, objectives, and goals
•  Be consistent with similar statements in higher-
level specifications if they exist

› NOTE The descriptions and explanations in this section should be

fairly high level and not get into too many specifics
 Lesson 02 - IEEE Software
Requirements Specification

1.3 - Definitions, Acronyms, and Abbreviations

•  Define all terms, acronyms and abbreviations found within

the SRS
•  Not all of the document’s audience are technical people and may not
know exactly what every acronym or term means.
•  Including this section makes the document more readable by a
wider audience
 Lesson

1.4 - References
› Should:
•  Provide a complete list of all documents referenced elsewhere
in the SRS
•  Identify each document by title, report number (if applicable),
date, and publishing organization – using the APA standard
•  Specify the sources from which the references can be
obtained
1.5 - Overview
› Should:
• ›Describe what the rest of the SRS contains
• ›Explain how the SRS is organized
•  Tell the reader what will be found in Sections 2 and 3 of the
SRS and how they are laid out – perhaps even the intended
audience for each of the sections … you are trying to tell
the audience what and how to read the rest of the SRS
Section 2 – Overall Description

•  This section of the SRS should describe the general

factors that affect the product and its requirements
›
•  This section does not state specific requirements
Instead, it provides a background for those requirements,
which are defined in detail in Section 3 of the SRS, and
makes them easier to understand

•  Think of Section 2 as a high-level overview when it

comes to defining the functionality and purpose of the
software
2.1 - Product Perspective
Should put the product into perspective with other related
products
•  If the software being defined and specified is part of a larger
system – then make sure to say this here. Also talk about
the larger system and give references to documents about it
•  If the software being defined is self-contained then this
should be stated here
•  It can be beneficial to include a block (CONTEXT)
diagram of the system showing the major components,
the interconnections and the external interfaces
› This subsection should also describe how the software
operates and interacts with the world around it by
describing :
1.  System Interfaces: Does the software call upon other unrelated
systems to perform some functions ?
› Name each external system and describe how / what the
software does and needs that system to do for it
2.  User Interfaces: The logical characteristics of each UI between
the software and the user

•  › This can include descriptions of the required screen

formats, page or window layouts, contents of reports and
menus, use of special buttons and function keys
•  › Often times rather than describing all of this content in
words it is much more preferable (from the writer’s and the
reader’s standpoint) to include UI mock-ups here
•  › A list of considerations to think about for the UI from
the user’s perspective
2.1.3 Hardware Interfaces
› Describe how the software interfaces with the hardware
within the system. If the software directly manipulates the
hardware then it needs to be described here
•  Software Interfaces
› Describe how the software product will interface with other
required software products or other applications
› Does the software have a need to call upon a database?
directly manipulate and use the O/S? use a supporting
mathematical software package? talk to the system hardware
through an API?
› Detail the purpose for interfacing with this other software
› Specify the name of software being interfaced to, its version,
where it comes from and make reference to any documentation
specifying the interface
•  Communications Interfaces
› Does the software directly use any underlying communication
protocol ? If so, you need to specify that protocol here.
2.1.6 Memory Constraints
› This is where you state your considerations and
expectations / limits on memory for the software ?
› Is amount of memory used a concern for the software ? Is
memory limited within the system – state it here.
•  Operations
› List and describe the various modes of operation of the
software here e.g. user set-up mode, administration mode, general
operation mode, etc.
› Can the software operate in unattended mode ?
› If applicable also make note of the backup and recovery operations
of the software
› Note that sometimes this subsection is combined with
User Interfaces
•  Site Adaptation Requirements
› This section describes any customization that needs to be
done or considered when the software is installed at a location
› Is there any setup or configuration that is necessary when installing?
2.2 - Product Functions
› This section should provide a summary of the major
functions that the software will perform
› Do not go into too much detail and do not provide any
specific requirements … a “Reader’s Digest” version of
the software’s functionality
› Remember the intended purpose and audience for
Section 2 of the SRS
› Either generally a non-technical person or the section
provides an introduction to low-level details and
requirements of Section 3
› Again diagrams are sometimes helpful in displaying the
functions of the software and how they interact
2.3 - User Characteristics
› In this section you need to describe what expectations the
system and software has on its users in terms of their :
•  › Level of training and experience
•  › Education
•  › Technical expertise
2.4 - Constraints
› General description of any other items that will limit the
architect’s and developer's options. For example:
Regulatory policies
•  ›
• ›Hardware limitations
• ›Interfaces to other applications
• ›Parallel operation
• › Audit functions
• › Control functions
• › Higher-order language requirements
• › Signal handshake protocols
• › Reliability requirements
• › Criticality of the application
• › Safety and security considerations
› In this section, you list and describe any considerations that
must be taken into account when architecting and designing
the software
The Structure of an SRS*
› Table of Contents
› 1. Introduction › 3. Specific Requirements
› 1.1 Purpose › 3.1 External Interfaces
› 1.2 Scope › 3.2 Functions
› 1.3 Definitions, Acronyms, and › 3.3 Performance Requirements
Abbreviations › 3.4 Logical Database Requirements
› 1.4 References › 3.5 Design Constraints
› 1.5 Overview › 3.6 Software System Attributes
2. Overall Description › 4. Appendices
› 2.1 Product Perspective › 5. Index (not required for this assignment)
› 2.2 Product Functions
› 2.3 User Characteristics
› 2.4 Constraints
› 2.5 Assumptions and Dependencies
› 2.6 Apportioning of Requirements
* NOTE : These are the sec-ons that will be in your final SRS for Assignment 1
2.5 - Assumptions and Dependencies
› In this section, you list and describe the factors that may
affect requirements stated in the SRS
› For example, if an assumption that a specific Operating System
will be available on the hardware and it ends up not to be the
case, then this would affect the contents of the SRS
› Basically what you are trying to capture in this section
are any known external considerations that are being
assumed in the writing of the requirements for the
software
› And if these assumptions end up changing – then the
software’s requirements may need to change as well
A Note about TBD’s
› What’s a TBD ?
› Strictly speaking according to the IEEE Specification, in
order to be a complete SRS – there must not be any
TBD’s in the document.
› But as we know, stuff happens and
as a result, the software that we are
trying to describe may (at the time of
writing the SRS) have unknowns or
assumptions that need to be made
…
› In this case we need to document the TBD
fully (more on this in another lesson)
2.6 - Apportioning of Requirements
› Identify requirements that may be delayed until future
versions of the system
› If there is a known requirement that has been mentioned and at
the time of writing the SRS, you know that it will be put off until a
future release, then document it here
Section 3 - Specific Requirements
› This is where the meat and potatoes of the SRS is found.
› This section contains all of the requirements to a
level of
detail sufficient to enable:
a)  designers to design a system to satisfy those requirements
b)  testers to test that the system satisfies those requirements
› Also remember to follow these principles
› All requirements should be uniquely identifiable (and
traceable)
› Attention should be paid to organizing the
requirements for maximum readability and
comprehension
› Other things to consider in documenting your
requirements … they :
› Should describe each input (stimulus) to the system.
› Should describe each output (response) from the system.
› Should describe all functions performed by the system in
response to an input or in support of an output.
Types of Specific Requirements
› 3.1 External Interfaces
› 3.2 Functions
› 3.3 Performance Requirements
› 3.4 Logical Database Requirements
› 3.5 Design Constraints
› 3.6 Software System Attributes

NOTE: There are many different ways of laying out Section 3 – but in all
of the
different organizations, these subsections need to be present
3.1 - External Interfaces
› This section should contain a detailed description of all inputs
into and outputs from the software.
› It should complement the interface descriptions from
Section 2 (in
Section 2.1) and be broken out into the same subsections
› For each input or output specified you should specify
› The input / output name
› You will refer to this input / output by name in Section
3.2
› Description of purpose
› Source of input or destination of output
› Where does it come from or where is it going to ?
› Relationships to other inputs / outputs
› The format of the input / output
› Whether that be screen format, window format, data
format or command format
3.2 - Functions
› This is the section of the SRS where all of the software’s
requirements are specified !
› This section contains the software’s functional requirements
› This section describes the fundamental actions that must take
place in the software in processing the inputs and generating outputs
› Requirements are specified as the shall statements (“The system
shall…”)
› In specifying the requirements remember to include
•  › validity checks on the inputs
•  › exact sequence of operations
•  › responses to abnormal situations
•  › effect of parameters
•  › relationships of outputs to inputs
› It may be appropriate to break the functional requirements into
sub-functions (or sub-processes)
› Based on logical subsystems of the software, or modes of
operation of the software, etc.
3.3 - Performance Requirements
› This sections lists the static and dynamic numerical
requirements placed on the software or on the
human interaction with the software
› Examples of static:
› number of users
› amount of information
› Examples of dynamic:
› numbers of transactions to be processed within certain
time periods for normal and peak workload conditions
› All requirements given in this section should be stated
in measurable terms.
For example:
› 95% of the transactions shall be processed in less than 1
second.
3.4 - Logical Databas Requirements
•  › The requirements for any information that is to be placed in a
•  database should be specified here
•  › Remember that a database is really any collection or
organization of data
•  › The requirements for the database need to include:
•  › The data entities used in the software and any relationships
they have to one another
•  › The frequency of use of the data
•  › What subsystems or mode of operation will be
accessing and manipulating the data ?
•  › The data retention requirements
•  › How long does the data need to stay around (exist) ?
3.5 - Design Constraints

Specify design constraints that can be imposed by standards

compliance, hardware limitations, etc.
› For example
•  › If your software must be written in C# you would state it
here
•  › If you had to follow Six Sigma Quality Management in your
•  organization, you would state it here
•  › If your system only had 1 GByte of RAM, you would state it
here
3.6: Software System Attributes
›There are a number of attributes of a software product that
serve as requirements
› These are often referred to as the non-functional
requirements
› It is important to include these attributes so that their
achievement can be objectively verified
› These attributes can include :
› According to the IEEE Specification : Reliability,
Availability, Security, Maintainability, Portability
› Another common breakdown of these attributes are :
Reliability, Availability, Serviceability, Usability and
Installability
Organizing the Specific Requirements
› Okay, so now you know what (in terms of details) needs to go into
Section 3 of the SRS … but how should you organize that section ?
› There are many different ways of organizing Section 3 – depending
on the software system, some methods are better than others
› Different organizational models include:
•  › System Mode: When there are different modes of operation
within the software
•  › User class: When the software behaves differently depending
on the type of user
•  › Objects: If your software interacts with different objects (eg.
Patient Monitoring System interacts with objects : patient, sensors,
nurses, room …)
•  › Features: If the system has a number of externally desired
services
Organizing the Specific Requirements
› Other organizational models include:
•  › Stimulus: Some systems are best organized by
describing the requirements on a per stimulus (input) basis
•  › Response: Same idea as stimulus, but on a per output
(response) basis
•  › Functional hierarchy:If all else fails, organize in this
way – according to the functional areas of the software
•  There are templates that are made available for each
organization of the Specific Requirements
•  They are found in Annex (Appendix) A of the IEEE
Standard