View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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
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.
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