CO2401 Software Development
• Teaching structure
– Lecture
– Labs
• Assessment
– Assignment 50%
– Exam 50%
CO2401 Software Development
•
•
•
•
•
•
•
•
Project Lifecycle
Requirements
HCI & GUI
Design
Code
Testing
Quality
Evaluation
Objectives
1. To introduce the idea of system requirements
and the requirements engineering process for
software systems
2. To explain how requirements engineering fits
into a broader system engineering process
3. To explain the importance of the system
requirements document (SRS)
Software systems
Computer 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 delivers that system
Software systems (continued)
Classes of custom systems
•
•
•
Information systems
Primarily concerned with processing information
Embedded systems
Systems where software is used as a controller in a
hardware system (e.g. video camera)
Command and control systems
A combination of information systems and embedded
systems where special purpose computers provide
information which is collected and stored and used to
make decisions
Terminology
•
System requirements
Define what the system is required to do and constraints under
which it will be required to operate
•
Requirements engineering
The structured set of activities involved in developing system
requirements (are accountable for approx 15% of system
development costs)
•
Requirements document
The formal statement of system requirements
•
System stakeholders
Anyone affected by the system
•
Requirements management
The processes involved in making changes to requirements
Requirements document structure
IEEE/ANSI 830-1993 standard recommended
structure for software requirements documents
1 Introduction
1.1
1.2
1.3
1.4
1.5
Purpose of document
Scope of the product
Definitions, acronyms and abbreviations
References
Overview of the remainder of the document
Requirements document structure
2 General description
2.1
2.2
2.3
2.4
2.5
2.6
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
Apportioning of requirements
3 Specific requirements
- Covering functional, non-functional and interface requirements
4 Appendices
5 Index
Requirements document structure
1 Introduction
1.1 Purpose
This sub-section should
– Describe the purpose of the SRS
– Specify the intended audience of the SRS
Requirements document structure
1 Introduction
1.2 Scope
This sub-section should
–
Identify the software product(s) to be produced by name
–
Explain what the software product(s) will do and not do
–
Describe the application of the software including benefits,
objectives and goals
–
Be consistent with higher level specifications if they exist
Requirements document structure
1 Introduction
1.3 Definitions, acronyms and abbreviations
This sub-section should
–
Provide the definitions of all terms a complete list
of all terms, acronyms and abbreviations required
to properly interpret the SRS
–
This information may be provided by reference to
one or more appendixes in the SRS or reference to
other documents
Requirements document structure
1. Introduction
1.4 References
This sub-section should
– Provide a complete list of documents referenced
elsewhere in the SRS
– Identify each document by title, report number (if
applicable), date and publishing organisation
– Specify the sources from which the references can be
obtained
Requirements document structure
1. Introduction
1.5 Overview
This sub-section should
–
Describe what the rest of the SRS should contain
–
Explain how the SRS is organised
Requirements document structure
2
General description
2.1
2.2
2.3
2.4
2.5
2.6
3
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
Apportioning of requirements
Specific requirements
- Covering functional, non-functional and interface requirements
4
5
Appendices
Index
Requirements document structure
2. General description
2.1 Product perspective
This sub-section should
•
Put the product in perspective with other related products
•
If the product is totally self-contained it should be stated here.
•
If the product is a component of a larger system, functionality of
the software to the requirements of the larger system should be
stated and interfaces between the two systems should be stated.
Block diagrams may be useful for showing components and
interfaces of two systems.
Requirements document structure
2. General description
2.1 Product perspective (continued)
This sub-section should also describe how the software operates
inside various constraints. For example, these could include:
•
•
•
•
•
•
•
•
System interfaces
User interfaces
Hardware interfaces
Software interfaces
Communication interfaces
Memory
Operations
Site adaptation requirements
Requirements document structure
2. General description
2.2 Product functions
This sub-section provides a summary of the major functions that
the software will perform. For example, and SRS for an
accounting program may use this part to address customer
account maintenance, customer statement and invoice
preparation.
For the sake of clarity:
•
•
The functions should be organised in a way that makes them
understandable to anyone reading the document
Textual or graphical methods can be used to show the functions and
their relationships. Such a diagram is not intended to show a
design of the product, but simply shows the logical relationships
among variables.
Requirements document structure
2. General description
2.3 Constraints
This sub-section should provide a general description of any
other items that will limit the developers options. These include:
•
•
•
•
•
•
Regulatory policies
Hardware limitations
Interfaces to other applications
Reliability requirements
Criticality of the application
Safety and security considerations
Requirements document structure
2. General description
2.4 Assumptions and dependencies
This sub-section should list each of the factors that affect the
requirements stated in the SRS.provide a general description of
any other items that will limit the developers options. These
include:
•
•
•
•
•
•
Regulatory policies
Hardware limitations
Interfaces to other applications
Reliability requirements
Criticality of the application
Safety and security considerations
Requirements document structure
2. General description
2.5 Apportioning of requirements
This sub-section should identify requirements
that may be delayed until future versions of
the system
Requirements document structure
3. Specific requirements
This section of the SRS should contain all the
software requirements to a level of detail
sufficient to enable designers to design a
system to satisfy those requirements, and
testers to test that the system satisfies those
requirements.
Requirements document structure
3. Specific requirements (continued)
These requirements should include at a
minimum a description of every input (stimulus)
into the system, every output (response) from
the system, and all functions performed by the
system in response to an input or in support of
an output.
Requirements document structure
3. Specific requirements
As this is often the largest and most important part of the
SRS, the following principles apply:
a)
b)
c)
d)
Specific requirements should be stated in conformance with all
the characteristics described in the section titled “Characteristics
of a good SRS”
Specific requirements should be cross-referenced to earlier
documents that relate
All requirements should be uniquely identifiable
Careful attention should be given to organising the requirements
to maximise readability
Requirements document structure
3. Specific requirements
The items that compromise requirements are:
3.1
3.2
3.3
3.4
3.5
3.6
3.7
External interfaces
Functions
Performance requirements
Logical database requirements
Design constraints
Software system attributes
Organising the specific requirements
Requirements document structure
3. Specific requirements
3.1 External interfaces
This part should contain a detailed description of all
inputs into and outputs from the software system.
It should complement the interface descriptions from
section 2 of the document and should not repeat the
information from there
Requirements document structure
3. Specific requirements
3.1 External interfaces (continued)
This part should include both content and format as follows:
a) Name of item
b) Description of purpose
c) Source of input or destination of output
d) Valid range, accuracy and/or tolerance
e) Units of measure
f) Timing
Requirements document structure
3. Specific requirements
3.1 External interfaces (continued)
g)
h)
i)
j)
k)
l)
Relationships to other inputs/outputs
Screen formats/organisation
Window formats/organisation
Data formats
Command formats
End messages
Requirements document structure
3. Specific requirements
3.2 Functions
Functional requirements should define the fundamental
actions that must take place in the software in accepting
and processing the inputs and and in processing and
generating the outputs.
Functional requirements are generally listed as “shall”
statements starting with “The system shall…”
Requirements document structure
3. Specific requirements
3.2 Functions (continued)
Functional requirements include:
a)
b)
c)
d)
e)
Validity checks on the inputs
Exact sequence of operations
Responses to abnormal situations (e.g., overflow,
communication facilities, error handling and recovery)
Effect of parameters
Relationship of inputs to outputs, including
i.
ii.
Input/output sequences
Formulas for input to output conversion
Requirements document structure
3. Specific requirements
3.3 Performance requirements
This subsection should specify both the static and
dynamic numerical requirements placed on the software
or on the human interaction with the software as a
whole.
Static numerical requirements are sometimes identified
under a separate section titled “Capacity”
Requirements document structure
3. Specific requirements
3.3 Performance requirements (continued)
Static numerical requirements may include the
following:
a)
b)
c)
The number of terminals to be supported
The number of simultaneous users to be supported
Amount and type of information to be handled
Requirements document structure
3. Specific requirements
3.3 Performance requirements (continued)
Dynamic numerical requirements may include the
following:
a)
b)
The numbers of transactions and tasks
The amount of data to be processed within certain time periods
for both normal and peak workload conditions
Requirements document structure
3.
Specific requirements
3.3 Performance requirements (continued)
All performance requirements should be stated in measurable terms:
For example:
95% of the transactions shall be processed in less than one second
Rather than:
An operator shall not have to wait for the transaction to complete
Note: Numerical limits applied to one specific function are normally
specified as part of the processing subparagraph description of that
function
Requirements document structure
3. Specific requirements
3.4 Logical database requirements
This part should specify the logical requirements for any
information that is to be placed in a database. This may include the
following:
a) Types of information used by various functions
b) Frequency of use
c) Accessing capabilities
d) Data entities and their relationships
e) Integrity constraints
f) Data retention requirements
Requirements document structure
3. Specific requirements
3.5 Design constraints
This part should specify design constraints that can be imposed by other
standards, hardware limitations etc
3.5.1 Standards compliance
The standards section should specify the requirements derived from existing
standards or regulations. They may include the following:
a)
Report format
b)
Data naming
c)
Accounting procedures
d)
Audit tracing
e.g. this could specify a requirement for software to trace processing activity
Requirements document structure
3. Specific requirements
3.6 Software system attributes
There are a number of attributes of software that can serve as requirements.
It is important that required attributes can be specified so that their
achievement can be verified. The following is a partial list of examples:
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
Requirements document structure
3. Specific requirements
3.6 Software system attributes
3.6.1 Reliability
Should specify the factors required to establish the required
reliability of the software system at the time of delivery
3.6.2 Availability
Should specify the factors required to guarantee a defined
availability level for the entire system such as checkpoint,
recovery and restart
Requirements document structure
3. Specific requirements
3.6 Software system attributes
3.6.3 Security
Should specify the factors that protect the software from accidental or
malicious access, use, modification, destruction, or disclosure. Specific
requirements in this area could include the need to:
a)
b)
c)
d)
e)
Utilise certain cryptographical techniques
Keep specific log or history data sets
Assign certain functions to different modules
Restrict communications between some areas of the program
Check data integrity for critical variables
Requirements document structure
3. Specific requirements
3.6 Software system attributes
3.6.4 Maintainability
Should specify attributes of software that relate to the ease of
maintenance of the software itself. There may be some
requirement for certain modularity, interfaces, complexity etc
Note: Requirements should not be placed her because just
because they are thought to be good design practises
Requirements document structure
3. Specific requirements
3.6 Software system attributes
3.6.5 Portability
Should specify attributes of software that relate to the ease of porting
the software to other host machines and/or operating systems. This
may include the following:
a)
b)
c)
d)
e)
Percentage of components with host dependant code
Percentage of code that is host dependant
Use of a proven portable language
Use of a particular compiler or language subset
Use of a particular operating system
Requirements document structure
3. Specific requirements
3.6 Software system attributes
3.6.5 Portability
Should specify attributes of software that relate to the ease of porting
the software to other host machines and/or operating systems. This
may include the following:
a)
b)
c)
d)
e)
Percentage of components with host dependant code
Percentage of code that is host dependant
Use of a proven portable language
Use of a particular compiler or language subset
Use of a particular operating system
Requirements document structure
3. Specific requirements
3.7 Organising the specific requirements
For anything but trivial systems the detailed
requirements tend to be extensive. For this reason, it is
recommended that careful consideration is given to
organising these in manner optimal to understanding.
There is no one optimal organisational for all systems.
Different classes of systems lend themselves to different
organisations of requirements in section 3 of the SRS.