Embedded Systems Software Training Centerestc.dsr-company.com/images/1/1d/SE-L3-SW... · ... of the...

14
Embedded Systems Software Training Center Software Requirements Copyright © 2011 DSR Corporation

Transcript of Embedded Systems Software Training Centerestc.dsr-company.com/images/1/1d/SE-L3-SW... · ... of the...

Embedded Systems Software Training Center

Software Requirements

Copyright © 2011 DSR Corporation

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 2

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

Copyright © 2011 DSR Corporation

【System Overview】 ・Sensors: AC×1、AR×4、AZD×4

・Developing Firmware ・Web Application

Source code and Binary

Control panel

Sensors Central data management

system

Local PC

Network

Network

Summary data

Reports

Control

3

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

Copyright © 2011 DSR Corporation

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

4

1. The Requirements Process

Performed by the requirements analyst, system analyst, or business

analyst

The final outcome is a Software Requirements Specification (SRS)

document

Copyright © 2011 DSR Corporation

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

5

2. Requirements Documentation IEEE Standard for SRS

Copyright © 2011 DSR Corporation

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

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

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

4. Appendices

6

Based on IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications

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 7

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

Copyright © 2011 DSR Corporation

# Condition Message

R1001 <condition> <message format>

… … …

8

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:

Copyright © 2011 DSR Corporation

# Sensors connected Max response time, ms

R1011 20 10

R1012 10 5

9

4. Requirements Notations Semi-Formal Languages (cont.)

UML diagram example: sequence diagram

Copyright © 2011 DSR Corporation

10

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

4. Requirements Notations Semi-Formal Languages (cont.)

UML diagram example: Turnstile -- finite state machine

Copyright © 2011 DSR Corporation

11

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

4. Requirements Notations Semi-Formal Languages (cont.)

UML diagram: Jackson’s finite state machine example

(incomplete requirement)

Copyright © 2011 DSR Corporation

12

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

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

Copyright © 2011 DSR Corporation 13

Pfleeger and Atlee, Software Engineering: Theory and Practice, Chapter 4

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 14