"101 uses of requirements" a talk on the reasons for engineering requirements ian...
TRANSCRIPT
"101 Uses of Requirements"A talk on the reasons for engineering requirements
Ian Alexander
System Architect User Group, 2001
Requirements Aren't Only for Software
Systems can be composed of subsystems of any type
System
Subsystem 1 Subsystem 2 Subsystem 3
Assembly a Assembly b Assembly c
Software Program yHardware Device x
Different Types of Requirement
UserRequirements
SystemRequirements
System Design/Architecture
WorldEngineered
System
… need to be thought about differently
satisfies
satisfies
Desired Resultsto overcome Problems
in the World
Engineered Solutionsusing new and existing
Systems
UR Activities• Identify Business Objectives
– Why develop anything?
• Identify Stakeholders– Who is involved?
• Obtain Viewpoints– What are they concerned about?
– Do they conflict?
• Resolve Conflicts?• Identify Scenarios
– What results do people want?
Objectives Example
• "To become the market leader in small-household burglar alarms"
• "To make steadily growing annual income from alarm sales, maintenance, and monitoring"
Clear, Simple, Truthful – with many implied requirements
Must not conflict!
Must not conflict!
Users
Actors
Stakeholders
Users, Systems, Actors, Stakeholders
Systems
Identify Stakeholders
• Initial contact will usually indicate people to talk to, their roles and interests
• Stakeholders include direct system users and indirect interests, e.g. regulators and standards bodies
• Stakeholders may themselves suggest other people who ought to be consulted …
Example Viewpoints
Burglar Alarm Viewpoints:Householder – want to be safe in my house, not lose
valuablesMaintenance Engineer – want a job; want alarm to be
easy to diagnose and repairPolice – want to reduce crime; no nuisance from
ringing alarmsShareholder – want annual income based on alarm
sales and contracts to monitor & maintain alarmsIEE, BSI – want systems to conform to standards, be
electrically safe
Types of Viewpoint
Viewpoint
Direct
Indirect
System
Operator
Regulatory
Organisation
Engineering
Environment
Maintenance
Standards
After Sommerville & Kotonya
These can be Actors
These influence our system from outside
Direct and Indirect Viewpoints• Direct viewpoints
– Interact directly with the System– Clients who receive services– e.g. Operators & Other Systems
• Indirect viewpoints – Do not interact directly with the System– Have an ‘interest’ in services delivered by System– Create constraints on System– e.g. engineering standards, industry regulator
Conflict Resolution
• Disagreements about requirements are inevitable when a system has many stakeholders. Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities
• Expect to have to discuss requirements conflicts and reach a compromise that all stakeholders can agree to
• Important to leave enough time for negotiation. Finding a compromise is often time-consuming
Capturing Scenarios
• A workshop can represent a sequence of tasks directly by role-play
• Users often understand processes for the first time
token
user states role & activity,identifies next user(s),throws token(s)
next user statesrole, activity…
99 Uses for Scenarios...Problem Domain
Scenarios
TrainingCourses/Manuals
System UsageScenarios
System Test Scripts
Acceptance Test Scripts
System MaintenanceManual
System OperationsManual
• Scenarios show what results systems should deliver
• So they are the natural way of checking that systems do what they should
• And defining how systems should be used & maintained
• And teaching people to use them
includes
Eliciting Functional and Non-Functional Requirements:
Use & Misuse Cases
Use Cases for 'Car Security'
threatens
Short the Ignitionincludes
mitigates
Lock the Transmission
Steal the Car
Car ThiefCar Thief
threatens
includes
mitigates
Lock the Car
Drive the Car
DriverDriverDriver
Capturing Exceptions
Set Alarm
Shut Door
Watch for IntrusionNot set
Alarm failed
Wrong PIN
Exceptions
Alarm failed
Animal in house
Owner/friend in house
Wind triggers alarm
ExceptionsNot shut
Exceptions
Gathering, Capturing, Eliciting
• is about understanding business & system context• creates user requirements and constraints• many possible approaches and methods
Do requirements exist beforeyou go out to capture them?
Sources of Requirements• Interviews with users • The system’s environment• Business objectives• Marketing requirements• Contractual obligations• Working in user environment• Analogous or existing systems• Change suggestions, problem reports
• User modifications
• User group meetings
• Workshops
• Prototypes
• Studies
• Innovation work
• Questionnaires
• Consultants & Trainers
• Observation / Fieldwork
Validating Requirements – Are we about to build the wrong system?
• Certify that described system is the wanted system• Check requirements document for
– Completeness and consistency
– Conformance to standards
– Method of testing agreed
• Ensure freedom from – Requirements conflicts
– Technical errors
– Ambiguities
Best to find out before you spend $1000M
Requirements Review
Plan the Review Cycle
Obtain Review
Comments
Classify & Sort
Comments
Conduct Review Meeting
Update Requirements
Document
Execute Agreed Actions
Pre-review Baseline
All reviewers work from
same version
Post-review Baseline
Approved version
Review Checks
• Understandable– Can readers of the document understand what the
requirements mean?
• Stated Once– Is information unnecessarily repeated?
• Complete– Any missing requirements? Any information missing from
individual requirement descriptions?
• Unambiguous– Are all terms clearly defined? – Could readers from different backgrounds interpret the
requirements differently?
Review Checks• Consistent
– Different requirements free from contradictions?
• Organised– Document structured sensibly? – Related requirements grouped together?
• Conforms to standards– Do individual requirements and whole requirements
document conform to standards? Are departures from the standards fully justified?
• Fully Traced– Requirements unambiguously identified?– Links to all related requirements? – Links to justifications?
Requirements Checklist• Is each requirement uniquely identified?• Are all specialised terms defined in the glossary?• Does each requirement stand on its own?• Are terms used consistently?• Are there any contradictions?• Are all mentioned facilities described?• Are all related requirements grouped or cross-referenced?• Can we build it?
SR Activities
• Trace Between Items
• Model Desired Behaviour
• Define Constraints
• Specify Requirement Attributes
Traceability• Traceability is primarily to help assess the impact of
requirements change (tracing forwards to design)• And to demonstrate complete satisfaction of
requirements (tracing backwards from design)• Traces link requirements to other system items• Traces have many other uses and purposes:
– to support verification (linking test steps to requirements and other items)
– to link to reference documents– to link terms to their definitions– … and so on.
Backwards/forwards Traceability
User Requirements
System Design
System Specifications
go forwards to assess impact of a change
go backwards to trace origins of a component
Logical links can be followed in either direction
Traceability Example
Impact of requirements on design (in another document)
is found from traceability links
Example Types of Traceability• satisfies
– Links an item back to its sources (such as a requirement). Each system specification and design element must trace back to at least one source
• defines– Links a definition to a term being used with a particular
meaning within the project. Should be a 1:1 mapping.
• verifies– Links a verification (usually a test) item back to a
requirement that it helps to verify. (Note that several tests may be needed for one requirement, and that one test may help to verify many requirements.)
• ...and many others (constrains, depends on, …)
Information Model(of requirement traceability)
• Explicitly named relationships
• Relationship has a type and a direction
• Simple mapping between user concepts and data structures
Document / Data Structure
Typed, Directional Traceability Relationship
Traceability Matrix
Traceability Graph (Back-to-Back Trees)
Traceability - Making Sure You Build What The Users Want
• Engineers and Reviewers have to be able to refer to each requirement uniquely, but change is inevitable and continuous – making tracing difficult
• Requirements are more stable than implementations, but compatibility and portability requirements are therefore often volatile
• Tool support becomes essential when projects are any of the following: large, distributed, long-lived, safety- or mission-critical, in product families or multiple versions, or subject to change
Model System Behaviour - Objectives
• To explore the solution, avoiding commitment to any specific design
• To Show what the system must do, but not how• To Model the desired behaviour of the system• To Map between the World and the Machine
– between the user requirements and the system design
• Method: constrain the solution space with precise specifications. Often called ‘system requirements’ as distinct from ‘user requirements’
• Focus on functions/constraints that must be flowed down to the physical design to meet the user requirements
• Leave freedom for designers to decide how to partition into sub-systems
System Behaviour ModellingDefines Exactly What Is Needed
• System behaviour descriptions
• End-to-end scenarios/threads
• Timing/sequencing of functionality
• Requirements for parallelism/concurrency
• Data and/or material flows
• Flow of control
• Conformance to mathematical models/algorithms
• Performance requirements
• System constraints and ‘ilities’• Interactions with external systems• Other modes of operation:
– Fall-back/reversionary– Abnormal, degraded & emergency– Recovery– Start, stop, reset, warm-up,…– Test modes– Instrumentation or recording– Training
• Safety interlocks, inhibits, overrides,…
What to Model, and WhenTo Describe: Model with:
Big Picture, Actors’ Story Agent Interactions or Use Case Summary
Sequences of Events Scenarios, Use Casesfirst for business transactions,then for system threads
What can happen, when State Transitionsfor complex subsystems
Detailed structure of data Entity-Relationships or for complex structures Objects & Attributes
Partitioning into subsystems Objects & Messageswith interfaces
Traditional versus UML [Context]
Context Diagram Agent Interactions, orUse Case Summary Diagrams
[Scenarios] Jackson Trees, Flowcharts Use Case text (not diagrams), (Dataflows are unsuitable) Activity Diagrams +/- Swimlanes
[States] State Transition Diagrams State Diagrams
[Data] Entity-Relationship Diagrams Objects & Attributes
[Architecture] Procedure Calling Trees, Objects & Messages, Informal Box-and-Line Object Sequence DiagramsArchitecture Diagrams, Dataflows
Define Constraints
• Capture requirements that are not functions but which constrain the desired system in any way
• Link to specific functions where possible
• Some constraints are global, e.g. end-to-end performance targets
• No perfect universal way to classify constraints – but may be helpful to think through a checklist
Types of Constraint(including ‘ilities’)
Constraints
Process Product External
Delivery
Implementation
Standards
Usability
Reliability
Safety
Efficiency
Performance
Capacity
Legal
Economic
Interoperability
After Sommerville & Kotonya
Many other types
Priority & Other Attributes
• Database tracks each item, allowing audit and tracing
• User-defined attributes typically include Status and Priority among others
Control Changes
• Change comes from many sources – detected errors, user wishes, new technology opportunities, competition, …
• Uncontrolled change derails projects
• Ideal is to permit change in manageable increments at predictable cost
• So, you need a change management policy
Concepts of Requirements Engineering• Requirements Engineering consists of two related streams of activity:
– Requirements Development (Elicitation, Analysis, & Modelling)
– Requirements Management (Identification, Configuration, Prioritisation, Traceability)
Requirements Elicitation, Analysis, & Modelling
Requirements Management
newly elicited requirements
agreed versions, traces, progress
• Requirements Development creates and interprets requirements
• Requirements Management organises and keeps track of them
Manage the Requirements
Requirements Database
Requirementsdocument
Traceabilitysupport system
Report generator
Requirementsreport
Req. browserReq. query
system
Change controlsyste m
import/export
Traceability
Matrix
Metrics,Graphs, etc
Managing the Requirements
• Guaranteeing a solid basis for projects• Receives the products of Elicitation & Modelling
• Consists of 3 quite different kinds of activity– Fine-Grained Configuration Management (CM)
– Coarse-Grained CM
– Fine-Grained Engineering Decision Support
Fine-Grained Configuration Management (CM)• Uniquely identifies every requirement
– solid basis for review e.g. “reqt #123 is ambiguous, please change it”
– foundation of traceability e.g. “reqt #123 is satisfied by design items #345, #346”
– only possible basis for managing versions and releases e.g. “reqt #123 is
– optional in version 1.0
– mandatory in version 2.0”
• Must be available within RM toolkit (however it is done)
• Must be rock-solid
What is a Requirements Release?• A Release is a group of Requirements to be developed together
• The resulting (increment of) functionality is typically released to users as a new Product Version
• Can you just put whatever the users want most in Release 1.0 ?
No!
• Some Requirements depend on others– no point being able to send colour images to cellphones until colour screens exist
• So a Release is a Consistent Interdependent Set of Requirements
• Later Releases can build on earlier ones
• Should (in theory) be easy if Life-Cycle is Incremental
• But since development is often Evolutionary, Release Planning can be hard
Coarse-Grained Configuration Management (CM) • Baselines whole sets of requirements/project documents
– solid basis for reviews, contracts, product releases e.g. “Baseline for System Requirements Review (SR/R) contains
– BR v2.1
– SR v1.0
– AT v1.3
– ST v1.0”
e.g. “We promise to deliver the system specified in SR v1.0 at end of Stage 2”
– builds on the fine-grained definition of what exactly is in each version of each document
• CM should therefore be closely integrated with RM toolkit
• Must keep the document versions securely
Fine-Grained Engineering Decision Support
• Prioritising each requirement– rational basis for trade-offs and hard decisions
e.g. “reqt #124 is nice but not vital”
• Tracing each requirement– rational basis for cost estimation
e.g. “reqt #124 leads to design items costing £xyz”
– rational basis for trade-offs e.g. “reqt #124 is not vital; deleting it will save £xyz”
• Specifying which requirement belongs to which Version / Release– firm basis for agreement between customer & developer
e.g. “reqt #124 waits till v3”
OperationalAcceptance
OperationalTrials
SystemTesting
SystemIntegration
Sub-systemTesting
Sub-systemIntegration
Building BlockTesting
Building BlockCommissioning
SystemRequirementsDefinition
System DesignDefinition
Sub-systemRequirementsDefinition
Sub-systemDefinition
Building BlockRequirementsDefinition
Building BlockDesign
Building BlockManufacture
UserRequirementsDefinition
And Requirements are the foundation of V&V!Validation (that we have the
right requirements for the next version)
Verification (of each sub-system)
Verification (that the system does meet its
requirements)
Verification(of each building block)
Validation(that we have the right
requirements now)
SystemsEngineering
Soft SystemsEngineering
EnterpriseManagement
Project Management
Hardware Engineering
Software Engineering
Human Factors
Engineering
Verification EngineeringRequirements Engineering
101 Uses for Requirements?• No, there are many more than that!• The essential foundation of every project• The little rudder that guides the ship• Why? Who? When? What? How Much?• Impossible without.