Requirements Specification With The IEEE 830 and IEEE 29148 Standards

SEG3101 (Fall 2014)
Requirements Specification with

the IEEE 830 and IEEE 29148
Standards
Miguel Garzón, University of Ottawa

Based on slides by Gunter Mussbacher (2009) and Stéphane Somé (2008)
with material from these standards:
IEEE 830-1998, ISO/IEC 12207, ISE/IEC/IEEE 29148:2011
Table of Contents
• Requirements Specification Document
• IEEE 830 Standard

• Relationship of IEEE 830 and ISO/IEC 12207
• ISO/IEC/IEEE 29148 Standard
2
SEG3101. Requirements Specification with the IEEE 830 Standard. © 2009 G. Mussbacher, 2011-2014 D. Amyot
Requirements Specifications IEEE 830-1998 Standard IEEE 830 and ISO/IEC 12207 ISO/IEC/IEEE 29148:2011
Requirements Specification Document (1)

• Clearly and accurately describes each of the essential
requirements (functions, performance, design constraints,
and quality attributes) of the system / software and its
external interfaces
• Defines the scope and boundaries of the system / software
• Each requirement must be described in such a way that it is

feasible and objectively verifiable by a prescribed method
(e.g., by inspection, demonstration, analysis, or test)
• Basis for contractual agreements between contractors or

suppliers and customers
• Elaborated from elicitation notes

3
Requirements Specification Document (2)

• Specifications are intended to a diverse audience
• Customers and users for validation, contract, ...
• Systems (requirements) analysts
• Developers, programmers to implement the system
• Testers to check that the requirements have been met
• Project Managers to measure and control the project
• Different levels of detail and formality is needed for each

audience
• Different templates for requirements specifications

• e.g. IEEE 830
4
IEEE 830-1998 Standard

• Title of Standard
• « IEEE Recommended Practice for Software Requirements
Specifications »
• Describes the content and qualities of a good software

requirements specification (SRS)
• Presents several sample SRS outlines
5
IEEE 830-1998 Standard – Objectives

• Help software customers to accurately describe what they
wish to obtain
• Help software suppliers to understand exactly what the

customer wants
• Help participants to:

• Develop a template (format and content) for the software requirements
specification (SRS) in their own organizations
• Develop additional documents such as SRS quality checklists or an
SRS writer’s handbook
6
IEEE 830-1998 Standard – Benefits

• Establish the basis for agreement between the customers
and the suppliers on what the software product is to do
• Reduce the development effort

• Forced to consider requirements early  reduces later redesign,
recoding, retesting
• Provide a basis for realistic estimates of costs and schedules
• Provide a basis for validation and verification

• Facilitate transfer of the software product to new users or new
machines
• Serve as a basis for enhancement requests
7
IEEE 830-1998 Standard – Considerations

• Section 4 of IEEE 830 (how to produce a good SRS)
• Nature (goals) of SRS
• Functionality, interfaces, performance, qualities, design constraints
• Environment of the SRS
• Where does it fit in the overall project hierarchy
• Characteristics of a good SRS
• Generalization of the characteristics of good requirements to the document
• Evolution of the SRS
• Implies a change management process
• Prototyping
• Helps elicit software requirements and reach closure on the SRS
• Including design and project requirements in the SRS
• Focus on external behavior and the product, not the design and the
production process (describe in a separate document)
8
IEEE 830-1998 Standard – Structure of the SRS

• Section 5 of IEEE 830
• Contents of SRS
• Introduction
• General description of the software product
• Specific requirements (detailed)
• Additional information such as appendixes and index, if necessary
9
IEEE 830-1998 Standard – Section 1 of SRS

• Title • Describe purpose of this
• Table of Contents •
SRS
Describe intended audience
• 1. Introduction • Identify the software product

• Enumerate what the system will and will not
• 1.1 Purpose do
• Describe user classes and benefits for each
• 1.2 Scope
• 1.3 Definitions. Acronyms, and Abbreviations
• 1.4 References • Define the vocabulary of the
SRS (may reference appendix)
• 1.5 Overview
• 2. Overall Description • List all referenced documents including sources
(e.g., Use Case Model and Problem Statement;
• 3. Specific Requirements Experts in the field)
• Appendices • Describe the content of the rest of the
• Index •
SRS
Describe how the SRS is organized
IEEE 830-1998 Standard – Section 2 of SRS

• Title •
•
Present the business case and operational concept of the system
Describe how the proposed system fits into the business context
• Table of Contents •
•
Describe external interfaces: system, user, hardware, software, communication
Describe constraints: memory, operational, site adaptation
• 1. Introduction • Summarize the major functional capabilities
• 2. Overall Description
• Include the Use Case Diagram and supporting
narrative
(identify actors and use cases)
• 2.1 Product Perspective • Include Data Flow Diagram if appropriate
• 2.2 Product Functions • Describe and justify technical skills

and capabilities of each user class
• 2.3 User Characteristics
• 2.4 Constraints
• 2.5 Assumptions and Dependencies
• 3. Specific Requirements • Describe other constraints that will limit developer’s
• 4. Appendices options; e.g., regulatory policies; target platform,
database, network software and protocols,
• 5. Index development standards requirements
IEEE 830-1998 Standard – Section 3 of SRS (1)

•…
• 1. Introduction
Specify software requirements in sufficient
detail to enable designers to design a system to satisfy
those requirements and testers to verify
requirements
• 3. Specific Requirements State requirements that are externally perceivable by

users, operators, or externally connected systems
• 3.1 External Interfaces
Requirements should include, at a minimum, a
• 3.2 Functions description of every input (stimulus) into the system,
every output (response) from the system, and all
functions performed by the system in response to an
• 3.3 Performance Requirements input or in support of an output
• 3.4 Logical Database Requirements

(a) Requirements should have characteristics of
high quality requirements
• 3.5 Design Constraints (b) Requirements should be cross-referenced to
their source.
• 3.6 Software System Quality Attributes
(c) Requirements should be uniquely identifiable
(d) Requirements should be organized to
• 3.7 Object Oriented Models maximize readability
• 4. Appendices
• 5. Index
IEEE 830-1998 Standard – Section 3 of SRS (2)

•… • Detail all inputs and outputs
• 1. Introduction (complement, not duplicate, information presented in section

2)
• Examples: GUI screens, file formats
• 3. Specific Requirements • Include detailed specifications of

each use case, including
• 3.1 External Interfaces collaboration and other diagrams
useful for this purpose
• 3.2 Functions
• Include:
• 3.3 Performance Requirements a) Types of information used
b) Data entities and their relationships
• 3.4 Logical Database Requirements
• 3.5 Design Constraints • Should include:
a) Standards compliance
• 3.6 Software System Quality Attributes b) Accounting & Auditing procedures
• 3.7 Object Oriented Models • The main body of requirements organized in a variety of
• 4. Appendices a)
possible ways:
Architecture Specification
• 5. Index b)
c)
Class Diagram
State and Collaboration Diagrams
d) Activity Diagram (concurrent/distributed)
IEEE 830-1998 Standard – Templates

• Annex A of IEEE 830
• Section 3 (Specific Requirements) may be organized in many

different ways based on
• Modes
• User classes
• Concepts (object/class)
• Features
• Stimuli
• Response
• Functional hierarchy
14
Relationship of IEEE 830 and ISO/IEC 12207 (1)

• 12207
• Common framework for « Software life cycle processes »
• ISO/IEC 12207 = IEEE/EIA 12207
• IEEE 830-1998 and IEEE/EIA 12207.1-1997 both place

requirements on documents describing software
requirements
• Annex B of IEEE 830 explains the relationship between the
two sets of requirements for those who want to produce
documents that comply with both standards simultaneously
• Such compliance may be required by customers when
requesting proposals or issuing call for tenders
15
Relationship of IEEE 830 and ISO/IEC 12207 (2)
• Note: Table B.3 is more detailed and shows the

correspondence between the two standards at the level of
requirements types
16
ISO/IEC/IEEE 29148:2011
• ISO/IEC/IEEE 29148:2011: Systems and software
engineering — Life cycle processes — Requirements
engineering
• http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6146379
• This International Standard provides a unified treatment of
the processes and products involved in engineering
requirements throughout the life cycle of systems and
software.
• Harmonizes IEEE 830, SWEBOK, and 7 other standards.
• More emphasis on characteristics of good requirements, RE
activities and processes, operations (and operation context),
and different information items (including their structures)
such as specification of requirements for stakeholders,
systems and software.
• Complies with ISO/IEC 15288 and ISO/IEC 12207
17
Stakeholder Requirements Specification Outline
18
System Requirements Specification Outline
19
Software Requirements Specification Outline
Verification: This section provides the

verification approaches and methods
planned to qualify the software. The
information items for verification are
recommended to be given in a parallel
manner with the information items in
section 3.
20

Requirements Specification With The IEEE 830 and IEEE 29148 Standards

Uploaded by

Copyright:

Available Formats

Requirements Specification With The IEEE 830 and IEEE 29148 Standards

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Specification With The IEEE 830 and IEEE 29148 Standards

Uploaded by

Copyright:

Available Formats

SEG3101 (Fall 2014)

Requirements Specification with

Miguel Garzón, University of Ottawa

• IEEE 830 Standard

• ISO/IEC/IEEE 29148 Standard

Requirements Specification Document (1)

• Each requirement must be described in such a way that it is

• Basis for contractual agreements between contractors or

• Elaborated from elicitation notes

Requirements Specification Document (2)

• Different levels of detail and formality is needed for each

• Different templates for requirements specifications

IEEE 830-1998 Standard

• Describes the content and qualities of a good software

• Presents several sample SRS outlines

IEEE 830-1998 Standard – Objectives

• Help software suppliers to understand exactly what the

• Help participants to:

IEEE 830-1998 Standard – Benefits

• Reduce the development effort

• Provide a basis for validation and verification

IEEE 830-1998 Standard – Considerations

IEEE 830-1998 Standard – Structure of the SRS

IEEE 830-1998 Standard – Section 1 of SRS

• 1. Introduction • Identify the software product

• Appendices • Describe the content of the rest of the

IEEE 830-1998 Standard – Section 2 of SRS

• 1. Introduction • Summarize the major functional capabilities

• 2.2 Product Functions • Describe and justify technical skills

IEEE 830-1998 Standard – Section 3 of SRS (1)

• 3. Specific Requirements State requirements that are externally perceivable by

• 3.4 Logical Database Requirements

IEEE 830-1998 Standard – Section 3 of SRS (2)

• 1. Introduction (complement, not duplicate, information presented in section

• 3. Specific Requirements • Include detailed specifications of

IEEE 830-1998 Standard – Templates

• Section 3 (Specific Requirements) may be organized in many

Relationship of IEEE 830 and ISO/IEC 12207 (1)

• IEEE 830-1998 and IEEE/EIA 12207.1-1997 both place

Relationship of IEEE 830 and ISO/IEC 12207 (2)

• Note: Table B.3 is more detailed and shows the

Stakeholder Requirements Specification Outline

System Requirements Specification Outline

Software Requirements Specification Outline

Verification: This section provides the

You might also like