Recap

 Introduction to course
 What is a requirement?
 Types of requirement
 What is requirement engineering process?
 System engineering and software requirements

1
Today’s Lecture
 System engineering
 Software requirement engineering
 Software requirements document
 Sample requirements document

2 Software Requirements Engineering

3
Systems engineering
 Computer-based systems fall into two broad categories:
 User-configured systems where a purchaser puts together a system from
existing software products
 Custom systems where a customer produces a set of requirements for
hardware/software system and a contractor develops and delivers that
system

4
Classes of custom systems
 Information systems
 Primarily concerned with processing information which is held in some
database.
 Embedded systems
 Systems where software is used as a controller in some broader hardware
system
 Command and control systems
 Essentially, a combination of information systems and embedded systems
where special purpose computers provide information which is collected
and stored and used to make decisions

5
Emergent properties
 Emergent properties are properties of the system as a whole and only
emerge once all of its individual sub-systems have been integrated
 Examples of emergent properties
 Reliability
 Maintainability
 Performance
 Usability
 Security
 Safety

6
The systems engineering process

S y st em System
requ ir em ent s validation
eng in eerin g

Arch it ectu ral S y st em

R equ irem ents S u b-s ys tem

S o ftw are
requ iremen ts
eng in eerin g

7
System engineering activities
 System requirements engineering
 The requirements for the system as a whole are established and written to be
understandable to all stakeholders
 Architectural design
 The system is decomposed into sub-systems
 Requirements partitioning
 Requirements are allocated to these sub-systems
 Software requirements engineering
 More detailed system requirements are derived for the system software

8
System engineering activities
 Sub-system development
 The hardware and software sub-systems are designed and implemented in
parallel.
 System integration
 The hardware and software sub-systems are put together to make up the
system.
 System validation
 The system is validated against its requirements.

9
Requirements document
 The requirements document is a formal document used to
communicate the requirements to customers, engineers and
managers.
 The requirements document describes:
 The services and functions which the system should provide
 The constraints under which the system must operate
 Overall properties of the system i.e.. constraints on the system’s emergent
properties
 Definitions of other systems which the system must integrate with.

10
Requirements document
 The requirements document describes:
 Information about the application domain of the system e.g. how to carry out
particular types of computation
 Constraints on the processes used to develop the system
 Description of the hardware on which the system is to run
 In addition, the requirements document should always include an
introductory chapter which provides an overview of the system,
business needs supported by the system and a glossary which explains
the terminology used.

11
Users of requirements documents
 System customers
 specify the requirements and read them to check they meet their needs
 Project managers
 Use the requirements document to plan a bid for system and to plan the system
development process
 System engineers
 Use the requirements to understand the system being developed
 System test engineers
 Use the requirements to develop validation tests for the system
 System maintenance engineers
 Use the requirements to help understand the system
12
Requirements document structure
 IEEE/ANSI 830-1993 standard proposes a structure for software
requirements documents
 1. Introduction
1.1 Purpose of requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document

13
Requirements document structure
 2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
 3. Specific requirements
Covering functional, non-functional and interface requirements.
 4. Appendices
 Index
14
Adapting the standard
 The IEEE standard is a generic standard which is intended apply to
a wide range of requirements documents.
 In general, not all parts of the standard are required for all
requirements documents
 Each organisation should adapt the standard depending on the type
of systems it develops
 Consider a company (XYZ) that develops scientific instruments

15
Organisation XYZ standard
 Preface
 This should define the expected readership of the document and describe its
version history including a rationale for the creation of a new version and a
summary of the changes made in each version.
 Introduction
 This should define the product in which the software is embedded, its
expected usage and present and overview of the functionality of the control
software.
 Glossary
 This should define all technical terms and abbreviations used in the document.

16
Organisation XYZ standard
 General user requirements
 This should define the system requirements from the perspective of the user of
the system. These should be presented using a mixture of natural language and
diagrams.
 System architecture
 This chapter should present a high-level overview of the anticipated system
architecture showing the distribution of functions across system modules.
Architectural components which are to be reused should be highlighted.
 Hardware specification
 This is an optional chapter specifying the hardware that the software is expected
to control. It may be omitted if the standard instrument platform is used.

17
Organisation XYZ standard
 Detailed software specification
 This is a detailed description of the functionality expected of the software of
the system. It may include details of specific algorithms which should be
used for computation. If a prototyping approach is to be used for
development on the standard instrument platform, this chapter may be
omitted.
 Reliability and performance requirements
 This chapter should describe the reliability and performance requirements
which are expected of the system. These should be related to the statement
of user requirements in Chapter 4.

18
Organisation XYZ standard
 The following appendices may be included where appropriate:
 Hardware interface specification
 Software components which must be reused in the system implementation
 Data structure specification
 Data-flow models of the software system
 Detailed object models of the software system
 Index

19
Writing requirements
 Requirements are usually written as paragraphs of natural language
text supplemented by diagrams and equations
 Problems with requirements
 use of complex conditional clauses which are confusing
 sloppy and inconsistent terminology
 writers assume readers have domain knowledge

20
Writing essentials
 Requirements are read more often than they are written. You should
invest time to write readable and understandable requirements
 Do not assume that all readers of the requirements have the same
background and use the same terminology as you
 Allow time for review, revision and re-drafting of the requirements
document

21
 Writing guidelines
 Define standard templates for describing requirements
 Use language simply consistently and concisely
 Use diagrams appropriately
 Supplement natural language with other description of requirements
 Specify requirements quantitatively

22
Example – Bus Locator Project
 Problem Statement: Students using busses as means to get to the
campus face problems when busses are late, especially when they
have to wait for busses under scorching sun or heavy rain. This
application intends to facilitate students by providing means to track
busses in real time which will not only allow students to view
locations of their busses and get to stop on time. It will also facilitate
the transport office to keep track of all the active busses.
 SRS

23
Users of Bus Locator SRS
 End User / Customer
 Bus Drivers
 Students
 Transport Office
 Project Manager
 Development Team
 Test

24
Summary
 System engineering and software requirements
 The requirements document is the definitive specification of
requirements for customers, engineers and managers.
 The requirements document should include a system overview,
glossary, statement of the functional requirements and the
operational constraints

25