Software

Requirements
Engineering
Review

u Characteristics of requirement statements: Complete, Correct, Feasible,

Necessary, Prioritized, Unambiguous, Verifiable
u Characteristics of requirements collections: Complete, Consistent,
Modifiable, Traceable
u Experimental session- group work
Outline

1. Setting requirement priorities

2. Software requirement specification
Software Requirements Specification

u The software requirements document (also called software requirements

specification or SRS) is an official statement of what the system developers
should implement.
u The SRS should include both the user requirements for a system and a
detailed specification of the system requirements.
u The SRS has a diverse set of users and they need different levels of details.
u Software development teams need to know what to build.
u Training personnel use the SRS and user documentation to develop educational
materials.
u Testers use it to develop requirements-based tests, test plans, and test procedures
u …
 System Requirements Specification
Notation Description

Natural language sentences The requirements are written using numbered sentences in
natural language. Each sentence should express one
requirement.

Structured natural language The requirements are written in natural language on a

standard form or template. Each field provides information
about an aspect of the requirement.
Design description languages This approach uses a language like a programming language,
but with more abstract features to specify the requirements
by defining an operational model of the system.
Graphical notations Graphical models, supplemented by text annotations, are
used to define the functional requirements for the system.
UML use case and sequence diagrams are commonly used.
Mathematical specifications These notations are based on mathematical concepts such as
finite-state machines or sets.
Natural Language Specification

u Requirements are written as natural language sentences supplemented by

diagrams and tables.
u Used for writing requirements because it is expressive, intuitive and
universal. This means that the requirements can be understood by users and
customers.
Guidelines for Writing Requirements

u Invent a standard format and use it for all requirements.

u Use language in a consistent way. Use shall for mandatory requirements,
should for desirable requirements.
u Use text highlighting to identify key parts of the requirement.
u Avoid the use of computer jargon.
u Include an explanation (rationale) of why a requirement is necessary.
Problems with Natural Language

u Lack of clarity
u Precision is difficult without making the document difficult to read.
u Requirements confusion
u Functional and non-functional requirements tend to be mixed-up.
u Requirements amalgamation
u Several different requirements may be expressed together.
Structured Specifications
u Structured natural language is a way of writing system requirements:
u The freedom of the requirements writer is limited
u all requirements are written in a standard way
u This works well for some types of requirements e.g. requirements for
embedded control system but is sometimes too rigid for writing business
system requirements.
u Example
Structured Specifications

Essential information:
u Definition of the function or entity.
u Description of inputs and where they come from.
u Description of outputs and where they go to.
u Information about the information needed for the computation and other
entities used.
u Description of the action to be taken.
u Pre and post conditions (if appropriate).
u The side effects (if any) of the function.
Structured Specifications
u Tabular specification
u Particularly useful when you have to define a number of possible alternative
courses of action.
u For example, the insulin pump systems bases its computations on the rate of
change of blood sugar level and the tabular specification explains how to
calculate the insulin requirement for different scenarios.

Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of increase CompDose = 0
decreasing ((r2 – r1)<(r1 – r0))
Sugar level increasing and rate of increase CompDose = round((r2 - r1)/4)
stable or increasing ((r2 – r1)>=(r1 – r0)) If rounded result = 0 then
CompDose = MinimumDose
 The Structure of a Requirements Document
Chapter Description
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 describe the need for the system. It should briefly describe the system’s functions and
explain how it will work with other systems. It should also describe how the system fits into the
overall business or strategic objectives of the organization commissioning the software.

Glossary This should define the technical terms used in the document. You should not make assumptions
about the experience or expertise of the reader.
User Here, you describe the services provided for the user. The nonfunctional system requirements
requirements should also be described in this section. This description may use natural language, diagrams, or
definition other notations that are understandable to customers. Product and process standards that must be
followed should be specified.
System This chapter should present a high-level overview of the anticipated system architecture, showing
architecture the distribution of functions across system modules. Architectural components that are reused
should be highlighted.
The Structure of a Requirements Document
Chapter Description
System requirements This should describe the functional and nonfunctional requirements in more detail. If
specification necessary, further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between the
system components and the system and its environment. Examples of possible models
are object models, data-flow models, or semantic data models.
System evolution This should describe the fundamental assumptions on which the system is based, and
any anticipated changes due to hardware evolution, changing user needs, and so on.
This section is useful for system designers as it may help them avoid design decisions
that would constrain likely future changes to the system.
Appendices These should provide detailed, specific information that is related to the application
being developed; for example, hardware and database descriptions. Hardware
requirements define the minimal and optimal configurations for the system. Database
requirements define the logical organization of the data used by the system and the
relationships between data.
Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.
An example template of
the SRS
Take a break~
The Structure of a Requirements Document

1. Introduction
The introduction presents an overview to help the reader understand how the
SRS is organized and how to use it.
1.1 Purpose
1.2 Document conventions
1.3 Project scope
1.4 References
The Structure of a Requirements Document

2. Overall description
This section presents a high-level overview of the product and the environment.
2.1 Product perspective
2.2 User classes and characteristics
2.3 Operating environment
2.4 Design and implementation constraints
2.5 Assumptions and dependencies
The Structure of a Requirements Document

3. System features
Possible ways to arrange functional requirements: system feature, functional area,
process flow, use case, mode of operation, user class, stimulus, and response

Example:
u 3.x System feature X
State the name of the feature in just a few words, such as “3.1 Spell Check.” Repeat
section 3.x with its subsections 3.x.1 and 3.x.2 for each system feature.
u 3.x.1 Description
Provide a short description of the feature and indicate whether it is of high, medium,
or low priority.
u 3.x.2 Functional requirements
Itemize the specific functional requirements associated with this feature.
The Structure of a Requirements Document

4. Data requirements
Use this section of the template to describe various aspects of the data that the
system will consume as inputs, process in some fashion, or create as outputs.
4.1 Logical data model
4.2 Data dictionary
4.3 Reports
4.4 Data acquisition, integrity, retention, and disposal
The Structure of a Requirements Document

5. External interface requirements

Provide information to ensure that the system will communicate properly with
users and with external hardware or software elements.
5.1 User interfaces
5.2 Software interfaces
5.3 Hardware interfaces
5.4 Communications interfaces
The Structure of a Requirements Document

6. Quality attributes
This section specifies nonfunctional requirements other than constraints and
external interface requirements.
5.1 User interfaces
5.2 Software interfaces
5.3 Hardware interfaces
5.4 Communications interfaces
The Structure of a Requirements Document

7. Internationalization and localization requirements

Internationalization and localization requirements ensure that the product will
be suitable for use in nations, cultures, and geographic locations.

8. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS.

Appendix A: Glossary
Define any specialized terms that a reader needs to know to understand the SRS,
including acronyms and abbreviations.
Appendix B: Analysis models
This optional section includes or points to pertinent analysis models.
Guidelines for writing requirements

u Two important goals of writing requirements are that:

u Anyone who reads the requirement comes to the same interpretation as any other
reader.
u Each reader’s interpretation matches what the author intended to communicate.

There is no formulaic way to write excellent requirements; the best teachers

are experience and feedback from the recipients of your requirements.
Example: Cafeteria Ordering System (COS)
Example: Cafeteria Ordering System (COS)
Example: Cafeteria Ordering System (COS)
Example: Cafeteria Ordering System (COS)
Example: Cafeteria Ordering System (COS)
Example: Cafeteria Ordering System (COS)
In the next lecture…

u We will talk about requirements validation

Question session