1. R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase for Systems Analysis!

2. A Requirement is… A Specific Thing your System has to do to Work Correctly. –Specific: A single thing you can test –System: The complete app or project –Correctly: “The customer decides when a system works correctly. So if you leave out a requirement or even if they forget to mention something to you, the system isn’t working correctly.” “A requirement is a singular need detailing what a particular produce or service should be or do.” —H1OOAD, p. 62.

3. Domain Analysis “The process of identifying, collecting, organizing, and representing the relevant information of a domain, based upon the study of existing systems and their development histories, knowledge captured from domain exerts, underlying theory, and emerging technology within a domain.” —H1 st OOA&D McLaughlin, Brett D., Gary Pollice & David West, Head First Object-Oriented Analysis & Design, Sebastopol, California: O’Reilly (0-596-00867-8 978-0-596-00867-3), 2007.

4. Robert L. Glass  Fact 23. One of the two most common causes of runaway projects is unstable requirements. (The other is poor estimation)  Fact 24. Requirements errors are the most expensive to fix during production.  Fact 25. Missing requirements are the hardest requirements errors to correct.  Fact 26. Explicit requirements “explode” as implicit (design) requirements for a solution evolve. Glass, Robert L., Facts and Fallacies of Software Engineering, Boston: Addison-Wesley (0-321-11742-5), 2003.

5. Analyze Analyze—Find the details of the situation Synthesize—Put together for understanding, communication and improvement Investigate Data Models Use Cases Other Models Béla Uitz Analysis on a Violet Background 1922

6. Focus on Requirements Listen to the Customer : “ When it comes to requirements, the best thing you can do is let the customer talk. And pay attention to what the system needs to do; you can figure out how the system will do those things later.” —H1OOAD Don’t worry about your code at this stage—just make sure you know what the system should do.

7. Communicate Question Listen Negotiate Present Sell Gause, Donald C. & Gerald M. Weinberg, Exploring Requirements: Quality Before Design, New York: Dorset House (0-932633-13-7), 1989. TALK LISTEN!

8. You Must Ensure All relevant rules within the Scope are –Discovered –Defined –Verified The Participants (“users”, “SMEs”, “clients”, …) agree that these are the Rules The Rules are documented in such a way that –they are unambiguous –participants can verify them They are useful to both audiences –IT - analysts, designers, programmers … –Business - sponsor, management, subject experts, …

9. Business Rules A Purchase Order can specify several Items A Purchase Order must specify at least one delivery location Mailing addresses must include a zip code The format of a zip code is nnnnn-nnnn An approved vendor must be reviewed every three years Late fees are calculated by adding 1% Exercise: What are the Business Rules for Enrolling in this class?