R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley...
-
Upload
berniece-french -
Category
Documents
-
view
215 -
download
0
Transcript of R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley...
![Page 1: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/1.jpg)
R
Requirements AnalysisPart I
Copyright © 2001 Patrick McDermott
University of CaliforniaBerkeley [email protected]
The most critical phase for Systems Analysis!
![Page 2: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/2.jpg)
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.
![Page 3: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/3.jpg)
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.”—H1st 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.
![Page 4: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/4.jpg)
Robert L. GlassFact 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.
![Page 5: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/5.jpg)
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 UitzAnalysis on a Violet Background
1922
![Page 6: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/6.jpg)
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.
![Page 7: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/7.jpg)
CommunicateQuestionListenNegotiatePresentSell
Gause, Donald C. & Gerald M. Weinberg, Exploring Requirements: Quality Before Design, New York: Dorset House (0-932633-13-7), 1989.
TALKLISTEN!
![Page 8: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/8.jpg)
You Must EnsureAll 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, …
![Page 9: R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com The most critical phase.](https://reader036.fdocuments.net/reader036/viewer/2022082613/56649ebc5503460f94bc53ef/html5/thumbnails/9.jpg)
Business RulesA Purchase Order can specify several ItemsA Purchase Order must specify at least one
delivery locationMailing addresses must include a zip codeThe format of a zip code is nnnnn-nnnnAn approved vendor must be reviewed
every three yearsLate fees are calculated by adding 1%• Exercise: What are the Business Rules for
Enrolling in this class?