1. CSC 402 Requirements Engineering 1

2. 2 Problem Definition Requirements Definition informal statement of need for system natural language statement of what system is to provide Requirements Specification notational and/or formal description of a software system Requirements Analysis and Specification

3. CSC 402 Requirements Engineering 3 Requirements purposes review Develop a contract between customer and developer – Enables both sides to be clear about what is to be done Understand and specify requirements based on customer’s needs – Not on what the developer thinks the customer needs Provide basis for definitive testing and verification – System is acceptable if its passes the “acceptance” test

4. CSC 402 Requirements Engineering 4 Goals for a requirements specification Identify the functional capabilities of the system Identify desired responses to undesired events Identify non-functional and environmental constraints to be satisfied – “My users will submit input in the form of Microsoft Word documents” – “It has to run on a ‘386 under Win 3.1!” Avoid specifying “how” focus simply on “what” – but recall Michael Jackson’s thoughts about “machines” Serve as a guide to the development team

5. CSC 402 Requirements Engineering 5 Desirable Characteristics of a Requirements Specification Abstract – one model, many realizations Complete – to the extent required Consistent – no contradictions Unambiguous – concrete acceptance test Precise – uniquely interpretable Testable Concise – no extraneous details Feasible – realistic constraints Even – consistent level of detail Modifiable – living document Reference Tool – readable by all stakeholders No implementation bias

6. CSC 402 Requirements Engineering 6 Common Problems Incompleteness – customer may be unavailable or inaccessible – customer asks for too little – customer doesn’t think of everything – the world changes – (sometimes incompleteness is okay (as long as its noted!)) Inconsistency – customer may be a group that disagrees – different people may negotiate different parts Ambiguity – customer may be a group where noone sees the whole picture – difficult to spot ambiguity in large, complex applications

7. CSC 402 Requirements Engineering 7 Common Problems - 2 Imprecision – customer may be a group with a different vocabulary – precision easiest in mature application areas (e.g. accounting) – precision difficult in new disciplines Infeasibility – customer asks for too much ¤ no conceivable algorithm ¤ unrealistic requests Unevenness – different sources of information – different people write different parts – different parts of specification are more difficult than others

8. CSC 402 Requirements Engineering 8 Basic Techniques Customer teaches; developer learns and organizes – Developer applies discipline to process and helps discover ambiguity, inconsistency, and incompleteness Interviews, investigations, questionnaires Develop glossaries to aid communication Describe in a (semi-)formal notation Hierarchical decomposition System modeling – Dataflow diagrams, E-R Diagrams, Finite state machines, Petri nets, UML diagrams

9. CSC 402 Requirements Engineering 9 Informal Requirements Specification Typical method – useful first attempts during problem definition Structured Natural Language – Extended, more detailed form of requirements definition Advantage – Uses expressiveness and understandability of natural language Problems – Inherent ambiguity of natural language – Requirements are not partitioned effectively by the language itself (difficult to find related requirements)

10. CSC 402 Requirements Engineering 10 Typical contents of a textual Req. Spec. (check the many templates available!) Description – restatement of problem definition Functionality – “what” the system does Data – “what” the system processes Environment – “where” the system operates Robustness – “what“ is expected of the system when an error occurs Security – “who” has access to “what” Safety – Can this system harm anyone Performance – “what” constraints are placed on the system’s performance Resources – “what” information/other systems is/are available to help the system accomplish its job

11. CSC 402 Requirements Engineering 11 Rapid Prototyping A means to understand and acquire requirements Most often – a mockup of (some aspect of) a software product ¤ serves as a communication device with the user “I don’t know what I want, but I don’t want THAT!” ¤ facilitates technical exploration “Is this possible?” ¤ aids the development and assessment of specifications “I want that...”

12. CSC 402 Requirements Engineering 12 Rapid Prototyping - See Schach, pg. 71 Rapid Prototype Verify Retirement Operations Test Implementation Verify Design Req. Change

13. CSC 402 Requirements Engineering 13 Understanding user needs... A prototype can help understand user needs – Is the proposed service/system adequate? – Is the user-interface usable? – Are the requirements complete? – Which alternative should we take? ¤ e.g. present the user with multiple “throw-away” prototypes

14. CSC 402 Requirements Engineering 14 “Rapid” is key The prototype must be constructed quickly! – Thus, inconsequential problems are minor as long as main aspect of the prototype functions correctly A prototype should be designed to be rapidly changed – This supports iteration in the process ¤ If the user doesn’t like it, incorporate the feedback and try again! To support these requirements, fourth-generation languages or interpreted languages are often used to generate prototypes

15. CSC 402 Requirements Engineering 15 Rapid Prototypes as specifications... Instead of discarding the prototype, use it to serve as the specification – Saves time having to write a specification document! Generally considered a bad idea... – because ¤ a rapid prototype can’t serve as a legal contract ¤ a rapid prototype does not make for good documentation It can’t serve as a reference tool for maintenance, for example. Prototypes should be used to elicit requirements and then discarded, next comes design...

16. CSC 402 Requirements Engineering 16 Rapid Prototypes as the finished product! Also considered a bad idea... – Same problems as previous slide... – Plus ¤ Its too easy to slip into the build-and-fix lifecycle!

17. CSC 402 Requirements Engineering 17 Training the client... Customer and/or users may confuse a prototype with the operational system – “Why do we have to wait so long for the system, didn’t you have it working three months ago?” Customer may request more features than originally intended – “Hey that’s great! Can you add this...and this?” Thus...client should be informed as to the purpose of the prototype and be aware of the position of requirements in the life-cycle...