Requirements%20Engineering%20

1
Requirements Engineering a brief review

• by
• Andy Gillies

2
Session Aims

• 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.

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
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.s
ei.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
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
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.

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