Introduction to Software Requirements

Dr Suad AlRamouni

◦ Understand some key terms used in software requirements engineering.

◦ Distinguish requirements development from requirements management.

◦ Be alert to some requirements-related problems that can arise.

◦ Learn several characteristics of excellent requirement

Learning Outcomes

Lack of user input, incomplete requirements, and changing requirements are the major reasons why so many information technology projects fail to deliver all of their planned functionality on schedule and within budget

Many software developers aren’t comfortable or proficient at gathering requirements from customers.

Customers often don’t have the patience to participate in requirements development, or they have the wrong people supply the requirements

Why Software projects fail?

Project participants often don’t even agree on what a "requirement" is?

Software development involves at least as much communication as computing, yet we often emphasize the computing and neglect the communication.

Case Study

The Essential Software Requirement◦ Many software problems arise from shortcomings

in the ways that people gather, document, agree on, and modify the product’s requirements. As with Phil and Maria, the problem areas might include informal information gathering, implied functionality, erroneous or uncommunicated assumptions, inadequately defined requirements, and a casual change process

Part I. Software Requirements: What, Why, and Who

Errors made during the requirements stage account for 40 to 60 percent of all defects found in a software project

The two most frequently reported problems in a large survey of the European software industry concerned specifying and managing customer requirements.

Bad Requirements Costs!

Nonetheless, many organizations still practice ineffective methods for these essential project activities. The typical outcome is an expectation gap, a difference between what developers think they are supposed to build and what customers really need.

Nowhere more than in the requirements process do the interests of all the stakeholders in a software or system project intersect. These stakeholders include◦ Customers who fund a project or acquire a

product to satisfy their organization’s business objectives.

◦ Users who interact directly or indirectly with the product (a subclass of customers)

◦ Requirements analysts who write the requirements and communicate them to the development community.

Stakeholders

◦ Developers who design, implement, and maintain the product.

◦ Testers who determines whether the product behaves as intended.

◦ Documentation writers who produce user manuals, training materials, and help systems.

◦ Project ne whether the product behaves as managers who plan the project and guide the development team to a successful delivery.

◦ Legal staff who ensure that the product complies with all pertinent laws and regulations.

◦ Manufacturing people who must build the products that contain software.

◦ Sales, marketing, field support, help desk, and ◦ other people who will have to work with the

product and its customers

Requirements Engineering Process

Processes used to discover, analyse and validate system requirements

requirement is "anything that drives design choices" (Lawrence 1997).

Requirements Engineering Processes

The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as

1. A condition or capability needed by a user to solve a problem or achieve an objective.

2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

3. A documented representation of a condition or capability as in 1 or 2.

◦ The following definition acknowledges the diversity of requirements types (Sommerville and Sawyer 1997):

Requirements are...a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system

Software requirements include three distinct levels—business requirements, user requirements, and functional requirements.

In addition, every system has an assortment of nonfunctional requirements.

Software requirements – cont’d

The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements

However, there are a number of generic activities common to all processes

Requirements engineering processes

Requirements Elicitation

Requirements Analysis

Requirements

Specification

Requirements Validation

Requirements

Management

Requirements Engineering Process

Requirements Engineering

Requirements Developments

Elicitations Analysis Specification Validation

Requirements Management

Sometimes called requirements elicitation or requirements discovery

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints

May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

Elicitation

Stakeholders don’t know what they really want

Stakeholders express requirements in their own terms

Different stakeholders may have conflicting requirements

Organisational and political factors may influence the system requirements

The requirements change during the analysis process. New stakeholders may emerge and the business environment changes

Problems of requirements analysis

The requirements analysis process

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry

Generic model: each organization has its own version

Domain understanding (how the organization operates)

Requirements collection (interaction with stakeholders)

Classification (into coherent clusters) Conflict resolution (find & resolve) Prioritisation (interaction with

stakeholders, identification of most important requirements)

Requirements checking (completeness, consistency, real needs)

Process activities

CONTINUOUS FEEDBACK BETWEEN ACTIVITIES

Concerned with demonstrating that the requirements define the system that the customer really wants

Requirements error costs are high so validation is very important◦ Fixing a requirements error after delivery may cost

up to 100 times the cost of fixing an implementation error (it goes through specs, design and implementation)

Requirements validation

Validity. Does the system provide the functions which best support the customer’s needs?

Consistency. Are there any requirements conflicts or different descriptions of the same function?

Completeness. Are all functions (and constraints) required by the customer included?

Realism. Can the requirements be implemented given available budget and technology?

Verifiability. Can the requirements be checked?

Requirements checking

Types of Checks:

Requirements reviews◦ Systematic manual analysis of the requirements

Prototyping◦ Using an executable model of the system to check

requirements Test-case generation

◦ Developing tests for requirements to check testability

◦ Tests difficult to implement reveal potential difficulty of implementing requirements

Automated consistency analysis◦ Checking the consistency of a structured

requirements description (formal notation) using a dedicated CASE tool

Requirements validation techniques

Automated consistency checking

Requirementsdatabase

Requirementsanalyser

Requirementsproblem report

Requirementsprocessor

Requirementsin a formal language

Regular reviews should be held while the requirements definition is being formulated

Both client and contractor staff should be involved in reviews

Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage

Requirements reviews

Verifiability. Is the requirement realistically testable?

Comprehensibility. Is the requirement properly understood by procurers or end-users?

Traceability. Is the origin of the requirement clearly stated?

Adaptability. Can the requirement be changed without a large impact on other requirements?

Review checks

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

Requirements are inevitably incomplete and inconsistent◦ New requirements emerge during the process as

business needs change and a better understanding of the system is developed

◦ Different viewpoints have different requirements and these are often contradictory

Requirements management

The priority of requirements from different viewpoints changes during the development process

System customers may specify requirements from a business perspective that conflict with end-user requirements

The business and technical environment of the system changes during its development

Requirements change

Requirements evolution

Changedunderstanding

of problem

Initialunderstanding

of problem

Changedrequirements

Initialrequirements

Time

Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. Requirements may be derived from domain models

Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

Enduring and volatile requirements

Evolution perspective : Two classes of requirements

Mutable requirements◦ Requirements that change due to the system’s

environment Emergent requirements

◦ Requirements that emerge as understanding of the system develops

Consequential requirements◦ Requirements that result from the introduction of

the computer system (change of working processes)

Compatibility requirements◦ Requirements that depend on other systems or

organisational processes

Classification of volatile requirements

During the requirements engineering process, you have to plan:◦ Requirements identification

How requirements are individually identified◦ A change management process

The process followed that assess the cost and impact of changes

◦ Traceability policies The amount of information about requirements

relationships that is maintained◦ CASE tool support

The tool support required to help manage requirements change

Requirements management planning

Traceability is concerned with the relationships between requirements, their sources and the system design

Source traceability◦ Links from requirements to stakeholders who

proposed these requirements Requirements traceability

◦ Links between dependent requirements to assess how many other requirements will be affected

Design traceability◦ Links from the requirements to the design

modules that implement them

Traceability

A traceability matrix

Req.id

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 U R1.2 U R U1.3 R R2.1 R U U2.2 U2.3 R U3.1 R3.2 R

Used to represent traceability information (for a small number of reqs)

A “U” is used when a req. in a row uses the facilities of the req. in the column

An “R” is used when there is a weaker relationship (e.g. reqs are part of the same sub-system)

Requirements storage◦ Requirements should be managed in a secure,

managed data store Change management

◦ The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated

Traceability management◦ Automated retrieval of the links between

requirements

CASE tool support

Should apply to all proposed changes to the requirements

Principal stages◦ Problem analysis and change specification. Discuss

requirements problem and propose change◦ Change analysis and costing. Assess effects of

change on other requirements◦ Change implementation. Modify requirements

document and other documents to reflect change

Requirements change management

Requirements change management

Changeimplementation

Change analysisand costing

Problem analysis andchange specification

Identifiedproblem

Revisedrequirements