Upload
theodore-haynes
View
258
Download
4
Embed Size (px)
Citation preview
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 1
Chapter 7
Requirements Engineering Process
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 2
Objectives
To describe the principal RE activities. To introduce techniques for requirements
elicitation and analysis. To describe requirements validation. To discuss the role of requirements
management in support of other RE processes.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 3
RE processes…
Vary widely depending on: Application domain People involved Organization developing the requirements
Generic activities common to most: Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation
core, iterative activities
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 4
RE Process Model
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 5
Spiral RE Process Model
Requirementsspecification
Requirementsvalidation
Requirementselicitation
System requirementsspecification and
modeling
Systemrequirements
elicitation
User requirementsspecification
Userrequirements
elicitation
Business requirementsspecification
Prototyping
Feasibilitystudy
Reviews
System requirementsdocument
Emphasizes iterative natureof core activities
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 6
Feasibility StudyFeasibility study issues
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 7
Feasibility study
Aims to answer three basic questions: Would the system contribute to overall
organizational objectives? Could the system be engineered using
current technology and within budget? Could the system be integrated with other
systems already in use?
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 8
Feasibility study issues (a high-level checklist)
How would the organization cope if the system wasn’t implemented?
What are the current process problems and how would the system help with these?
What will the integration problems be? Is new technology needed? New skills? What must be supported by the system, and what
need not be supported?
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 9
Elicitation and AnalysisProblems
Process activities
Viewpoint-oriented elicitation
Method-based RE
Interviewing
Scenarios
Social and organizational factors
Ethnography & focused ethnography
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 10
Elicitation and analysis
Involves working with customers to learn about the application domain, the services needed and the system’s operational constraints, etc.
May also involve end-users, managers, maintenance personnel, domain experts, trade unions, etc. (That is, other stakeholders.)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 11
Problems of elicitation and analysis
Getting all, and only, the right people involved
Stakeholders often: don’t know what they really want
express requirements in their own terms.
have conflicting or competing requirements.
Requirements naturally change as insight improves. (Should this really be thought of as a problem?)
(cont'd)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 12
Problems of elicitation and analysis (cont’d)
New stakeholders may emerge. Political or organizational factors may affect
requirements. (Examples?)
The environment may evolve during the RE process.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 13
Elicitation and analysis process activities Requirements discovery
Interacting with stakeholders to discover product and domain requirements
Requirements classification and organization Grouping and organizing requirements to facilitate
analysis Prioritization and negotiation
Prioritizing requirements and resolving requirements conflicts.
Requirements documentation Requirements are documented and input into the
next round of the spiral.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 14
Elicitation and Analysis spiral
Requirementsclassification and
organisation
Requirementsprioritization and
negotiation
Requirementsdocumentation
Requirementsdiscovery
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 15
Viewpoint-oriented elicitation
Stakeholders represent different ways of looking at a problem (“viewpoints”).
A multi-perspective analysis is important as there is no single correct way to analyze system requirements.
Provides a natural way to structure the elicitation process and organize requirements.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 16
Types of viewpoints Interactor viewpoints
People or other systems that interact directly with the system.
Indirect viewpoints Stakeholders who do not use the system
themselves but who influence the requirements. Domain viewpoints
Domain characteristics and constraints that affect the requirements.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 17
Method-based RE “Structured methods” to elicit, analyze,
and document requirements. Examples include:
Ross’ Structured Analysis (SA), Volere Requirements Process (www.volere.co.uk) Knowledge Aquisition and Sharing for Requirement
Engineering (KARE) Esprit project
(http://cordis.europa.eu/esprit/home.html), Sommerville’s Viewpoint-Oriented Requirements
Definition (VORD), and Thebaut’s Scenario-Based Requirements Engineering
(SBRE)
part of “SA/SD”Suzanne & James
Robertson, Atlantic Systems Guild
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 18
Volere Requirements Process
Start here
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 22
VORD standard formstwo points of reference
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 23
Interviewing RE’s meet with stakeholders to discuss
the system currently in place and the system to be developed.
May be: formal or informal closed (with a pre-defined agenda), open
(no pre-defined agenda), or a mix Useful for learning how stakeholders
might affect or be affected by the system.
(cont'd)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 24
Interviewing (cont’d) Less useful for learning about domain
requirements since: RE’s may not understand domain-specific
terminology; stakeholders may not communicate such
requirements because they are so obvious (to the stakeholders)
Gause & Weinberg (“Exploring Requirements:
Quality Before Design,” Dorset House, 1989) describe many useful interviewing techniques.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 25
Scenarios
Depict examples or scripts of possible system behavior
People often relate to these more readily than to abstract statements of requirements “Give me an example to help tie the parts together” (into a coherent whole.)
Particularly useful in elucidating fragmentary, incomplete, or conflicting requirements
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 26
Scenario elements
1. System state at the beginning of the scenario (if relevant)
2. Sequence of events for a specific case of some generic task the system is required to accomplish.
3. Any relevant concurrent activities.
4. System state at the completion of the scenario.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 27
A simple scenario
t0: The user enters values for input array A. The values are [1, 23, -4, 7, 19].
t1: The user executes program MAX.
t2: The value of variable BIG is 23 and the values of A are [1, 23, -4, 7, 19].
(Compare this to the interface and operational specification examples from the Chap. 6 lecture notes.)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 28
Scenario-Based Requirements Engineering (Thebaut)
A CASE tool supports the rapid construction of an operational specification of the desired system and its environment.
Utilizes a forward chaining, parallel, rule-based language.
An interpreter executes the specification to produce natural language based scenarios of system behavior.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 29
Scenario representation in VORD (Sommerville)
VORD supports the graphical description of multi-threaded “event scenarios” to document system behavior: Data provided and delivered Control information Exception processing The next expected event
Multi-threading supports description of exceptions. (blurs the distinction between scenarios and operational specifications)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 30
Scenario for a “start transaction” event
different scenarios
different scenarios
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 31
UML use-cases and sequence diagrams
Graphical notations for representing abstract scenarios in the UML. (UML is the de facto standard for OO Analysis & Design)
Identify actors in an interaction and describe the interaction itself.
A set of use-cases should describe all types of interactions with the system.
Sequence diagrams show the sequence of event processing.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 33
Catalogue management sequence diagram
time
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 34
Social and organizational factors
All software systems are used in a social and organizational context. This can influence or even dominate system requirements.
Good analysts must be sensitive to these factors, but there is currently no systematic way to tackle their analysis.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 35
Example
• Consider a system which allows senior manage-ment to access information without going through middle managers. Managerial status – Senior managers may feel that
they are too important to use a keyboard. Managerial responsibilities – Managers may not have
time to learn how to use the system Organizational resistance – Middle managers who will
be made redundant may deliberately provide misleading or incomplete information so the system will fail.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 36
Ethnography
A social scientist observes and analyzes how people actually work.
Subjects do not have to explain or otherwise articulate what they do.
Social and organizational factors of importance may be observed.
Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.
(Good for studying existing practices, but how will things change when the new system is introduced?)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 37
Focused ethnography
Developed during a project studying the air traffic control process.
Combines ethnography with prototyping. Prototype development raises issues which focus
the ethnographic analysis. Problem with ethnography alone: it studies
existing practices which may not be relevant when a new system is put into place.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 38
Requirements Validationattributes
techniques
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 39
Requirements validation
Concerned with whether or not the requirements define a system that the customer really wants. (as opposed to needs?)
Requirements error costs are high, so early validation is very important. (Fixing a requirements error after delivery may cost 100 times that of fixing an error during implementation.)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 40
Requirements attributes Validity: Does the system provide the functions
which best support the customer’s needs? Consistency: Are there any requirements
conflicts? Completeness: Are all functions required by the
customer included? Realism: Can the requirements be implemented
given available budget and technology Verifiability: Can the requirements be tested?
(More precisely, can the system be tested to determine whether or not the requirements are met?)
(as opposed to wants?)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 41
Requirements validation techniques
Requirements reviews / inspections – systematic manual analysis of the requirements.
Prototyping – using an executable model of the system to check requirements. Covered in Chapter 17.
Test-case generation – developing tests for requirements to check testability.
Automated consistency analysis – checking the consistency of a structured requirements description. (CASE – e.g., “Wisdom” tool in KARE workbench)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 42
Requirements reviews / inspections
Regular reviews should be held while require-ments are being formulated.
Both client and contractor staff should be involved in reviews. (+ other stakeholders…who?)
Reviews may be formal or informal…
Good communication between developers, customers and users can resolve problems at an early stage.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 43
Review check-list
Verifiability: Is the requirement testable? Comprehensibility: Is the requirement
understandable? Traceability: Is the origin of the requirement
clearly stated? and rationale!
Adaptability: Can the requirement be changed with minimum impact on other requirements? (Especially when change is anticipated!)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 44
Requirements ManagementEnduring vs. volatile requirements
Planning considerations
Traceability
CASE support
Change management process
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 45
Requirements management…
…is the process of understanding and controlling requirements change.
Requirements evolve, priorities change, and new requirements emerge as a better understanding of the system is
developed, and the business and technical environment of
the system changes.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 46
Enduring and volatile requirements
Enduring requirements: Stable requirements derived from the core activity of the customer organization. (E.g., a hospital will always have doctors, nurses, etc. May be derived from domain models.)
Volatile requirements: Requirements which change during development or when the system is in use. (E.g., requirements derived from the latest health-care policy.)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 47
Types of volatile requirements Mutable – those that change due to changes
in the organization’s operating environment. Emergent – those that emerge as a better
understanding of the system develops. Consequential – those that result from the
introduction of the system. Compatibility – those that change due to
changing systems or processes within the organization.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 48
Requirements management planning requires decisions on:
Requirements identification – how requirements will be individually identified
A change management process – to be followed when analyzing the impact and costs of a requirements change
Traceability policies – the amount of information about requirements relationships that is maintained
CASE tool support – the tool support required to help manage requirements change
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 49
Traceability…
…is concerned with the relationships between requirements, their sources, and the system design.
Types of traceability: Source traceability – links from requirements to
stakeholders who proposed the requirements. (or other sources)
Requirements traceability – links between dependent requirements.
Design traceability – links from the requirements to the design.
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 50
CASE tool support
Requirements storage – in a secure, managed data store
Change management – a workflow process whose stages can be defined and information flow between the stages partially automated
Traceability management – automated discovery and documentation of relationships between requirements (keyword search, common scenarios, etc.)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 51
Change management process
Applied to all proposed requirements changes
Principal stages: Problem analysis – analyze identified
requirements problem and propose specific change(s)
Change analysis and costing – assess effects of change on other requirements
Change implementation – modify requirements document (+ system design and implementation, as necessary) to reflect the change
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 52
Change management process (cont’d)
Changeimplementation
Change analysisand costing
Problem analysis andchange specification
Identifiedproblem
Revisedrequirements
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 53
Key points
The RE process includes a feasibility study, elicitation and analysis, specification, and validation.
Elicitation and analysis involves requirements discovery, classification and organization, prioritization and negotiation, and documentation.
(cont'd)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 54
Key points (cont’d)
Systems have multiple stakeholders with different viewpoints and requirements.
Social and organization factors influence system requirements.
Requirements validation is concerned with checks for validity, consistency, complete-ness, realism, and verifiability.
(cont'd)
©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 55
Key points (cont’d)
Business, organizational, and technical changes inevitably lead to changing requirements.
Requirements management involves careful planning and a change manage-ment process.