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

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

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

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

Class Materials Software Engineering Introduction diagrams are available here: http://www.estc.dsr-company.com/images/8/8d/Se-l3- diagrams.pptx Hands-on Exercises are available here: http://www.estc.dsr-company.com/images/8/8f/Se-l3- exercises.docx Copyright © 2011 DSR Corporation

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

1. The Requirements Process Copyright © 2011 DSR Corporation

Software Engineering Processes Copyright © 2011 DSR Corporation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (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

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

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

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

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

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

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

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

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

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

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

References Software Engineering: Theory and Practice / Shari Lawrence Pfleeger SWEBOK. Guide to the Software Engineering. Body of Knowledge. 2004 Version / A project of the IEEE Computer Society Professional Practices Committee IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology IEEE Std 830-1998, 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 http://www.omg.org/spec/UML/2.4 Z.100 : Specification and Description Language (SDL) Writing Software Requirements Specifications by Donn Le Vie, Jr. http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html 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