1. Software Requirements Specification SJTU

2. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

3. Systems Engineering Process Model System Requirements Engineering Architectural Design Requirements Allocation Software Requirements Engineering Sub-system Development System Integration System Validation Needs statement Validated System System Requirements Specification Software Requirements Specification

4. Requirements Engineering Activity Model Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Validated Requirements Specification Existing System Information Stakeholder Needs Organizational Standards Technical Standards Regulations Domain Information Goals Requirements Management

5. Requirements Elicitation l Knowledge transfer from users to developers l First stage in building an understanding of the problem that the software is required to solve l Fundamentally a human activity l Not a passive activity l Also referred to as requirements capture, requirements discovery, or requirements acquisition

6. Elicitation Techniques l Interviews l Questionnaires l Scenarios l Use cases Also a requirements analysis method l Prototypes Also a requirements validation method l Facilitated workshops (e.g., JAD session) l Observation Job protocol analysis Social analysis

7. Requirements Analysis l The process of analyzing requirements to: Detect and resolve requirements problems Decompose (elaborate) requirements Discover system boundary and how system must interact with its environment Discover interactions and overlaps between requirements Gain a better understanding of the problem l Includes the following main activities: Requirements classification Conceptual modeling Requirements negotiation l Quality of analysis directly affects product quality More rigorous analysis leads to better software quality

8. Conceptual Modeling l Development of models to aid understanding of requirements A model is an abstract representation of system whose requirements are being analyzed Model can be used to answer questions about system Not concerned with initiating design of the solution l In nearly all cases, useful to start by building model of system boundary Crucial to understanding system’s context in its operational environment Crucial to identify system’s interfaces to external environment

9. Examples of Conceptual Models l Activity model l Class diagram l Context diagram l Data flow model l Data model l Formal model l Object model l Process model l State model l Use case model

10. Typical Requirements Problems Identified During Analysis l Ambiguous requirements l Conflicting requirements l Design dependent requirements l Infeasible requirements (technical, operational, economic) l Incomplete requirements l Inconsistent requirements l Non-singularized requirements l Non-testable requirements l Unnecessary requirements

11. Requirements Negotiation l The activity of resolving problems with conflicting requirements Between stakeholder requirements Between requirements and resources Between capabilities and constraints l Includes the following main activities: Requirements discussion Stakeholders involved present their views Requirements prioritization Disputed requirements are prioritized to identify critical requirements Requirements agreement Compromise set of requirements result

12. Requirement Types (1 of 4) l System requirement Condition or capability that must be met or possessed by a system (IEEE STD 729) Externally visible function or attribute of a system (IEEE STD 830) Defines service the system must provide and associated constraints l Software requirement Condition or capability that must be met or possessed by a software component

13. Requirement Types (2 of 4) l Functional requirement Condition or capability needed by end user to solve a problem or achieve an objective (IEEE STD 729) User requirement Behavioral requirement

14. Requirement Types (3 of 4) l Non-functional requirement Requirement not specifically concerned with functionality System quality or attribute Reliability Availability Maintainability Portability Usability Security Capacity Performance Safety Design constraint Restriction on system/software to be built Restriction on developmental process

15. Requirement Types (4 of 4) l Information requirement Entities, attributes, and relationships that must be stored and processed by the system/software Data requirement l External interface requirement Information that must be exchanged with an external system or component Information exchange requirement

16. Natural Language l Requirements specifications are typically expressed in natural language l Advantages Extraordinarily rich and expressive Able to describe almost any concept or system property l Disadvantages Inherently ambiguous Hard to describe complex concepts precisely Difficult to modularize natural language requirements Prone to misunderstanding

17. Alternatives to Natural Language Specifications (1 of 2) l Structured natural language Restricted form of natural language Maintains most of the expressiveness of natural language while ensuring some degree of uniformity l Design description or program description languages Language derived from a programming language containing additional, more abstract, constructs to increase expressiveness l Graphical notations

18. Alternatives to Natural Language Specifications (2 of 2) l Mathematical notations (formal methods) Z CSP Advantage Non-ambiguous since syntax and semantics are formally defined Disadvantage Not expressive enough to adequate describe every system aspect Almost always requires natural language to supplement

19. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

20. System Requirements Specification (SyRS) l Completely describes interface between system (as a black box) and its external environment (actors) Human users External systems Hardware devices l Serves as basis for system architecture and design l Serves as basis for system validation and user acceptance Test solution against system requirements l Forms basis for system development contract l Communicates system requirements to users, customers, developers, and other stakeholders

21. SyRS Standards and Formats l System requirements specification (SyRS) IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications IEEE/EIA 12207.1-1997, Clause 6.26 l System/Subsystem Specification (SSS) IEEE J-STD-016-1995, Annex F.2.2

22. IEEE 12201.1 Recommended Contents for SyRS l Generic specification information l System identification and overview l Required states and modes l Requirements for the functions and performance of the system l Business, organizational, and user requirements l Safety, security, and privacy protection requirements l Human-factors engineering (ergonomics) requirements l Operations and maintenance requirements l System interface requirements System environmental req’ts l Design constraints and qualification requirements Computer resource req’ts l System quality characteristics l Internal data requirements l Installation-dependent data requirements l Physical requirements l Personnel, training, and logistics requirements l Packaging requirements l Precedence and criticality of requirements l Rationale

23. Selection of SyRS Standard and Format l Depends on context Project User organization Customer organization Development organization For example, U. S. Army requires operational requirements document for all major system development efforts l Should tailor selected standard for project Eliminate unneeded sections For example, eliminate states and modes if not applicable

24. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

25. Software Requirements Specification (SRS) l Completely describes interface between software component and its external environment (actors) Decomposition of system requirements (from SyRS) that have been allocated (during requirements allocation) to software components (within architectural design) Non-functional requirements from SyRS are elaborated and quantified SRS requirements traced to SyRS requirements l Serves as basis for software sub-system design l Serves as basis for software sub-system testing l Forms basis for software development contract l Communicates software requirements to users, customers, developers, and other stakeholders

26. Contents of SRS l Functional requirements Functions software must provide l External interface requirements Required interaction with external environment People, hardware, and other software l Performance requirements Speed, availability, response time, recovery time of various software functions l Non-functional requirements Portability, correctness, maintainability, security, etc. l Design constraints imposed on an implementation Required standards, implementation language, policies for database integrity, resource limits, operating environment(s) etc.

27. SRS Standards and Formats l IEEE STD 830-1998 IEEE/EIA 12207.1-1997, Clause 6.2.2, Software Requirements Description l IEEE p123/D3 l ISO/IEC 12119-1994 l IEEE J-STD-016-1995, Annex F.2.4

28. Selection of SRS Standard and Format l Depends on context Project User organization Customer organization Development organization l Should tailor selected standard for project Eliminate unneeded sections

29. IEEE 830-1998 Recommended SRS Format (1 of 3) Table of contents 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview

30. IEEE 830-1998 Recommended SRS Format (2 of 3) 2 Overall description 2.1Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 2.6 Apportioning of requirements

31. IEEE 830-1998 Recommended SRS Format (3 of 3) 3 Specific requirements 3.1 External interfaces 3.2 Functions Organize by mode, user class, object, feature, stimulus, response, or functional hierarchy 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints 3.6 Software system attributes l Appendixes l Index

32. Section 3.2 Organized By Feature l 3.2 System features l 3.2.1 System Feature 1 l 3.2.1.1 Introduction/Purpose of feature l 3.2.1.2 Stimulus/Response sequence l 3.2.1.3 Associated functional requirements l 3.2.1.3.1 Functional requirement 1 l... l 3.2.1.3.n Functional requirement n l 3.2.2 System feature 2 l... l 3.2.m System feature m l …

33. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

34. Other Requirements Specifications l Interface Requirements Specification (IRS) IEEE J-STD-016-1995, Annex F.2.3 l Operational Concept Description (OCD) IEEE J-STD-016-1995, Annex F.2.1 IEEE/EIA 12207.1-1997, Clause 6.3 IEEE 1362-1998 l Operational Requirements Document (ORD) l Functional Description (FD) l Mission Needs Statement (MNS)

35. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

36. Attributes of a Well-Written SRS Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable

37. Correct An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet

38. Unambiguous An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation The SRS should be unambiguous both to those who create it and to those who use it Impossible to achieve using natural language Natural language is inherently ambiguous Glossary of terms is helpful in reducing ambiguity Examples of ambiguous requirements The system shall work well The system shall be user friendly

39. Complete An SRS is complete if, and only if, it includes: All significant requirements relating to functionality, performance, design constraints, attributes, and external interfaces Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations Important to specify responses to both valid and invalid input values Full labels and references to all figures, tables, and diagrams Definition of all terms and units of measure No use of the term “ to be determined ” (TBD)

40. Consistent An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict Examples of inconsistency The format of an output report may be described in one requirement as tabular but in another as textual One requirement may state that “ A ” must always follow “ B ” while another may require that “ A ” and “ B ” occur simultaneously A program ’ s request for a user input may be called a “ prompt ” in one requirement and a “ cue ” in another

41. Ranked for Importance and/or Stability An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement For example: essential vs. desirable

42. Verifiable l An SRS is verifiable if, and only if, every requirement stated therein is verifiable l A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement l Examples of non-verifiable (and ambiguous) requirements The system shall work well The system shall be user friendly In general any ambiguous requirement is not verifiable l Example of a verifiable requirement Output of the program shall be produced within 20 s of event ´ 60% of the time; and shall be produced within 30 s of event ´ 100% of the time

43. Modifiable An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style Coherent and easy-to-use organization with a table of contents, an index, and explicit cross-referencing No redundant requirements (i.e., the same requirement should not appear in more than one place in the SRS) Singularized requirements Express each requirement separately, rather than intermixed with other requirements

44. Traceable l An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation Backward traceability (i.e., to previous stages of development) This depends upon each requirement explicitly referencing its source in earlier documents Forward traceability (i.e., to all documents spawned by the SRS) This depends upon each requirement in the SRS having a unique name or reference number

45. Benefits of a Well-Written Specification l Establishes basis for agreement between customers and developers on what functions software product must perform l Reduces development effort Reduces later redesign, recoding, and retesting l Provides basis for estimating costs and schedules l Provides baseline for validation and verification l Serves as basis for software maintenance Correction of bugs Enhancements

46. Common Requirements Specification Problems l Use of long sentences with complex sub-clauses l Use of terms with more than one plausible interpretation Ambiguity l Presenting several requirements as a single requirement l Inconsistency in use of terms

47. Subtopics l Background material l System requirements specification l Software requirements specification l Other types of requirements specifications l Attributes of a well-written requirements specification l Summary information

48. Recommended Practices l Use restricted subset of natural language l State requirements succinctly (in short sentences) l Standardize on small set of modal verbs to indicate relative priorities For example, “shall” indicates requirement is mandatory while “should” indicates requirement is optional but desirable l Generate specification from baselined requirements in requirements management database l Adopt organizational requirements specification standard l Tailor requirements document for project

49. Key Points l Requirements define what the system should provide and define system constraints l Requirements problems lead to late delivery and change requests after the system is in use l Quality of requirements document directly affects product quality l Requirements specification should be sufficient for design and procurement decisions to be made

50. References l Gerald Kotonya and Ian Sommerville, Requirements Engineering: Processes and Techniques, Wiley, 1998 l Pete Sawyer and Gerald Kotonya, Guide to the Software Engineering Body of Knowledge, Chapter 2, Version 0.95, May 2001, IEEE l Ian Sommerville, Software Engineering, 7th Edition, Addison-Wesley, 2000 l Alan Davis, Software Requirements, Prentice Hall, 1993 IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements Specifications IEEE STD 1233-1998, IEEE Recommended Practice for Developing System Requirements Specifications