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 37 Business process Most systems are built in order to do something: place orders, issue payments, launch rockets, run a heart/lung machine, and so on. To use a system, you need to know how to interact with it and why. Business processes describe your relationship with the system in terms of interactions. You enter a shipment. The system validates the data about the shipment and gives you a set of error messages. You fix the data about the shipment and try again. The system validates the data again. Seeing that the data is valid, the system uses it to save the shipment to the database and update the associated orders. A common challenge with gathering business processes is that it is difficult to distinguish personal preference or legacy practice from actual current need. So how do you avoid this trap One technique is to look past the process to the reason for the process. Each process had a justification at some point, even if that justification no longer exists. You need to know the reason behind the process. For example, What result does logging the shipment produce What would happen to the rest of the system if you didn’t have a record of the shipment Would another process fail (for example, would you be able to accurately maintain the inventory and Accounts Receivable if you didn’t know what was shipped) Next, evaluate each process, both on its own and in its role in the system. Identify those processes that no longer produce valuable outcomes. Keep only those that are essential to the successful operation of the system. For example, evaluate the following interactions of the Inventory Control processes for Receiving, Stocking, and Accounts Payable: The stock is offloaded from the trucks and placed into a staging area. Why Historically the same people offloaded the trucks and placed the products into inventory. They couldn’t do both at the same time. When the product is in the right location, the stocking personnel inform the supervisor, who delivers the documents to the Accounts Payable department. Why do they wait to notify AP Historically this was a manual process so the stock clerks waited until they had all of their other work done. Then come back and evaluate those processes that, even though they aren’t essential, may add value. Prioritize these contributions and allocate resources proportional to their value to the system and add them to the project plan. For example, The incoming shipment documents are delivered to the supervisor for verification. Why After a few interviews, you find out that this practice was instituted because in years past the warehouse had serious theft problems. Is there still a problem that would justify the added cost and delays The goal in this evaluation process is to make conscious choices about how to spend the finite time and money available to the project to deliver the best possible system. The lesson: Focus on results rather than processes; quantify the value of the results; allocate resources proportional to the value of the results.
38 Friday Evening Constraints The second type of requirement is called a constraint. Constraints are limitations on or boundaries around what you can do when you develop a solution for the system. Constraints can apply to virtually any aspect of your project and the resulting system. Why do you care about constraints Because constraints limit the options you have at virtually every phase of the development life cycle. Consider the constraints on each of these four development phases: Requirements gathering: Limitations on client skills and experience drive the type of solutions that you can offer. The application may need to offer substantially more help features for less-skilled users, whereas extremely skilled or experienced users might reject the same features as a hindrance. Analysis: Limitations imposed by policies and procedures, laws, contracts, and industry standards restrict the models that you develop to document the problem domain. You may not be able to be as creative as you’d like when the law or a contract says that it has to be done a particular way. For example, the inventory system must abide by generally accepted accounting principles. Failure to do so risks an audit, fines, or worse. Design: Programming languages, databases, middleware, and just about every technology impose specific limitations. These technologies often dictate field data types and sizes, data conversions, communication protocols, and more. This limits the options available to you to when you try to satisfy the system requirements. You might want to network the warehouse to the accounting office a few blocks away only to find the phone lines are over 30 years old and are currently tied up in a massive upgrade project that is running badly behind schedule. Implementation: Implementation technologies impose performance limitations that often conflict directly with the performance requirements for the business. This is, in fact, the motivation behind so much technological advancement (that is, removing these bottlenecks so that technological constraints don’t sabotage business constraints). The warehouse may want to transition to radio frequency data entry, but the substation next door causes too much interference; the technology may be ideal, but to overcome the interference problem would cost twice what has been budgeted for the whole project. Rules Constraints are like mandates: It must be done this way! Rules are more like agreements: We’ve talked about it and agreed that the invoice needs to include these items and have these approvals. Rules need to be enforced, but if you find a better way to do it you can always talk about it again and choose to change it. In the meantime, you agree to implement and follow the decision consistently. Rules can be anything from the look of a form or screen, to a business process with checks and approvals, number of copies, and waiting periods. Constraining policies are typically upper-management decisions or directives from the business environment (legislation, regulations, and so on) and tend to be separate from the processes that implement them. In the case study, the inventory control system requires you to complete the receiving documentation with the prescribed details about the shipper, products, shipping company,
- Page 11 and 12: x Preface To get the most out of th
- 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: 36 Friday Evening Remember to pay c
- Page 63 and 64: 40 Friday Evening An Inventory Cont
- Page 65 and 66: 42 Friday Evening Performance How
- 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
Session 4—Defining Requirements for the Case Study 37<br />
Business process<br />
Most systems are built in order to do something: place orders, issue payments, launch rockets,<br />
run a heart/lung machine, and so on. <strong>To</strong> use a system, you need to know how to interact<br />
with it and why. Business processes describe your relationship with the system in terms<br />
of interactions. You enter a shipment. The system validates the data about the shipment<br />
and gives you a set of error messages. You fix the data about the shipment and try again.<br />
The system validates the data again. Seeing that the data is valid, the system uses it to save<br />
the shipment to the database and update the associated orders.<br />
A common challenge with gathering business processes is that it is difficult to distinguish<br />
personal preference or legacy practice from actual current need. So how do you avoid<br />
this trap One technique is to look past the process to the reason for the process. Each<br />
process had a justification at some point, even if that justification no longer exists. You<br />
need to know the reason behind the process. For example,<br />
What result does logging the shipment produce<br />
What would happen to the rest of the system if you didn’t have a record of the<br />
shipment<br />
Would another process fail (for example, would you be able to accurately maintain<br />
the inventory and Accounts Receivable if you didn’t know what was shipped)<br />
Next, evaluate each process, both on its own and in its role in the system. Identify those<br />
processes that no longer produce valuable outcomes. Keep only those that are essential to<br />
the successful operation of the system. For example, evaluate the following interactions of<br />
the Inventory Control processes for Receiving, Stocking, and Accounts Payable:<br />
The stock is offloaded from the trucks and placed into a staging area. Why<br />
Historically the same people offloaded the trucks and placed the products into<br />
inventory. They couldn’t do both at the same time.<br />
When the product is in the right location, the stocking personnel inform the supervisor,<br />
who delivers the documents to the Accounts Payable department. Why do they<br />
wait to notify AP Historically this was a manual process so the stock clerks waited<br />
until they had all of their other work done.<br />
Then come back and evaluate those processes that, even though they aren’t essential,<br />
may add value. Prioritize these contributions and allocate resources proportional to their<br />
value to the system and add them to the project plan. For example,<br />
The incoming shipment documents are delivered to the supervisor for verification.<br />
Why After a few interviews, you find out that this practice was instituted because<br />
in years past the warehouse had serious theft problems. Is there still a problem that<br />
would justify the added cost and delays<br />
The goal in this evaluation process is to make conscious choices about how to spend the<br />
finite time and money available to the project to deliver the best possible system. The<br />
lesson: Focus on results rather than processes; quantify the value of the results; allocate<br />
resources proportional to the value of the results.