1. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 Lecture 2:Requirements and Projects Ü Two basic principles of requirements engineering:  Separate the problem from the solution  Problems and solutions intertwine with one another Ü Describing problems:  Application Domains vs. Machine Domains  Verification vs. Validation Ü Systems Engineering  Systems vs. software Ü Patterns and Types of Problem  Requirements patterns  Problem Frames Ü Project  Types & Context Ü Requirments Life-Cycle

2. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 Separate the problem from the solution Problem Statement Implementation Statement System Correspondence Correctness Validation Verification Ü A separate problem description is useful:  Most obvious problem might not be the right one to solve  Problem statement must be discussed with stakeholders  Problem statement can be used to evaluate design choices  Problem statement is a source of good test cases Ü Still need to check:  Solution correctly solves the stated problem  Problem statement corresponds to the needs of the stakeholders Problem Situation

3. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 Problem Situation But design changes the world… abstract model of world implementation statement problem statement change System

4. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4 Intertwining of problems and solutions Implementation Dependence Dependent Independent General Detailed Level of Detail Implementation Statement Problem Statement Path of exploration

5. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5 Some observations about RE Ü RE is not necessarily a sequential process:  Don’t have to write the problem statement before the solution statement  (Re-)writing a problem statement can be useful at any stage of development  RE activities continue throughout the development process Ü The problem statement will be imperfect  RE models are approximations of the world  will contain inaccuracies and inconsistencies  will omit some information.  analysis should reduce the risk that these will cause serious problems… Ü Perfecting a specification may not be cost- effective  Requirements analysis has a cost  For different projects, the cost-benefit balance will be different Ü Problem statement should never be treated as fixed  Change is inevitable, and therefore must be planned for  There should be a way of incorporating changes periodically

6. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6 A problem to describe… Ü E.g. “prevent unauthorized access to DSIC machines” encryption algorithmsstudents intruders password allocation process stickies with passwords on T-cards sysadmins signed forms passwords usernames typing at keyboard password files memory management cache contents secure sockets things the machine cannot observe things private to the machine shared things

7. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7 Application Domain Machine Domain D - domain properties R - requirements C - computers P - programs What are requirements? Ü Domain Properties:  things in the application domain that are true whether or not we ever build the proposed system Ü Requirements:  things in the application domain that we wish to be made true by delivering the proposed system  Many of which will involve phenomena the machine has no access to Ü A Specification:  is a description of the behaviours that the program must have in order to meet the requirements  Can only be written in terms of shared phenomena!

8. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8 Fitness for purpose? Ü Two correctness (verification) criteria:  The Program running on a particular Computer satisfies the Specification  The Specification, in the context of the given domain properties, satisfies the requirements Ü Two completeness (validation) criteria:  We discovered all the important requirements  We discovered all the relevant domain properties Ü Example:  Requirement R:  “Reverse thrust shall only be enabled when the aircraft is moving on the runway”  Domain Properties D:  Wheel pulses on if and only if wheels turning  Wheels turning if and only if moving on runway  Specification S:  Reverse thrust enabled if and only if wheel pulses on  Verification: S, D R Ü S + D entail R  But what if the domain assumptions are wrong?

9. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9 Another Example Ü Requirement R:  “The database shall only be accessible by authorized personnel” Ü Domain Properties D:  Authorized personnel have passwords  Passwords are never shared with non-authorized personnel Ü Specification S:  Access to the database shall only be granted after the user types an authorized password Ü S + D entail R  But what if the domain assumptions are wrong?

10. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10 But we can also move the boundaries… Ü E.g. Elevator control system: people waiting people in the elevator people wanting to go to a particular floor Elevator motors Elevator call buttons Floor request buttons Current floor indicators Scheduling algorithm Safety rules Motor on/off Door open/close Control program button lights We can shift things around: E.g. Add some sensors to detect when people are waiting This changes the nature of the problem to be solved

11. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 11 Example Problem Frames Ü Required behaviour  Problem: build a machine to control part of the world in accordance with a fixed set of control rules  Likely Solution: an automated control system Ü Commanded Behaviour  Problem: build a machine that allows part of the world to be controlled by an operator by issuing commands  Likely Solution: a “human-in- the-loop” control system. Ü Information Display  Problem: provide information about the current state of part of the world, in response to information requests  Likely Solution: an information system. Controller Desired Behavior Controlled Domain Controller Desired Behavior Controlled Domain User Information Requests Real World Information system Information function Information Outputs

12. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 12 More problem frames Ü Simple workpieces frame  Problem: keep track of the edits performed on some workpiece, e.g a text file or a graphical object  Likely Solution: application software (e.g. a word processor) Ü Transformation frame  Problem: take input data in a certain format, and provide a transformation according to a certain set of rules  Example Solutions: data processing applications; compilers, etc. Ü Connection frame  Problem: maintain a correspondence between domains that are otherwise not connected  Example Solutions: data entry system, sensor network, etc. machine Operation properties workpiece Operation Requests machine Mapping Rules Output Data Input Data SystemReal World Connection Achievable correspondence SC CR

13. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 13 Project Types Ü Reasons for initiating a software development project  Problem-driven: competition, crisis,…  Change-driven: new needs, growth, change in business or environment,…  Opportunity-driven: exploit a new technology,…  Legacy-driven: part of a previous plan, unfinished work, … Ü Relationship with Customer(s):  Customer-specific - one customer with specific problem  May be another company, with contractual arrangement  May be a division within the same company  Market-based - system to be sold to a general market  In some cases the product must generate customers  Marketing team may act as substitute customer  Community-based - intended as a general benefit to some community  E.g. open source tools, tools for scientific research  funder  customer (if funder has no stake in the outcome)  Hybrid (a mix of the above)

14. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 14 Project Context Ü Existing System  There is nearly always an existing system  May just be a set of ad hoc workarounds for the problem  Studying it is important:  If we want to avoid the weaknesses of the old system…  …while preserving what the stakeholders like about it Ü Pre-Existing Components  Benefits:  Can dramatically reduce development cost  Easier to decompose the problem if some subproblems are already solved  Tension:  Solving the real problem vs. solving a known problem (with ready solution) Ü Product Families  Vertical families: e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions of a system  Horizontal families: similar systems used in related domains  Need to define a common architecture that supports anticipated variability

15. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 15 Is there a “Requirements Lifecycle” Specification Agreement Representation complete fair vague personal view common view informal semi-formalformal Source: Adapted from Pohl, CAISE 1993

16. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 16 Inquiry Cycle Prior Knowledge (e.g. customer feedback) Observe (what is wrong with the current system?) Model (describe/explain the observed problems) Design (invent a better system) Intervene (replace the old system) Note similarity with Process of scientific Investigation: Requirements models are theories about the world; Designs are tests of those theories Initial hypothesis Look for anomalies - what can’t the current theory explain? Create/refine a better theory Design experiments to test the new theory Carry out the experiments

17. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 17 Summary Ü Requirements Engineering is about describing problems  It is useful to separate the problem from the solution  Even though this cannot be achieved entirely  Problems evolve continuously:  Delivering a solution changes the problem  Describing the problem changes the problem Ü Key distinctions:  Application Domains vs. Machine Domains  Verification vs. Validation  Systems Engineering vs. Software Engineering Ü Basic Problem Frames  Give us a starting point for understanding the problem  Tell us what subdomains we need to describe

18. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 18 Summary Ü Project Lifecycles  Useful for comparing projects in general terms  Represent different philosophies in software development  Requirements evolve through their own lifecycles too!