Requirements Engineering Overview

Requirements Engineering

• This topic covers requirements specification, documentation and methods
• A software requirements specification is a list of all requirements for a software product.
• Requirements specification is the process of documenting the collected requirements into a document.
• Inputs for requirements specification come from requirements analysis and negotiation.
• The output of requirements specification is a Requirements Document that fully describes the system to be developed.
• Key aspects of requirements specification involve defining the product's purpose and scope, describing the product, detailing the requirements, and providing supporting information.
• The output of the requirements specification process is a requirements document.

Requirements Document

• A requirements document is a reference document
• It resolves conflicts between users and developers
• It creates a common language between multiple parties, including customers, analysts, designers, developers, testers, and maintainers.
• Agreements should also be achieved between purchasers and suppliers.
• The document supports requirements verification and validation, system testing, and project management
• It helps control system evolution.

Characteristics of a Requirements Document

• A well-written requirements document should be clear, complete, accurate, consistent, traceable, and relevant.

Problems Without a Requirements Document

• Without a requirements document, systems may not meet customer needs.
• Developers may not build what the customer needs.
• Maintenance becomes difficult, as engineers struggle to understand the system's functionality.
• Users' manuals are difficult to write.

Methods for Software Requirements Specification

• For large systems, user stories or disciplined documentation using structured natural language is preferred.
• For smaller systems, free documentation in unrestricted natural language may suffice.

User Story

• A user story is a requirement from an end-user's perspective.
• User stories are a popular method in Agile development.
• Benefits of user stories involve focusing on the user, clear requirements, and high-level requirements without unnecessary detail.

User Story Format

• User stories follow a standard format
• An example format: "As a [role], I want [goal] so that [benefit]".

Free Documentation in Unrestricted Natural Language

• This approach uses natural language without restrictions.
• It benefits from simplicity and accessibility but can lead to ambiguity.
• Issues often arise due to logical connective confusion and content ambiguities in natural language.

Disciplined Documentation in Structured Natural Language

• This approach utilizes standardized statement templates.
• Often based on standards like IEEE recommended practice for software requirements specification.
• It benefits from clarity but may require more technical expertise.

IEEE 830-1998 Standard - Structure of the SRS

• The standard outlines the structure of a well-organized Software Requirements Specification (SRS).
• The standard covers areas like Introduction, Overall Description, Specific Requirements, External Interfaces, Functions, Performance Requirements, Logical Database Requirements, Design Constraints, Software System Quality Attributes, Object-Oriented Models, Appendices, and Index.

User Story + SRS

• Combining user stories and SRS provides comprehensive requirements.
• User stories, SRS and testing tasks complement each other.