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

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

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

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 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces 3.2 Functional Requirements 3.2.1 Class 1 3.2.2 Class 2 … 3.3 Quality Requirements 3.4 Constraints 3.5 Other Requirements Appendices Based on IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications Copyright © 2011 DSR Corporation

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

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

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

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

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

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

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