Requirements Engineering

Requirements Engineering is the process of establishing the servies that a customer requires from a system and the constraints under which it operates and is developed

A requirement may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification

Requirements specification:

  • Requirements specification: documents the user and system requirements
  • Requirements specification: has to be understandable by end-users and customers
  • Requirements specification: may be part of the contract
  • Requirements specification: should state what the system will do, not how it will do it

Types of Requirements

  1. User Requirements: statements in natural language plus diagrams of the services the sytem provides and its operational constraints. User requirements are written for customers. User requirements are readable by

   

  1. client managers
  2. system end-users
  3. client engineers
  4. contractor managers
  5. system architects
    1. System requirements: A structured document setting out detailed descriptions of the system’s functions, services, and operational constraints. System requirements define what should be implemented so may be part of a contract between clieant and contractor. System requirements are readable by:

   

  1. System end-users
  2. client engineers
  3. system architects
  4. software developers

Functional vs. non-functional requirements:

Functional Requirement: statement of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations

Non-functional requirements: constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards etc.

  • Process requirements may also be specified mandating a particular IDE, programming language, or development method

Domain requirements: constraints on the system from the domain of operation

Requirements quality: requirements should be complete, consistent, and unambiguous

Goal: general intention to achieve something

Verifiable: a measurable objective

Requirements Engineering Processes

Requirements Elicitation: technical staff work with customers and stakeholders to find out about the application. Requirements elicitation can be done through user stories

Requirements analysis: organise, prioritice, and document requirements

Requirements validation: check that the written requirements are what the customer really wants

Requirements management: dealing with changes in the requirements. Re-work will impact on cost and structure

User stories

3 C’s:

  1. Conversation: between development team, product owner, users, stakeholders, o understand what the application will do.
  2. Cards: document the requirements as user stories (specifies what class of users want to achieve and why they want to achieve it)
  3. Confirmation: document the acceptance criteria that clarify the desired behaviour

INVEST: indepent of each other, negotiable, valuable to the customer/user, estimable, small, testable

Use cases: a way to describe user interaction with the system. Each case defines a role, and a sequence of interactions that the user has with the system

Requirements Validation:

Checks that:

  • The system best supports the user’s needs
  • Everything is included
  • the requirements can be implemented given the available budget
  • the team can check that the requirements have been met

Checks by means of:

  • Document reviews by / with stakeholders
  • showing prototypes to thte stakeholders

Requirements management: the process of managing changing requirements during the requirements engineering process and system development.