|
Elements used |
How this Approach Describes Need |
Schools of Thought Favouring this Approach |
Books and Websites on this Approach |
Disadvantages of Using this Approach Alone |
| Stakeholder Analysis (Chapter 2) |
Identifies the political, economic, social, and cultural forces which drive design |
Soft Systems Methodology (CATWOE*, informal models such
as rich pictures).
Note that SSM precedes system development, and could identify a need for several products. |
Checkland: Soft Systems
Methodology |
No precise, verifiable description of system requirements; unsuitable for contracts |
| Goal Modelling (Chapter 3) |
Says what stakeholders want | KAOS (logical goal decomposition); |
Lamsweerde: Requirements
Engineering Sutcliffe: User-Centred Requirements Engineering, chapter 3 Betty Cheng: Goal Modelling (tutorial) |
Hard to express timing relationships (scenarios) between goals; danger of diving into design without considering alternatives |
| Event-Driven Analysis (in Chapter 4) |
Identifies events at interfaces, and says how to handle them | Event-Driven methods | Wiley: Essential System Requirements Robertson: Mastering the Requirements Process |
Assumes context is well-defined: does not attend to soft systems issues or conflicting stakeholder goals |
| Scenario Analysis (Chapter 5) |
Says how design will deliver results to human operators |
Cockburn-style Use Cases; Agile (user stories) |
Cockburn: Effective Use Cases Cohn: User Stories Applied Alexander & Maiden: Scenarios, Stories, Use Cases |
Over-emphasis on product behaviour; risk of ignoring qualities and constraints from non-operational stakeholders; danger of diving into interaction and user interface design without justification or clear priorities |
| Reuse – Standards & Templates (in Chapter 6) |
Defines generally needed qualities, constraints, and procedures for achieving them | Standardisation, Regulation, Quality Assurance |
Volere (Template) | Functions and innovative aspects specific to the new product are not covered |
| Rationale Modelling (Chapter 7) |
Explains why design is needed, or what is needed to make it safe |
Compendium project and tool (informal rationale diagrams) GSN, CAE (safety case diagrams) |
Dewar: Assumption-Based Planning Kirschner: Visualizing Argumentation Toulmin: The Uses of Argument Dick: Rich Traceability |
As for goal modelling, lacks timing (scenarios); danger of deciding on a solution and devising reasons that support it |
| Data Modelling (in Chapter 8) |
Defines the data, rules and relationships to ensure business works properly | UML class modelling; traditional entity-relationship data modelling |
Fowler: UML Distilled |
Lack of vision of end-to-end behaviour (scenarios), context, purpose |
| Measurement (Chapter 9) |
Shows exactly what results the design must provide | Traditional; (list of “The system shall…” requirements) |
Alexander &
Stevens: Writing Better Requirements Gilb: Competitive Engineering |
Requirement wording has to carry whole burden of defining terms, context, scenarios, timing; easy to lose sight of stakeholders, goals and purpose |
| Priorities, Trade-offs (Chapters 10, 14) |
Shows which design features are needed most, or would be most profitable | Business Case; Benefit/Cost Analysis; Value Engineering (spreadsheets) |
Davis: Just Enough Requirements Management | Suggests requirements are independent and can be compared financially; tends to ignore context, purpose, qualities, constraints, non-financial beneficiaries |
*CATWOE (in Soft Systems Methodology):
Customers: I'd call these Beneficiaries and (Normal) Operators (in the Onion Model of Stakeholders), as Checkland implies many roles here.
(c) Ian Alexander 2009