Chapter 4 - Requirements Engineering

CS 3354

Problems with Requirements

Failure to communicate

Insufficient focus on up-front activities

Over promise, under deliver

Requirements volatility

Perspective on Dealing with Requirements Problem

Computer scientists use formal specification techniques

System analysts use modeling approaches

Software project managers use iterative-and-incremental development

Developers use peer reviews (inspections) of the requirements

Testers and QA people require testable requirements and do early test set construction (test-driven development)

Agile advocates place a customer representative on the development team

Solutions to Known Problems

Talk to stakeholders (customers, users, and others)

Iterative and incremental development (manages volatile requirements and provides visibility)

Agile methods and UP are “methodologies” that systematically address these issues

“Sweet Spot” for Requirements Volatility in Agile Methods

30-50% (or more) per month

Unified Process (UP) Requirements Workflow

What must the product be able to do?

Develop understanding of application domain (specific environment it operates in)

Build business model of client’s business processes

Use business model to determine client’s requirements

Iterate, as necessary

Phases: Inception, Elaboration, Construction, Transition

Requirements Engineering

Process of establishing services that a customer requires from a system and the constraints under which it operates and is developed

Concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements.

Requirement

A statement which translates or expresses a need and its associated constraints and conditions (may range from high-level abstract statement to a detailed math functional specification;  requirements abstraction)

Derived Requirements

Requirements that are deduced or inferred from the collection and organization of requirements into a particular system configuration and solution

User Requirements

Statements in natural language plus diagrams of services that the system provides and its operation constraints

Written for customers

System Requirements

Structured document setting out detailed descriptions of system’s functions, services, and operational constraints.

Defines what should be implemented so may be part of a contract between client and contractor

Readers of User Requirements

Client managers

System end-users

Client engineers

Contractor managers

System architects

Readers of System Requirements

System end-users

Client engineers

System architects

Software developers

System stakeholders

Any person/organization who’s affected by the system in some way and has a legitimate interest

Types:

• End users

• System managers

• System owners

• External stakeholders

Functional Requirements

The “What?” — statements of:

• services system should provide

• how system should react to particular inputs

• how system should behave in particular situations

May state what system shouldn’t do as well

Describes functionality or system services, often expressed in terms of inputs and outputs.

May be high-level statements of what system should do, should describe system services in detail.

Non-Functional Requirements

The “How?” — defines constraints on services or functions offered by system such as timing constraints, constraints on development process, standards, etc.

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

Often applied to the system as a whole rather than individual features or services (system properties and constraints).

May be more critical than functional requirements, as the system may be useless if they aren’t met.

Requirements Jargon

Requirements → “shall”

Statements of fact, futurity, or declaration of purpose → “will”

Preferences or goals → “should”

Suggestions or allowances → “may”

Non-requirements → “are”, “is”, “was”

Avoid “must” due to misinterpretations and negative requirements (“shall not”)

Use active voice, not passive.

Characteristics of a Good Set of Requirements

In principle:

1) Complete

2) Consistent

3) Affordable (in budget, time, and life cycle constraints)

4) Bounded (maintains scope)

In practice, it’s impossible to make a complete AND consistent requirements document due to system and environmental complexity

Requirements Scrubbing

Requirements consistency checks

Requirements reviews

Requirements-driven early test case design

Testable requirements

Modeling, simulation, and prototyping to check early requirements validity

Formal specification techniques

Non-Functional Classifications

Product Requirements — specifies that delivered product behaves in a particular way (execution speed, reliability, etc)

Organizational Requirements — a consequence of organizational policies and procedures (process standards used, implementation requirements, etc)

External Requirements — Arises from factors external to system (interoperability requirements, legislative requirements, etc)

Example of Non-Functional Requirements

Metrics for Specifying Non-Functional Requirements

Speed, Size, Ease of Use, Reliability, Robustness, Portability

Requirements Engineering Processes

Common Generic Activities:

1) Requirements elicitation and analysis

2) Requirements specification

3) Requirements Validation

4) Requirements Management

In practice, RE is an iterative activity in which these processes are interleaved.

Requirements Elicitation and Analysis

Discovery, classification and organization, prioritization and negotiation, and specification of requirements

Problems: stakeholders don’t know what they want and can’t express requirements, different stakeholders may have conflicting requirements, influence from organizational and political factors, changing requirements from new stakeholders or business environment

Problems with Interviews

Technical or language gaps between application specialists and requirements engineers

Not good for understanding domain requirements

Thus, use ethnography (social scientists)!

Scenarios

Structured form of user story

Should include:

• Description of starting situation

• Description of normal flow of events

• Desc of of what can go wrong

• Information about other concurrent activities

• Description of the state when the scenario finishes

Requirements Specification

Process of writing down user and system requirements in a requirements document; should be as complete as possible as it may be used for contracts

User requirements → understandable to non-technical backgrounds and end-users

System requirements → more detailed and includes more technical information

Requirements Representations

Natural language, structured natural language, design description languages, graphical notations, mathematical specifications

Structured Specification

Approach to writing requirements where the freedom of the requirements writer is limited, and requirements are written in a standard way

Works well for some types of requirements (like for an embedded control system), but sometimes too rigid for writing business system requirements

Tabular Specification

Used to supplement natural language; useful when you have to define a number of possible alternative courses of action

Tabular Specification + Class Responsibility Collaborator (CRC) Modelling

Class — name of class

Responsibility — attributes and operations that’re relevant for class (anything it does or knows)

Collaborator — classes that are required to provide current class with info needed to complete responsibility (a request for info or action)

Use Cases

A kind of scenario included in the UML that identifies actors in interaction and describes interaction itself

A set of use cases should describe all possible interactions within system

Requirements Validation

Concerned with demonstrating that the requirements define the system that the customer really wants due to requirement error costs being very high

Fixing requirements error may cost 100x the cost of fixing an implementation error

Requirements Checks

Validity (does system provide functions which best support customer needs?)

Consistency

Completeness

Realism (can it be done given available budget and tech?)

Verifiability

Requirements Validation Techniques

Requirements reviews

Prototyping

Test-case generation

Requirements Management

Process of managing changing requirements during RE process and system development

New requirements emerge as a system is being developed and after it’s gone into use

Must keep track of individual requirements and maintain links between dependent requirements to assess impact of requirement changes

Must establish formal process for making change proposals and linking these to system requirements

Changing Requirements

Business and technical environment of system always changes after installation

People who pay for system and users of system are rarely the same people

Large systems usually have diverse user community, with many users having different requirements and priorities that may be conflicting/contradictory

Requirements Management Planning

Establishes level of requirements management detail that’s required.

Requirements management decisions:

• Requirements identification → each requirement must be uniquely identified (used for cross-referencing between other requirements)

• A change management process → set of activities that assess impact and cost of changes

• Traceability policies → defines relationships between each requirement and between requirements and system design

• Tool support tools → ranges from specialist requirements and management systems to spreadsheets and simple databases

Requirements Change Management

Deciding if requirements change should be accepted

Stages:

• Problem analysis and change specification

• Change analysis and costing

• Change implementation

Structure of Requirements Document

Preface

Introduction

Glossary

User requirements definition

System architecture

System requirements specification

System models

System evolution

Appendices

Index