Embedded Systems Software Training Center
Software Requirements
Copyright © 2011 DSR Corporation
Welcome
 Instructor Introduction
 Objectives and Content
 Class Materials
 Agenda
Copyright © 2011 DSR Corporation
2
Instructor Introduction
 Alexandr Bychkov
 VP of Engineering at DSR
Copyright © 2011 DSR Corporation
3
Objectives
 Understand why requirements are important
 Understand what requirements should contain
 Understand the various approaches to requirements
descriptions
Copyright © 2011 DSR Corporation
4
Class Materials
 Software Engineering Introduction diagrams are
available here:
 http://www.estc.dsr-company.com/images/8/8d/Se-l3diagrams.pptx
 Hands-on Exercises are available here:
 http://www.estc.dsr-company.com/images/8/8f/Se-l3exercises.docx
Copyright © 2011 DSR Corporation
5
Agenda
1. The Requirements Process
2. Requirements Documentation
3. Requirements Quality
4. Requirements Notations
5. Requirements Validation and Verification
6. Requirements Management Tools
7. Requirements Prototyping
Copyright © 2011 DSR Corporation
6
Embedded Systems Software Training Center
1. The Requirements Process
Copyright © 2011 DSR Corporation
Software Engineering Processes
COPYRIGHT © 2011 DSR
CORPORATION
8
Requirements Input Example

Implement a control panel

Sensors send information to Control Panel (CP). CP processes, stores it, and sends
combined information to CDMS

The reports can be shown on Local PC via Web interface. Configuration is enabled
Network
Sensors
Summary data
Network
Control panel
Central data
management
system
Reports
【System Overview】
・Sensors： AC×１、AR×4、AZD×4
・Developing Firmware
・Web Application
Local PC
Control
Source code and Binary
Copyright © 2011 DSR Corporation
9
Requirements Input Example (cont.)

コントロールパネルを実装します

センサーは、コントロール (CP) パネルに情報を送る。CPのプロセス、それを保存し、CDMSへの組み合わせの情
報を送信します。

レポートは、Webインターフェースを介してローカルPC上で表示することができます。設定が有効になっています。
Network
センサ
要約データ
Network
中央のデータ
管理システム
コントロール
パネル
レポート
【システム概観 】
・ センサ : AC×１、AR×4、AZD×4
・ ファームウェアを開発する
・ Webアプリケーション
ローカルPC
コントロール
ソースコードとバイナリ
Copyright © 2011 DSR Corporation
10
What are requirements?
 A requirement is an expression of desired system behavior
 A requirement deals with:
 objects or entities
 the state they can be in
 functions that are performed to change states or object characteristics
 Requirements focus on the customer needs, not on the solution or
implementation:
 describes what behavior, without saying how that behavior will be realized
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
11
Why are Requirements Important?
 Top factors that cause projects to fail:
 Incomplete requirements
 Lack of user involvement
 Unrealistic expectations
 Lack of executive support
 Changing requirements and specifications
 Lack of planning
 System no longer needed
 Requirement errors can be expensive if not detected early
 Requirements documents are used as a baseline for all other project
activities and project acceptance (part of the software delivery
process )
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
12
Why are Requirements Important? (cont.)

Jone and Thayes's studies show that
 35% of the faults to design activities for projects of 30,000-35,000 delivered
source instructions
 10% of the faults to requirements activities and 55% of the faults to design
activities for projects of 40,000-80,000 delivered source instructions
 8% to 10% of the faults to requirements activities and 40% to 55% of the faults to
design activities for projects of 65,000-85,000 delivered source instructions

Basili and Perricone report
 48% of the faults observed in a medium-scale software project were attributed to
“incorrect or misinterpreted functional specification or requirements”

Beizer attributes 8.12% of the faults in his samples to problems in functional
requirements
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
13
The Requirements Process
 Performed by the requirements analyst, system analyst, or business
analyst
 The final outcome is a Software Requirements Specification (SRS)
document
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
14
Why Requirements Elicitation?
 Customers do not always understand what their needs
and problems are
 Customers are not always able or want to express the
details, relying upon the developer
 Customers do not always know if the functionality is
feasible
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
15
Requirements Elicitation Stakeholders
 Market Researchers: conduct surveys to determine future trends
and potential customers
 Customers: buy the software after it is developed
 Software engineers: technology experts
 Users: use the system
 Domain experts: familiar with the problem that the software must
automate
 Lawyers or auditors: familiar with government, safety, or legal
requirements
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
16
Means of Eliciting Requirements
 Interviewing stakeholders
 Reviewing available documentation
 Datasheets
 Standards
 Observing the current system (if exists)
 Working with users to learn about user's task in
more details
 Involving the reusable requirements and
requirements templates
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
17
Resolving Conflicts
 Different stakeholders have different set of requirements
 potentially conflicting ideas
 There are limitations on budget, resources etc.
 Need to prioritize requirements
 Prioritization might separate requirements into three categories
 Essential (Must-Have): absolutely must be met
 Desirable (Nice-To-Have): highly desirable but not necessary
 Optional : possible but could be ignored
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
18
Embedded Systems Software Training Center
2. Requirements Documentation
Copyright © 2011 DSR Corporation
Requirements Documentation
 Separate documents
 Requirements definition: a complete listing of everything the customer
wants to achieve. Describing the entities in the environment where the
system will be installed
 MRD, PRD
 Requirements specification: restates the requirements as a specification
of how the proposed system shall behave
 PRS, SRS
 All-in-One: Software Requirement Specification
Copyright © 2011 DSR Corporation
20
IEEE Standard for SRS
1. Introduction to the Document
1.1 Purpose of the Product
3. Specific Requirements
3.1 External Interface Requirements
1.2 Scope of the Product
3.1.1 User Interfaces
1.3 Acronyms, Abbreviations, Definitions
3.1.2 Hardware Interfaces
1.4 References
3.1.3 Software Interfaces
1.5 Outline of the rest of the SRS
2. General Description of Product
2.1 Context of Product
2.2 Product Functions
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
2.3 User Characteristics
3.3 Quality Requirements
2.4 Constraints
3.4 Constraints
2.5 Assumptions and Dependencies
3.5 Other Requirements
4. Appendices
Based on IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation
21
Specific Requirements
 Interface requirements specify the formats, timing, or other factors
of external interactions
 Functional requirements describe required behavior in terms of
required activities
 Quality requirement or non-functional requirement describes
some quality characteristic that the software must possess
 Constraint is a restriction on the system design and implementation
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation
22
Interface Requirements
 Hardware interfaces
 Software interfaces
 Communications interfaces
 User interfaces
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Copyright © 2011 DSR Corporation
23
Functional Requirements
 Exact sequence of operations
 Relationship of inputs to outputs, including:
 Input/output sequences
 Formulas for input to output conversion
 Effect of parameters
 Validity checks on the inputs
 Responses to abnormal situations, including:
 Overflow
 Communication facilities
 Error handling and recovery
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation
24
Non-Functional Requirements

Performance requirement imposes conditions on a functional requirement;
for example, a requirement that specifies the speed, accuracy, or memory
usage with which a given function must be performed.

Reliability is the ability of a system or component to perform its required
functions under stated conditions for a specified period of time.

Maintainability is the ease with which a software system or component can
be modified to correct faults, improve performance or other attributes, or
adapt to a changed environment.

Security specifies the factors that protect the software from accidental or
malicious access, use, modification, destruction, or disclosure.

Usability is the ease with which a user can learn to operate, prepare inputs
for, and interpret outputs of a system or component.
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
Copyright © 2011 DSR Corporation
25
Constraints

Design constraints are limitations on the design decision such as choice of
platform or interface components
 Hardware limitations
 Software constrains

Process constraints are a restriction on the techniques or resources that
can be used to build the system
 Programming languages
 Tools
 Libraries

Standard Compliance List of the standard and regulatory policies that are
the design constrains

Legal constrains include age, encryption, geographic filtering, black list of
companies and people, etc.
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation
26
Embedded Systems Software Training Center
3. Requirements Quality
Copyright © 2011 DSR Corporation
3. Requirements Quality







Correct
Consistent
Unambiguous
Complete
Testable
Feasible
Ranked for importance and/or stability
 Must-have
 Nice-to-have
 Traceable
 Modifiable
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
28
3. Requirements Quality
Examples
 Unambiguous
 Incorrect :

R1000. The screen allows to input the following information:
length, temperature, distance, and current time
 Correct:

R1000. The sсreen shall allow to input the following information:
length in meters, temperature in 0C, current date and time in the
YYYY-MM-DD HH:MM:SS format, respectively
Copyright © 2011 DSR Corporation
29
3. Requirements Quality
Examples (cont.)
 Unambiguous, Complete
 Incorrect :

R1000 In the case where emergency is identified as a result of the sensor
data processing, the system sends the appropriated message to the CDMS
immediately
 Correct:

R1000: The system SHALL create the emergency message as a result of
the sensor data processing if the following conditions are met
#
Condition
Message
R1001
<condition>
<message format>
…
…
…

R1010 The system MUST send the emergency message created as
defined in R1000 to the CDMS within 1 sec

R1020 The maximum amount of the emergency messages that can be
created by the system as defined in R1000 SHALL be 1000 per 1 hour
Copyright © 2011 DSR Corporation
30
3. Requirements Quality
Examples (cont.)
 Complete
 Incorrect (Jackson’s finite state machine example)
 Correct? (homework)
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
31
3. Requirements Quality
Examples (cont.)
 Consistent
 Incorrect (inconsistent):

R1000 The system MUST support maximum of 10 sensors connected
concurrently

R1010 The system response time MUST not exceed 10 ms when 20
sensors are connected to it concurrently
 Correct (consistent):

R1000 The system MUST support maximum of 20 sensors connected to it
concurrently

R1010 The REQUIRED maximum system response time in dependency to
the amount of sensors connected concurrently is shown in Table 1:
#
Sensors connected
Max response time, ms
R1011
20
10
R1012
10
5
Copyright © 2011 DSR Corporation
32
3. Requirements Quality
Requirements Improvement
Three ways to help make requirements testable, consistent and
unambiguous
 Specify a quantitative description for each adverb and
adjective
 Replace pronouns with specific names of entities
 Make sure that every noun is defined in exactly one place in
the requirements document
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
33
Embedded Systems Software Training Center
4. Requirements Notations
Copyright © 2011 DSR Corporation
4. Requirements Notations
Specification Languages
 Natural Languages
 Well-understandable for customers
 inherently ambiguous
 Semi-Formal Languages
 Use special-purpose graphical notations with a precise syntax
and a non-rigorous semantic
 Formal Languages
 Mathematics based languages with vocabulary, syntax and
semantics formally defined
 They allow avoiding ambiguity
 Unintelligible for users
 May be processed by Requirements Language Processor to
check the quality of an SRS
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
35
4. Requirements Notations
Natural Languages – Key Words (RFC2119)
 Essential
 “MUST”, “REQUIRED” or “SHALL” in positive meaning
 “MUST NOT, “”SHALL NOT” for prohibitions
 Conditional
 “SHOULD”, “RECOMMENDED” in positive meaning
 “SHOULD NOT, “”NOT RECOMMENDED” for prohibitions
 Optional
 “MAY”, “OPTIONAL”
Network Working Group. RFC2119. Key words for use in RFCs to Indicate Requirement Levels
Copyright © 2011 DSR Corporation
36
4. Requirements Notations
Semi-Formal Languages
 UML-like diagrams
 Class diagrams
 Structure diagrams
 Sequence diagrams
 State diagrams
 Use cases
 Entity-Relationship Diagrams
 Data Flow diagrams
 Petri nets
 Decision tables
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
37
4. Requirements Notations
Semi-Formal Languages (cont.)
 UML diagram example: sequence diagram
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
38
4. Requirements Notations
Semi-Formal Languages (cont.)
 UML diagram example: Turnstile -- finite state machine
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
39
4. Requirements Notations
Semi-Formal Languages (continued)
 Decision table example: Freshmen acceptance
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
High standardized exam scores
T
F
F
F
F
High grades
—
T
F
F
F
Outside activities
—
—
T
F
F
Good recommendations
—
—
—
T
F
X
X
X
Send rejection letter
Send admission forms
X
X
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
40
4. Requirements Notations
Formal Languages
 Mathematical notations
 Z notation
 Common Algebraic Specification Language (CASL)
 Specification and Description Language (SDL)
 SDL system diagram (a DFD)
 SDL block diagram (a DFD)
 SDL process diagram (a state-machine model)
 SDL data type (algebraic specification)
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
41
4. Requirements Notations
Formal Languages (cont.)
 Partial Z Specification : Example
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
42
Embedded Systems Software Training Center
5. Requirements Validation and
Verification
Copyright © 2011 DSR Corporation
5. Requirements Validation and Verification
 In requirements validation, we check that our requirements
definition accurately reflects the customer's needs
 In verification, we check that one document or artefact conforms to
another
 Verification ensures that we build the system right, whereas
validation ensures that we build the right system
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
44
5. Requirements Validation and Verification
 Manual method:

Applied to requirements written in natural and semi-formal languages

Requirements review: check and measure the requirements quality

Requirements measurement

Requirements rating
 Automated methods

Model checking is an exhaustive search for a specification's execution
space, to determine whether some temporal-logic property holds of the
execution

A theorem prover uses a collection of built-in theories, inference rules,
and decision procedures for determining whether a set of asserted facts
logically entails some unasserted fact
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
45
5. Requirements Validation and Verification
Requirements Rating
1. You understand this requirement completely, have designed
systems from similar requirements, and have no trouble
developing a design from this requirement
2. Some elements of this requirement are new, but they are not
radically different from requirements that have been successfully
designed in the past
3. Some elements of this requirement are very different from
requirements in the past, but you understand the requirement and
can develop a good design from it
4. You cannot understand some parts of this requirement, and are not
sure that you can develop a good design
5. You do not understand this requirement at all, and can not develop
a design
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
46
5. Requirements Validation and Verification
Requirements Rating: Testers/Designers Profiles
 Figure (a) shows profiles with mostly 1s and 2s

The requirements are in good shape
 Figure (b) shows profiles with mostly 4s and 5s

The requirements should be revised
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
47
Embedded Systems Software Training Center
6. Requirements Management
Tools
Copyright © 2011 DSR Corporation
6 Requirements Management Tools
Features
 Collaboration
 Change management
 Standardized requirements format
 Traceability. Link requirements to design items, test
plans, test cases and other requirements.
 Quality analysis and management
 Built-in Integrations
 API for customizations
 Enhanced document generation
Copyright © 2011 DSR Corporation
49
6 Requirements Management Tools
Examples
 Rational DOORS
 Polarion Requirements
 MKS Integrity
 Enterprise Architect
Copyright © 2011 DSR Corporation
50
Embedded Systems Software Training Center
7. Requirements Prototyping
Copyright © 2011 DSR Corporation
7. Requirements Prototyping
Approaches to Prototyping
 Throwaway approach
 Developed to learn more about a problem or a proposed
solution, and that is never intended to be part of the delivered
software
 Allow us to write “quick-and-dirty”
 Evolutionary approach
 Developed not only to help us answer questions but also to be
incorporated into the final product
 Prototype has to eventually exhibit the quality requirements of
the final product, and these qualities cannot be retrofitted
 Both techniques are sometimes called rapid prototyping
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation
52
Summary
 It is essential that the requirements specification documents
describe the problem, leaving solution selection to designer
 There is a variety of sources and means for eliciting requirements
 There are many specification types
 The specification techniques differ in terms of their tool support,
maturity, readability, ease of use, and mathematical formality
 Requirements must be validated to ensure that they accurately
reflect the customer's expectations
Copyright © 2011 DSR Corporation
53
References
1.
Software Engineering: Theory and Practice / Shari Lawrence Pfleeger
2.
SWEBOK. Guide to the Software Engineering. Body of Knowledge. 2004 Version / A project of the IEEE
Computer Society Professional Practices Committee
3.
IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology
4.
IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications
5.
Network Working Group. RFC2119. Key words for use in RFCs to Indicate Requirement Levels
6.
OMG Unified Modeling LanguageTM (OMG UML), Version 2.4 http://www.omg.org/spec/UML/2.4
7.
Z.100 : Specification and Description Language (SDL)
8.
Writing Software Requirements Specifications by Donn Le Vie, Jr.
http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
8.
Quality Evaluation of Software Requirements Specifications F. Fabbrini, M. Fusani, S. Gnesi, G. Lami I.E.I. C.N.R. Pisa, Italy.
9.
UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition By Martin Fowler
10.
UML 2.0 in a Nutshell By Dan Pilone, Neil Pitman
Copyright © 2011 DSR Corporation
54