Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements Analysis Part II Copyright © 2001 Patrick McDermott University of California Berkeley Extension

Similar presentations


Presentation on theme: "Requirements Analysis Part II Copyright © 2001 Patrick McDermott University of California Berkeley Extension"— Presentation transcript:

1 Requirements Analysis Part II Copyright © 2001 Patrick McDermott University of California Berkeley Extension pmcdermott@msn.com

2 Functions of the Analyst Help the users identify what is needed to support their business processes Describe this functionality so the technical staff can build a system to supply it Translate between business and technicians Suzuki Kiitsu (1796-1858) Marching Cranes ca. 1830

3 Problems The existing rules are hidden and tangled There are more rules than anyone realizes Participants usually operate under similar but different rules –Multiple participants, multiple points of view –Multiple vocabularies and conceptual frameworks Many rules are “unconscious” –Informal –Ad hoc Many necessary rules simply don’t exist –No one knows everything

4 No Pain, No Gain The Acceptability, Usefulness and Integrity of a system is directly proportional to how well business is understood The process should be as easy as possible But not necessarily easy or painless –I never Promised you a Rose Garden –No pain, no gain –Change ain’t easy

5 Change to Requirements Check your requirements against your Use Cases (Or other list) A Change to the Use Cases implies a change to the Requirements –and vice versa

6 The Analyst’s Perspective But, of course, everyone thinks it’s all perfectly clear You’re not just analyzing what exists; you’re helping define what will be Some like doing analysis, some hate it The All-Seeing I –Working outside your area of expertise - you don’t know when you don’t know –At some point, you should know more than any one person

7 You need to Understand “ You’ve figured out one of the hardest parts about getting a customer’s requirements— sometimes even the customer doesn’t know what they really want! So you’ve got to ask the customer questions to figure out what they want before you can determine exactly what the system should do. Then, you can begin to think beyond what your customers asked for and anticipate their needs, even before they realize they have a problem.” —H1OOAD

8 What and How Separate the “what” from the “how’, “who” and “when” ….and “why” Understanding business activities and information so that information systems will support these activities

9 WIACY “Why isn’t Anyone Coding yet?” “Hey, we all know how this ought to work. Let’s get on with it!” Discuss: “The Analysis is Over when the Time Runs Out”


Download ppt "Requirements Analysis Part II Copyright © 2001 Patrick McDermott University of California Berkeley Extension"

Similar presentations


Ads by Google