"101 Uses of Requirements" A talk on the reasons for engineering requirements

1. "101 Uses of Requirements"A talk on the reasons for engineering requirements Ian Alexander System Architect User Group, 2001

2. System Subsystem 1 Subsystem 2 Subsystem 3 Assembly c Assembly a Assembly b Software Program y Hardware Device x Requirements Aren't Only for Software Systems can be composed of subsystems of any type

3. Engineered System World satisfies satisfies Different Types of Requirement User Requirements System Requirements System Design/ Architecture Desired Resultsto overcome Problemsin the World Engineered Solutionsusing new and existing Systems … need to be thought about differently

4. 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?

5. Must not conflict! Must not conflict! 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

6. Users, Systems, Actors, Stakeholders Stakeholders Actors Users Systems

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

8. Example Viewpoints Burglar Alarm Viewpoints: Householder – want to be safe in my house, not lose valuables Maintenance Engineer – want a job; want alarm to be easy to diagnose and repair Police – want to reduce crime; no nuisance from ringing alarms Shareholder – want annual income based on alarm sales and contracts to monitor & maintain alarms IEE, BSI – want systems to conform to standards, be electrically safe

9. Types of Viewpoint These can be Actors System Direct Operator Maintenance Viewpoint Engineering Standards Regulatory Indirect Organisation These influence our system from outside Environment After Sommerville & Kotonya

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

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

12. token Capturing Scenarios • A workshop can represent a sequence of tasks directly by role-play • Users often understand processes for the first time next user states role, activity… user states role & activity, identifies next user(s), throws token(s)

13. 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 Acceptance Test Scripts System Usage Scenarios System Test Scripts System Operations Manual System Maintenance Manual Training Courses/Manuals 99 Uses for Scenarios... Problem Domain Scenarios

14. threatens Driver Driver Driver Steal the Car Car Thief Car Thief Eliciting Functional and Non-Functional Requirements: Use & Misuse Cases Drive the Car includes mitigates includes Lock the Car threatens Short the Ignition includes mitigates Lock the Transmission Use Cases for 'Car Security'

15. Exceptions Not set Alarm failed Wrong PIN Exceptions Not shut Exceptions Alarm failed Animal in house Owner/friend in house Wind triggers alarm Capturing Exceptions Set Alarm Shut Door Watch for Intrusion

16. Gathering, Capturing, Eliciting • is about understanding business & system context • creates user requirements and constraints • many possible approaches and methods Do requirements exist before you go out to capture them?

17. 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 Sources of Requirements

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

19. Plan the Review Cycle Obtain Review Comments Classify & Sort Comments Conduct Review Meeting All reviewers work from same version Update Requirements Document Execute Agreed Actions Pre-review Baseline Post-review Baseline Requirements Review Approved version

20. 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?

21. 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?

22. 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?

23. SR Activities • Trace Between Items • Model Desired Behaviour • Define Constraints • Specify Requirement Attributes

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

25. Backwards/forwards Traceability go forwards to assess impact of a change System Design System Specifications User Requirements go backwards to trace origins of a component Logical links can be followed in either direction

26. Traceability Example Impact of requirements on design (in another document) is found from traceability links

27. 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, …)

28. Information Model(of requirement traceability) • Explicitly named relationships • Relationship has a type and a direction • Simple mapping between user concepts and data structures Typed, Directional Traceability Relationship Document / Data Structure

29. Traceability Matrix

30. Traceability Graph (Back-to-Back Trees)

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

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

33. 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,… System Behaviour ModellingDefines Exactly What Is Needed

34. What to Model, and When To 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

35. TraditionalversusUML [Context]Context Diagram Agent Interactions, or Use 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

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

37. Types of Constraint(including ‘ilities’) Constraints Product Process External Usability Delivery Legal Reliability Implementation Safety Economic Efficiency Standards Interoperability Performance Many other types Capacity After Sommerville & Kotonya

38. Priority & Other Attributes • Database tracks each item, allowing audit and tracing • User-defined attributes typically include Status and Priority among others

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

40. newly elicited requirements agreed versions, traces, progress 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 • Requirements Development creates and interprets requirements • Requirements Management organises and keeps track of them

41. Manage the Requirements R e q . q u e r y R e q . b r o w s e r s y s t e m Requirements Database T r a c e a b i l i t y R e q u i r e m e n t s import/export s u p p o r t s y s t e m d o c u m e n t Traceability Matrix C h a g e c o n t r o l n R e p o r t g e n e r a t o r s y s t e m Metrics, Graphs, etc R e q u i r e m e n t s r e p o r t

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

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

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

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

46. 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”

47. User Requirements Definition System Requirements Definition System Design Definition Sub-system Requirements Definition Sub-system Definition Building Block Requirements Definition Building Block Design Building Block Manufacture And Requirements are the foundation of V&V! Validation (that we have the right requirements for the next version) Operational Acceptance Verification (that the system does meet its requirements) Operational Trials System Testing Verification (of each sub-system) System Integration Sub-system Testing Validation(that we have the right requirements now) Verification (of each building block) Sub-system Integration Building Block Testing Building Block Commissioning

48. Soft SystemsEngineering Human Factors Engineering Software Engineering Enterprise Management SystemsEngineering Verification Engineering Project Management Hardware Engineering Requirements Engineering

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