Requirements Engineering: A Comprehensive Guide to Gathering, Analyzing, and Managing System Requirements

Posted on Aug 3, 2024 in Computers

Requirements Engineering: A Comprehensive Guide

Introduction

Requirements engineering is the process of discovering, analyzing, documenting, and verifying the services required for a system and its operational constraints.

Types of Requirements

User Requirements:

  • Statements in natural language plus diagrams of services the system provides and its operational constraints.
  • Written for the users.

System Requirements:

  • A structured document setting out detailed descriptions of the functions, services, and operational constraints of the system.
  • Defines what should be implemented, can be part of a contract between the customer and developer.

Functional Requirements:

  • Describe functionality or system services.
  • Depend on the type of software, expected users, and the type of system where the software is used.
  • Can be high-level declarations, functional system requirements should describe the system services in detail.

Non-Functional Requirements:

  • Define system properties and constraints, e.g., reliability, response time, and storage requirements.
  • Restrictions on the ability of devices I/O, system representations, etc.
  • May be more critical than functional requirements.

Domain Requirements:

  • Derived from the application domain and describe system features that reflect the domain.
  • May restrict the existing functional requirements or define specific calculations should be performed.
  • If domain requirements are not met, the system cannot work.

Document Specification Requirements

  • Must be composed of sentences in natural language, following certain standards:

    1. Use “shall” for mandatory requirements and “should” for desirable requirements.
    2. The requirements must be organized logically.
    3. Each requirement must have a unique identifier, for example, a numeric identifier for later reference.
    4. The software requirements should be divided into functional and nonfunctional requirements.
    5. Avoid the use of computer jargon.

Format Requirements Specification

  • IEEE/ANSI 830/1998. (Introduction > Overview > Specific requirements > Appendices > Index)

Problems with Natural Language Specification

Ambiguity:

  • Readers and writers of the requirement must interpret the same words the same way.
  • Natural language is inherently ambiguous, therefore, very difficult.

Excessive Flexibility:

  • The same thing can be said in several different ways in the specification.

Lack of Modularization:

  • Language structures are inadequate to structure system requirements.

Requirements Engineering Phases

  1. Feasibility Study: Decides whether or not it is worth spending time and effort with the proposed system.
  2. Elicitation and Requirements Analysis: Gather information about the proposed system and the existing Source: documents, organization, existing specifications, observations, interviews, …
  3. Requirements Validation: Requirements error costs are high and thus, the validation is very important.
  4. Requirements Management: The process of managing changing requirements during the requirements engineering and system development.

Traceability

  • Is related to relationships between requirements, their sources, and the system design.
  • Traceability of the Source: Links from requirements to stakeholders who proposed these requirements.
  • Requirements Traceability: Links between dependent requirements.
  • Traceability Project: Links from requirements to modules project.