R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley...

9
R Requirements Analysis Part I Copyright © 2001 Patrick McDermott University of California Berkeley Extension [email protected] The most critical phase for Systems Analysis!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?