Synchronize for Second Week

1. Synchronize for Second Week You have read: Chaos, Student Survival Guide Gause & Weinberg Ch. 1,2,3 Jackson on “Descriptions” and “Machines” Wiegers Ch. 1 Now go read: Gause & Weinberg Ch. 4, and Part II Wiegers Ch. 6, 7 Jackson on “Procrustes” “Rough Sketches” “Application domain” Prepare to meet with the client and develop a “Vision and Scope” document

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

3. Why do requirements? • 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. 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. 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 Desirable Characteristics of a Requirements Specification

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. 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. 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. 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. 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 Typical contents of a textual Req. Spec. (check the many templates available!)

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. Rapid Prototype Verify Design Verify Implementation Test Rapid Prototyping - See Schach, pg. 71 Req. Change Operations Retirement

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