software requirements specification sjtu. subtopics l background material l system requirements...

Software Requirements Specification

SJTU

Subtopics Background material System requirements specification Software requirements specification Other types of requirements specifications Attributes of a well-written requirements

specification Summary information

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

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

Requirements Elicitation Knowledge transfer from users to developers First stage in building an understanding of the

problem that the software is required to solve Fundamentally a human activity Not a passive activity Also referred to as requirements capture,

requirements discovery, or requirements acquisition

Elicitation Techniques Interviews Questionnaires Scenarios Use cases

• Also a requirements analysis method Prototypes

• Also a requirements validation method Facilitated workshops (e.g., JAD session) Observation

• Job protocol analysis• Social analysis

Requirements Analysis 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

Includes the following main activities:• Requirements classification• Conceptual modeling• Requirements negotiation

Quality of analysis directly affects product quality• More rigorous analysis leads to better software quality

Conceptual Modeling 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

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

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

Typical Requirements Problems Identified During Analysis

Ambiguous requirements Conflicting requirements Design dependent requirements Infeasible requirements (technical, operational, economic) Incomplete requirements Inconsistent requirements Non-singularized requirements Non-testable requirements Unnecessary requirements

Requirements Negotiation The activity of resolving problems with conflicting

requirements• Between stakeholder requirements• Between requirements and resources• Between capabilities and constraints

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

Requirement Types (1 of 4) 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

Software requirement• Condition or capability that must be met or possessed by a

software component

Requirement Types (2 of 4) Functional requirement

• Condition or capability needed by end user to solve a problem or achieve an objective (IEEE STD 729)

• User requirement

• Behavioral requirement

Requirement Types (3 of 4) 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

Requirement Types (4 of 4) Information requirement

• Entities, attributes, and relationships that must be stored and processed by the system/software

• Data requirement

External interface requirement• Information that must be exchanged with an external system or

component

• Information exchange requirement

Natural Language Requirements specifications are typically

expressed in natural language Advantages

• Extraordinarily rich and expressive• Able to describe almost any concept or system property

Disadvantages• Inherently ambiguous• Hard to describe complex concepts precisely• Difficult to modularize natural language requirements• Prone to misunderstanding

Alternatives to Natural Language Specifications (1 of 2)

Structured natural language• Restricted form of natural language

• Maintains most of the expressiveness of natural language while ensuring some degree of uniformity

Design description or program description languages • Language derived from a programming language containing

additional, more abstract, constructs to increase expressiveness

Graphical notations

Alternatives to Natural Language Specifications (2 of 2)

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

System Requirements Specification (SyRS)

Completely describes interface between system (as a black box) and its external environment (actors)

• Human users• External systems• Hardware devices

Serves as basis for system architecture and design Serves as basis for system validation and user acceptance

• Test solution against system requirements Forms basis for system development contract Communicates system requirements to users, customers,

developers, and other stakeholders

SyRS Standards and Formats System requirements specification (SyRS)

• IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements Specifications

• IEEE/EIA 12207.1-1997, Clause 6.26

System/Subsystem Specification (SSS)• IEEE J-STD-016-1995, Annex F.2.2

IEEE 12201.1 Recommended Contents for SyRS

Generic specification information System identification and

overview Required states and modes Requirements for the functions

and performance of the system Business, organizational, and user

requirements Safety, security, and privacy

protection requirements Human-factors engineering

(ergonomics) requirements Operations and maintenance

requirements

System interface requirements System environmental req’ts Design constraints and qualification

requirements Computer resource req’ts System quality characteristics Internal data requirements Installation-dependent data

requirements Physical requirements Personnel, training, and logistics

requirements Packaging requirements Precedence and criticality of

requirements Rationale

Selection of SyRS Standard and Format

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

Should tailor selected standard for project• Eliminate unneeded sections

• For example, eliminate states and modes if not applicable

Software Requirements Specification (SRS)

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

Serves as basis for software sub-system design Serves as basis for software sub-system testing Forms basis for software development contract Communicates software requirements to users, customers,

developers, and other stakeholders

Contents of SRS Functional requirements

• Functions software must provide External interface requirements

• Required interaction with external environment• People, hardware, and other software

Performance requirements• Speed, availability, response time, recovery time of various software

functions Non-functional requirements

• Portability, correctness, maintainability, security, etc. Design constraints imposed on an implementation

• Required standards, implementation language, policies for database integrity, resource limits, operating environment(s) etc.

SRS Standards and Formats IEEE STD 830-1998 IEEE/EIA 12207.1-1997, Clause 6.2.2,

Software Requirements Description IEEE p123/D3 ISO/IEC 12119-1994 IEEE J-STD-016-1995, Annex F.2.4

Selection of SRS Standard and Format

Depends on context• Project

• User organization

• Customer organization

• Development organization

Should tailor selected standard for project• Eliminate unneeded sections

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


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


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

Appendixes Index

Section 3.2 Organized By Feature

3.2 System features 3.2.1 System Feature 1 3.2.1.1 Introduction/Purpose of feature 3.2.1.2 Stimulus/Response sequence 3.2.1.3 Associated functional requirements 3.2.1.3.1 Functional requirement 1 ... 3.2.1.3.n Functional requirement n 3.2.2 System feature 2 ...

3.2.m System feature m …

Other Requirements Specifications

Interface Requirements Specification (IRS)• IEEE J-STD-016-1995, Annex F.2.3

Operational Concept Description (OCD)• IEEE J-STD-016-1995, Annex F.2.1

• IEEE/EIA 12207.1-1997, Clause 6.3

• IEEE 1362-1998

Operational Requirements Document (ORD) Functional Description (FD) Mission Needs Statement (MNS)

Attributes of a Well-Written SRS

Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable

Correct An SRS is correct if, and only if, every

requirement stated therein is one that the software shall meet

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

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)

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

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

Verifiable An SRS is verifiable if, and only if, every requirement

stated therein is verifiable 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

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

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

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

Traceable 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

Benefits of a Well-Written Specification

Establishes basis for agreement between customers and developers on what functions software product must perform

Reduces development effort• Reduces later redesign, recoding, and retesting

Provides basis for estimating costs and schedules Provides baseline for validation and verification Serves as basis for software maintenance

• Correction of bugs

• Enhancements

Common Requirements Specification Problems

Use of long sentences with complex sub-clauses Use of terms with more than one plausible

interpretation• Ambiguity

Presenting several requirements as a single requirement

Inconsistency in use of terms

Recommended Practices Use restricted subset of natural language State requirements succinctly (in short sentences) 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

Generate specification from baselined requirements in requirements management database

Adopt organizational requirements specification standard Tailor requirements document for project

Key Points Requirements define what the system should

provide and define system constraints Requirements problems lead to late delivery and

change requests after the system is in use Quality of requirements document directly affects

product quality Requirements specification should be sufficient

for design and procurement decisions to be made

References Gerald Kotonya and Ian Sommerville, Requirements

Engineering: Processes and Techniques, Wiley, 1998 Pete Sawyer and Gerald Kotonya, Guide to the Software

Engineering Body of Knowledge, Chapter 2, Version 0.95, May 2001, IEEE

Ian Sommerville, Software Engineering, 7th Edition, Addison-Wesley, 2000

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

software requirements specification sjtu. subtopics l background material l system requirements...

Documents

requirements discovery

better understanding

following main activities

systems context

operational environmentcrucial

systems interfaces

resourcesbetween capabilities

developersfirst stage