UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 4—Defining Requirements for the Case Study 41 Business process requirements What are your job responsibilities Do many people share the same set of responsibilities If their jobs are different, then explain how and why. What does this system provide that ensures the success of your job or task Is it information Is it approval Is it a specific output, like a report or form What happens if you can’t get the information Constraints Are there any regulations, contracts, or laws that dictate how you do your job What authority, if any, do you need to access the features you use Rules What policies and procedures determine how you have to do your job Performance How many people will need to use the system How many will use it concurrently How slow can the system be before it interferes with your job Resources What do I mean by a resource when talking about software systems Information. Data. Typically, the sole purpose of a software system is to accumulate, manipulate, create, store, destroy, and retrieve information. So how do you find these resources One simple and very effective method is to examine the vocabulary of the users. Building a dictionary of the domain vocabulary is a good place to start. The terminology usually requires a bit of cleanup, but that too can be a healthy experience as you discuss the vocabulary with the users. Working from the vocabulary focuses your interview questions and makes better use of the client’s time. In my experience, it also improves your relationship with the users when you seek to understand their world through their own words. Business process requirements What resources do you acquire or dispose of What resources/information do you rely on to do your job What information are you responsible for (that is, what resources do you approve or requisition) Constraints What restrictions influence the acquisition, use, and disposal of each resource Are there any legal or government regulations that dictate your use of this resource Rules What authority level is required to approve the acquisition, use, and disposal of each resource (that is, how do you determine who is and is not allowed to use it) What policies govern the use of this resource within the company
42 Friday Evening Performance How much time is allowed for each transaction involving this resource Does the volume of resources affect your ability to process them effectively Functionality Functionality simply means what you expect the system to do. The cleanest way I know to find out is to go back to the questions you asked the users. If you can find out what their jobs are, specifically what tasks they must perform, then you can identify the specific objectives that the system must support. Focusing on objectives is critical. Avoid getting caught up in how they achieve those objectives. Talking with users about their work without talking about how they do it is almost impossible. Most people operate on the level of process, how they do their job. That’s okay as long as you always remember to ask, “Why” These questions keep you focused on the purpose of the function and away from processes that could be used to implement the function. This is a critical distinction when you get to Use Cases in Session 5. Business Process Requirements Why do you do that What do you expect to happen when you do that What happens when it doesn’t work Is there more than one possible outcome Do people with different jobs perform this same task Do they do it for the same reason Constraints What regulations or laws govern how you are allowed to perform the task Rules What guidelines or policies dictate the way you perform the task Does this task depend on other tasks Performance What factors influence or even determine how quickly you can complete the task How quickly does the task have to be performed Avoiding early pitfalls The UML gives us a reasonably precise language to communicate very effectively about challenging concepts. But the job of the analyst still boils down to good communication. So let’s take a look at a few of the common pitfalls that can sabotage good communication.
- Page 13 and 14: xii Preface Features First, as you
- Page 15 and 16: Part VI—Sunday Afternoon ........
- Page 17 and 18: xvi Contents Encapsulation ........
- Page 19 and 20: xviii Contents Modeling the Class C
- Page 21 and 22: xx Contents Session 22-Modeling the
- Page 24: UML Weekend Crash Course
- Page 27 and 28: PART I Friday Evening Session 1 Wha
- Page 29 and 30: 6 Friday Evening The UML is a stand
- Page 31 and 32: 8 Friday Evening will find three pa
- Page 33 and 34: 10 Friday Evening The Continuing Re
- Page 36 and 37: SESSION 2 UML and Development Metho
- Page 38 and 39: Session 2—UML and Development Met
- Page 40 and 41: Session 2—UML and Development Met
- Page 42 and 43: Session 2—UML and Development Met
- Page 44 and 45: Session 2—UML and Development Met
- Page 46 and 47: SESSION 3 How to Approach the UML S
- Page 48 and 49: Session 3—How to Approach the UML
- Page 50 and 51: Session 3—How to Approach the UML
- Page 52 and 53: Session 3—How to Approach the UML
- Page 54 and 55: Session 3—How to Approach the UML
- Page 56: Session 3—How to Approach the UML
- Page 59 and 60: 36 Friday Evening Remember to pay c
- Page 61 and 62: 38 Friday Evening Constraints The s
- Page 63: 40 Friday Evening An Inventory Cont
- Page 67 and 68: 44 Friday Evening In the effort to
- Page 70 and 71: Part II — Saturday Morning Sessio
- Page 72 and 73: SESSION 5 Understanding the Use Cas
- Page 74 and 75: Session 5—Understanding the Use C
- Page 76 and 77: Session 5—Understanding the Use C
- Page 78 and 79: Session 5—Understanding the Use C
- Page 80 and 81: Session 5—Understanding the Use C
- Page 82: Session 5—Understanding the Use C
- Page 85 and 86: 62 Saturday Morning Order Fulfillme
- Page 87 and 88: 64 Saturday Morning What does the
- Page 89 and 90: 66 Saturday Morning For example, th
- Page 91 and 92: 68 Saturday Morning REVIEW The goal
- Page 93 and 94: 70 Saturday Morning Much of this la
- Page 95 and 96: 72 Saturday Morning You reply that
- Page 97 and 98: 74 Saturday Morning Writing a Use C
- Page 99 and 100: 76 Saturday Morning Use Case dialog
- Page 101 and 102: 78 Saturday Morning Table 7-7 The F
- Page 104 and 105: SESSION 8 Identifying the Use Case
- Page 106 and 107: Session 8—Identifying the Use Cas
- Page 108 and 109: Session 8—Identifying the Use Cas
- Page 110 and 111: Session 8—Identifying the Use Cas
- Page 112 and 113: Session 8—Identifying the Use Cas
42<br />
Friday Evening<br />
Performance<br />
How much time is allowed for each transaction involving this resource Does the<br />
volume of resources affect your ability to process them effectively<br />
Functionality<br />
Functionality simply means what you expect the system to do. The cleanest way I know to<br />
find out is to go back to the questions you asked the users. If you can find out what their<br />
jobs are, specifically what tasks they must perform, then you can identify the specific<br />
objectives that the system must support. Focusing on objectives is critical. Avoid getting<br />
caught up in how they achieve those objectives. Talking with users about their work without<br />
talking about how they do it is almost impossible. Most people operate on the level of<br />
process, how they do their job. That’s okay as long as you always remember to ask, “Why”<br />
These questions keep you focused on the purpose of the function and away from<br />
processes that could be used to implement the function. This is a critical distinction when<br />
you get to Use Cases in Session 5.<br />
Business Process Requirements<br />
Why do you do that What do you expect to happen when you do that<br />
What happens when it doesn’t work Is there more than one possible outcome<br />
Do people with different jobs perform this same task Do they do it for the same<br />
reason<br />
Constraints<br />
What regulations or laws govern how you are allowed to perform the task<br />
Rules<br />
What guidelines or policies dictate the way you perform the task<br />
Does this task depend on other tasks<br />
Performance<br />
What factors influence or even determine how quickly you can complete the task<br />
How quickly does the task have to be performed<br />
Avoiding early pitfalls<br />
The <strong>UML</strong> gives us a reasonably precise language to communicate very effectively about challenging<br />
concepts. But the job of the analyst still boils down to good communication. So let’s<br />
take a look at a few of the common pitfalls that can sabotage good communication.
Change language