Lecture 5.2.b: Requirements Specifications (IEEE 830)

1
Lecture 5.2.b Requirements Specifications (IEEE
830)

• Dr. John MacCarthy
• UMBC CMSC 615
• Fall, 2006

2
Requirements Standards

• Active DOD Standards lthttp//www.dsp.dla.milgt
• Defense and Program-Unique Specifications Format
  and Content MIL-STD-961E, August, 2003
• Software Life Cycle Processes IEEE 12207.0, May
  1998
• Software Life Cycle Processes - Life Cycle Data
  IEEE 12207.1, May 1998
• Software Life Cycle Processes Implementation
  Considerations IEEE 12207.2, May 1998
• Data Item Descriptions (DIDs) MIL-STD-963
• IEEE Standards lthttp//www.ieee.orggt
• IEEE Guide for Developing of System Requirements
  Specification IEEE-1233-1998
• IEEE Recommended Practice for Software
  Requirements Specifications ANSI/IEEE 830-1998

• Cancelled Standards
• Software Development and Documentation
  MIL-STD-498, May, 1994 Replaced by IEEE/EIA
  12207 series
• Defense System Software Development
  MIL-STD-2167A, December 1994 Replaced by
  MIL-STD-498
• IEEE Recommended Practice for Software
  Requirements Specifications IEEE 830-1994
  http//www.cs.njit.edu/campbell/CIS673/IEEE.pdf
  Replaced by ANSI/IEE 830-1998

3
Industry Standard Software Requirements
Specifications (SRS)

• IEEE Std 830-1998, IEEE Recommended Practices for
  Software Requirements Specifications.
• There are 8 different recommended SRS Templates
  for Section 3
• System Mode (2)
• User Class
• Objects
• Features (Services)
• Stimulus (Input)
• Functional Hierarchy (Information Flow)
• Hybrid
• Response (Output)

4
Considerations for an SRS (4)

• Nature of the SRS (4.1)
• Functionality
• External Interfaces
• Performance
• Attributes
• Design Constraints
• Environment of the SRS (4.2)
• Correctly define SW requirements
• Should not describe design or implementation
  details
• Should not impose unnecessary constraints on the
  SW

• Characteristics of a good SRS (4.3)
• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable

5
Constraints Section

• Section 2.4 Constraints
• Regulatory Policies
• Hardware Limitations
• Interfaces to Other Applications
• Parallel Operation
• Audit Functions
• Control Functions
• Higher-Order Language Requirements
• Signal Handshake Protocols
• Reliability Requirements
• Criticality of the Application
• Safety and Security Considerations

6
Section 3 Structure

• 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 Functions
• 3.3 Performance Requirements

• 3.4 Design Constraints
• 3.5 SW System Attributes
• 3.5.1 Reliability
• 3.5.2 Availability
• 3.5.3 Security
• 3.5.4 Maintainability
• 3.5.5 Portability
• 3.6 Other Requirements

7
Section 3 Organized by Mode 1

• 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 Mode 1
• 3.2.1.1 Functional Requirement 1
• 3.2.1.2 Functional Requirement 2
• ..
• 3.2.2 Mode 2
• .
• 3.3 Performance Requirements
• 3.4 Design Constraints
• 3.5 SW System Attributes
• 3.6 Other Requirements

8
Section 3 Organized by Mode 2

• 3. Specific Requirements
• 3.1 Functional Requirements
• 3.1.1 Mode 1
• 3.1.1.1 External Interface Requirements
• 3.1.1.1.1 User Interfaces
• 3.1.1.1.2 Hardware Interfaces
• 3.1.1.1.3 Software Interfaces
• 3.1.1.1.4 Communications Interfaces
• 3.1.1.2 Functional Requirements
• 3.1.1.2.1 Functional Requirement 1
• 3.1.1.2.2 Functional Requirement 2
• 3.1.1.3 Performance Requirements
• 3.2.1 Mode 2
• .
• 3.2 Design Constraints
• 3.3 SW System Attributes
• 3.4 Other Requirements

9
Section 3 Organized by User Class

• 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 User Class 1
• 3.2.1.1 Functional Requirement 1
• 3.2.1.2 Functional Requirement 2
• ..
• 3.2.2 User Class 2
• .
• 3.3 Performance Requirements
• 3.4 Design Constraints
• 3.5 SW System Attributes
• 3.6 Other Requirements

10
Section 3 Organized by Object

• 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 Class Objects
• 3.2.1 Class Object 1
• 3.2.1.1 Attributes
• 3.2.1.2 Functions (Services, methods)
• 3.2.1.3 Messages
• 3.2.2 Class Object 2
• .
• 3.3 Performance Requirements
• 3.4 Design Constraints
• 3.5 SW System Attributes
• 3.6 Other Requirements

11
Other Organizations

• Section 3 Organized by Feature
• Section 3 Organized by Stimulus
• Section 3 Organized by Functional Hierarchy
• Section 3 Multiple Organizations

12
Section 3 Organized by Functional Hierarchy (2)
(My Recommendation)

• 3. Specific Requirements
• 3.1 External Interface Requirements
• 3.1.1 User Interfaces
• 3.1.2 Hardware Interfaces
• 3.1.3 Software Interfaces (including data)
• 3.1.4 Communications Interfaces (including data)
• 3.2 Functional Requirements
• (Statement of Top-Level Function)
• 3.2.1 Function 1.1
• 3.2.1.1 Function 1.1.1
• 3.2.1.2 Function 1.1.2
• 3.2.2 Function 1.2
• .
• 3.3 Performance Requirements
• 3.4 Design Constraints
• 3.5 SW System Attributes
• 3.6 Other Requirements

• Suggest a Logical Data Model Annex to support
  data structures addressed in Sections 3.1.3,
  3.1.4, and 3.2
• Suggested Functional Leaf Node Requirements
  Format
• Paragraph Number
• Shall statement with Function statement
• Outputs
• Triggers
• Inputs
• Rule Model
• Performance
• (Context/Notes)
• Note Non-leaf node function is considered
  accomplished (from a functional perspective) if
  all its leaf nodes are accomplished
• Note Non-leaf node functions may have
  performance requirements/attributes that are not
  simply roll-ups of leaf-node performance
• Note One may want to specify the scenario(s)
  that are to be used to verify performance

13
Example Format

• 3.2.X.Y The system shall verb phrase
• where the system generates the following outputs
  ..
• where the activity is triggered by the following
  conditions
• where the activity is provided the following
  input
• where the activity follows the following business
  rules
• where process is completed subject to the
  following performance requirements
• Context/Notes

• 3.X.Y The system shall verb phrase
• where this function consists of the subfunctions
  that follow
• where this function is completed subject to the
  following performance requirements
• Context/Notes