1. 1. The Requirements Process 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

2. 1. The Requirements Process 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

3. 1. 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

4. 2. Requirements Documentation 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

5. 3. Requirements Quality Examples
Unambiguous, Testable, Complete
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

6. 3. Requirements Quality Examples (cont.)
Unambiguous, Testable, 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

7. 3. Requirements Quality Examples (cont.)
Consistency
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

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

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

10. 4. Requirements Notations Semi-Formal Languages (cont.)
UML diagram: Jackson’s finite state machine example (incomplete requirement)
Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4
Copyright © 2011 DSR Corporation

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