1. Software Requirements
Embedded Systems Software Training Center
Software Requirements
Copyright © 2011 DSR Corporation

2. Welcome Instructor Introduction Objectives and Content Class Materials
Agenda
Copyright © 2011 DSR Corporation

3. Instructor Introduction
Alexandr Bychkov
VP of Engineering at DSR
Copyright © 2011 DSR Corporation

4. Objectives Understand why requirements are important
Understand what requirements should contain
Understand the various approaches to requirements descriptions
Copyright © 2011 DSR Corporation

5. Class Materials
Software Engineering Introduction diagrams are available here:
diagrams.pptx
Hands-on Exercises are available here:
exercises.docx
Copyright © 2011 DSR Corporation

6. Agenda The Requirements Process Requirements Documentation
Requirements Quality
Requirements Notations
Requirements Validation and Verification
Requirements Management Tools
Requirements Prototyping
Copyright © 2011 DSR Corporation

7. 1. The Requirements Process
Copyright © 2011 DSR Corporation

8. Software Engineering Processes
Copyright © 2011 DSR Corporation

9. 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
Central data management system
Network
Control panel
Reports
Local PC
【System Overview】 ・Sensors：　AC×１、AR×4、AZD×4 ・Developing Firmware ・Web Application
Source code and Binary
Control
Copyright © 2011 DSR Corporation

10. Requirements Input Example (cont.)
コントロールパネルを実装します
センサーは、コントロール (CP) パネルに情報を送る。CPのプロセス、それを保存し、CDMSへの組み合わせの情 報を送信します。
レポートは、Webインターフェースを介してローカルPC上で表示することができます。設定が有効になっています。
Network
センサ
要約データ
中央のデータ管理システム
Network
コントロールパネル
レポート
ローカルPC
【システム概観 】 ・ センサ :　AC×１、AR×4、AZD×4 ・ ファームウェアを開発する ・ Webアプリケーション
ソースコードとバイナリ
コントロール
Copyright © 2011 DSR Corporation

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 2. Requirements Documentation
Copyright © 2011 DSR Corporation

20. 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

21. IEEE Standard for SRS Introduction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
Hardware Interfaces
Software Interfaces
Communications Interfaces
3.2 Functional Requirements
Class 1
Class 2 …
3.3 Quality Requirements
3.4 Constraints
3.5 Other Requirements
Appendices
Based on IEEE Std , IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation

22. 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 , IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation

23. Interface Requirements
Hardware interfaces
Software interfaces
Communications interfaces
User interfaces
IEEE Std , IEEE Standard Glossary of Software Engineering Terminology
Copyright © 2011 DSR Corporation

24. 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 , IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation

25. 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 , IEEE Standard Glossary of Software Engineering Terminology
Copyright © 2011 DSR Corporation

26. 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 , IEEE Recommended Practice for Software Requirements Specifications
Copyright © 2011 DSR Corporation

27. 3. Requirements Quality
Copyright © 2011 DSR Corporation

28. 3. Requirements Quality Correct Consistent Unambiguous Complete
Testable
Feasible
Ranked for importance and/or stability
Must-have
Nice-to-have
Traceable
Modifiable
IEEE Std , IEEE Recommended Practice for Software Requirements Specifications
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation

29. 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

30. 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
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 #
Condition
Message
R1001
<condition>
<message format> …
Copyright © 2011 DSR Corporation

31. 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

32. 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 5
Copyright © 2011 DSR Corporation

33. 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

34. 4. Requirements Notations
Copyright © 2011 DSR Corporation

35. 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 , IEEE Recommended Practice for Software Requirements Specifications
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation

36. 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

37. 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

38. 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

39. 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

40. 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
High grades —
Outside activities
Good recommendations
Send rejection letter X
Send admission forms
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation

41. 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

42. 4. Requirements Notations Formal Languages (cont.)
Partial Z Specification : Example
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation

43. 5. Requirements Validation and Verification
Copyright © 2011 DSR Corporation

44. 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

45. 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

46. 5. Requirements Validation and Verification Requirements Rating
You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement
Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past
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
You cannot understand some parts of this requirement, and are not sure that you can develop a good design
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

47. 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

48. 6. Requirements Management Tools
Copyright © 2011 DSR Corporation

49. 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

50. 6 Requirements Management Tools Examples
Rational DOORS
Polarion Requirements 
MKS Integrity
Enterprise Architect
Copyright © 2011 DSR Corporation

51. 7. Requirements Prototyping
Copyright © 2011 DSR Corporation

52. 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

53. 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

54. References
Software Engineering: Theory and Practice / Shari Lawrence Pfleeger
SWEBOK. Guide to the Software Engineering. Body of Knowledge Version / A project of the IEEE Computer Society Professional Practices Committee
IEEE Std , IEEE Standard Glossary of Software Engineering Terminology
IEEE Std , IEEE Recommended Practice for Software Requirements Specifications
Network Working Group. RFC2119. Key words for use in RFCs to Indicate Requirement Levels
OMG Unified Modeling LanguageTM (OMG UML), Version 2.4
Z.100 : Specification and Description Language (SDL)
Writing Software Requirements Specifications by Donn Le Vie, Jr.
Quality Evaluation of Software Requirements Specifications F. Fabbrini, M. Fusani, S. Gnesi, G. Lami I.E.I. - C.N.R. Pisa, Italy.
UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition By Martin Fowler
UML 2.0 in a Nutshell By Dan Pilone, Neil Pitman
Copyright © 2011 DSR Corporation