1

Requirements Engineering – a brief

review

byAndy Gillies

2

The session aims to review the fundamentals of the requirements engineering process and provide participants with:

An overview Requirements Engineering process. Orient themselves. Relate current position to it.

An understanding of the of Requirements Engineering processes.

Relationship between Systems Engineering and Requirements.

Session Aims

3

Overview Introduction and Orientation. The Bigger Picture. The Requirements Engineering

Process. Managing Requirements.

4

What is a Requirement? “the effects that a client wishes to be

brought about in the problem domain” “properties that the new system must

possess” (Bray 2002)

“System requirements define what the system is required to do and the circumstances under which it is to operate” (Kotonya & Sommerville 1998)

5

Why Bother? Study after study has found that where

there is a failure, requirements problems are usually at the heart of the matter. (Glass, 1998)

See Glass for failings Also: http://catless.ncl.ac.uk/Risks

Forum On Risks To The Public In Computers And Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

6

The Bigger Picture – Systems & Requirements

7

System & Subsystem Requirements

System

Software Hardware

Software component Hardware component

HCI

Various levels of requirements exist.

8

System? Consider the Airbus: Airbus as a product to be built. Airbus as a system. Airbus as part of an Airways system

National International

Requirements exist at all these levels.

9

High Level System Requirements Sources:

Business. Legal. Society.

Impact: Imperative – make or break the system. Goals that drive the process (and the

product). i.e. Why are we doing/building this? Global.

10

Eg: Business Factors Players:

Senior Management. Role:

Highest level stakeholder. Identify a business need.

Impact: Paying for the system. Provides overall goal. System satisfies a business need.

11

Stakeholders (defined in CMMI models)

http://www.sei.cmu.edu/cmmi/faq/term-faq.html

Difference between “stakeholder” and a “relevant stakeholder?”"stakeholder"

•"a group or individual who is affected by or is in some way accountable for the outcome of an undertaking.“

"relevant stakeholder" •a subset of the term "stakeholder" and describes people or roles that are designated in the plan for stakeholder involvement.

"stakeholder" may describe a very large number of people.• a lot of time and effort would be consumed by attempting to deal with all of them. So, "relevant stakeholder" is used in most practice statements to describe the people identified to contribute to a specific task.

12

Global Requirements What the system does as a whole. Not part of any subsystem. Can emerge at any time. Impact

Highly coupled. Costly to change. Not part of any subsystem.

13

System Modelling-Why? “The ability of a requirements writer to

specify a system correctly is primarily a function of the number of techniques that the writer knows” .

(Chambers 1997) Growth in systems modelling compared to

definition (generally text). More understandable (Visibility). Show behaviour, structure. MDD (Model Driven Development).

14

Requirements & the Systems Life Cycle

Requirements

System Design

Coding

Feasibility

Detailed Design

Integration Testing

Unit Testing

Maintenance/Operation

Acceptance TestingQ

V Model

15

Definition of Requirements Engineering

involves all life-cycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and validation of the documented requirements against user needs, as well as processes that support these activities. (DoD 91)

16

Component Parts Of Requirements Engineering

Management

Validation Specification

Analysis

Elicitation

RE

17

Problem Analysis - definition

Problem analysis is the activity that: encompasses learning about the problem

to be solved (often through brainstorming and/or questioning),

understanding the needs of the potential users, trying to find out who the user really is, and understanding all the constraints of the solution.

Davis 1993

18

Characteristics of Analysis

Understand problem domain. Represent it (model) NOT the solution system.

19

What Is Analysis? “meaningful,short and simple

designation not possible” Through study of a problem domain,the

achievement of understanding of and the documentation of the characteristics of that domain and the problems (requiring solution) that exist within that domain.

(Bray 2002)

20

Outputs of Analysis Problem domain description/model. Requirements statement = solution. Note:

Requirements statement = effects required to solve problem.

Specification = required behaviour of the solution system.

21

Specification Interface between the problem and

the solution. Requirements are specified as

behaviour.

Problem Domain

Solution System

Interface

AnalysisSpecification Design

22

Manifestation Creative process :

Create the solution system behaviour. Client describes system behaviour

required. Document.

Client vague. Invent behaviour - then check with Client.

23

Characteristics of a good Specification (Bell, 2005)

Implementation free Complete Consistent Unambiguous Concise Minimal Understandable Achievable Testable

24

Output Specification Document. What Goes in a Specification

Document? Some confusion:

Requirements (analysis) documentation and specification not separated.

25

Validating Requirements Checks. Reviews. Prototyping. Model Validation. User manual. Testing.

26

Managing Requirements

Traceability.Volatile requirements.

Change.High-level system

requirements. Rejected requirements.

27

References Bell, D (2005) Software Engineering for Students, A

programming Approach, Addison-Wesley Bray, I, K (2002) An introduction to Requirements

Engineering. Addison-Wesley Chambers, L (1997) Modelling Software Requirements:

http://www.chambers.com.au/Marketing/mod_reqw.htm Davis, A, M (1993) Software Requirements:

Objects,Functions and States. Englewood Cliffs, New Jersey. Prentice-Hall.

Definition of Requirements Engineering [DoD 91] Department of Defense. Software Technology

Strategy. DRAFT: December, 1991. Glass, R (1998) Software Runways, Harlow,Prentice-Hall Kotonya, G & Sommervile, I. Requirements Engineering.

Processes and Techniques. Wiley (1998) Sommerville, I. Software Engineering, Addison-Wesley,

1997

28

Practical Exercise Systems and Requirements.

29

The END