Software Requirements Document Overview

Software Requirements Document

• A software requirements document is an official statement of what is required of system developers.
• It should define and specify requirements.
• It is not a design document, but should focus on what the system should do, not how.

Key Points

• Identify major components of the requirements document.
• Identify potential problems in the requirements document.
• Understand requirements document validation.
• Learn IEEE requirements document standards.

Guidelines for Writing Requirements

• Create a standard format for all requirements.
• Use consistent language, using "shall" for mandatory and "should" for desirable requirements.
• Use text highlighting to identify key parts of requirements.
• Avoid computer jargon.

Requirements Document Requirements

• Detail external system behaviour.
• Specify implementation constraints.
• Ensure requirements are easily modifiable.
• Predict and document system lifecycle changes.
• Characterise responses to unexpected events.

Complex Problems

• System complexity may make thorough understanding impossible during development.
• Requirements can often be incomplete and inconsistent due to this complexity.

Reasons for Inconsistency

• Large software systems often have effects on the organization that are difficult to foresee.
• Different users and organizations have different priorities and requirements.

Requirements Completeness

• A complete requirements document includes those relating to functionality, performance, design constraints, attributes, and external interfaces.
• It should describe all required features. Gaps in specification lead to assumptions.

Requirements Ambiguity

• Ambiguous requirements lead to different interpretations by developers and users.
• Examples include vagueness in statements about acceptable user numbers.

Ambiguity

• The natural language used in requirements is inherently ambiguous.
• Each requirement should have only one interpretation.
• Use clear and concise language, and use a glossary when necessary to avoid confusion.
• Define "fit criteria" to test solutions against requirements.

Problems with Natural Language Specifications

• Ambiguity: Readers and writers of requirements may have different interpretations of the same words.
• Over-flexibility: Multiple ways to express the same thing in the specification may confuse.
• Lack of modularisation: Natural language is often poorly suited to structuring system requirements.

Alternatives to Natural Language Specifications

• Structured Natural Language: Uses standard forms and templates for requirements.
• Design Description Languages: Uses programming language-like abstract features for defining an operational model.
• Graphical Notations: Uses visual representations supplemented by text to specify functional requirements.
• Mathematical Specifications: Uses concepts like finite-state machines to create precise and unambiguous requirements, but can be difficult for customers to understand.

Correctness

• Every requirement statement must accurately represent the functionality required.

Viability

• Requirements must be viable within the constraints of the project.
• Technical skills, time, budget, and stakeholder acceptance are viability concerns.

Requirements Rationale

• Providing rationale for requirements helps developers understand the application domain and justifies current form.
• Important for making changes to requirements without unforeseen effects

Requirements Verifiability

• Requirements should be precise and measurable, allowing objective verification.
• Vague terms like "minimize errors" should be quantified.
• Define metrics, such as an experienced user completing tasks within a set time and number of errors.

Requirements Separation

• Functional and non-functional requirements should be explicitly separated.
• Non-functional requirements (e.g., safety) may involve the addition of functions to the system.

Requirements Validation

• Validating requirements ensures the system meets customer needs accurately.
• Error costs associated with requirements errors typically high, making validation crucial.
• Prototyping helps in requirements validation.

Requirements Checking

• Validate requirements by ensuring that they meet customer needs, checking for conflicts, and confirming if all relevant functionalities are included.
• Requirements must be achievable given budget and technology.

Requirements Reviews

• Hold regular reviews to check requirements during their formulation.
• Involve client and contractor staff to ensure everyone's input is captured.
• Early communication to resolve issues quickly

Requirements Document Changes

• Organize the document to facilitate modifications without extensive rewriting.
• Minimize external references and use modular sections.
• Electronic documents facilitate changes.

IEEE Requirements Standard

• The IEEE standard document structure includes a general description, specific requirements, appendices, and an index.
• It is a generic structure adapted to specific systems.

IEEE Recommendations

• The IEEE recommendations detail the structure of a software requirement document, specifying sections like Introduction, Overview and Specific Requirements.