1. Session 4 Defining Requirements for the Case Study Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 5, 2011 Presented by Kang-Pyo Lee

2. Contents  The Case Study Problem Statement –Receiving –Stocking –Order Fulfillment –Shipping  Types of Requirements  An Inventory Control System 2

3. The Case Study Problem Statement (1/2)  The case study is a scaled down inventory control system  Your goal is to gather enough information about the system to rewrite it by evaluating the problem statement –In order to start a project, there has to be a perceived problem to solve (or an opportunity to exploit). –The “problem” may be the lack of a system to do a critical function –The problem statement documents this perception 3

4. The Case Study Problem Statement (2/2)  The problem statement for your case study consists of the following four paragraphs 4 Receiving The receiving clerks receive incoming shipments by matching purchase orders against the products in the shipment. The incoming shipment documents are delivered to the supervisor for verification. The products may come from cancelled orders, returned orders, or received shipments. The products are offloaded from the trucks and placed into a staging area. Order Fulfillment Other staff members fill orders by locating the products required for the order. After they have filled the order, they drop the order at the clerk’s desk. The clerk updates inventory to reflect the fact that the product has been removed for an order. There can be a delay of up to two days, causing significant problems with the reordering process and stock levels. They also notify the Order Processing Department that the order has been filled. Stocking The stock clerk looks up the correct location for each product, places the product in that location, and updates the inventory with the location and quantity. When the product is in the right location, the stocking personnel inform the supervisor, who delivers the receiving documents to the Accounts Payable Department. Shipping When the orders are filled, they are then packed and prepared for shipping. The shipping folks contact the shippers to arrange delivery and give the paperwork to the clerk. The clerk also notifies the Order Processing Department when the order has shipped and updates inventory to reflect the fact that the products actually shipped.

5. Contents  The Case Study Problem Statement  Types of Requirements –Business Process –Constraints –Rules –Performance  An Inventory Control System 5

6. Types of Requirements (1/7) - Business Process  What types of requirements could you encounter in a business system? –Business process, constraints, rules, and performance  Business processes describe your relationship with the system in terms of interactions, e.g., –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 6

7. Types of Requirements (2/7) - Business Process 7  It is difficult to distinguish personal preference or legacy practice from actual current need  One technique is to look past the process to the reason for 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 (e.g., would you be able to accurately maintain the inventory and Accounts Receivable if you didn’t know what was shipped)?

8. Types of Requirements (3/7) - Business Process 8  Next, evaluate each process, both on its own and in its role in the system  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.

9. Types of Requirements (4/7) - Business Process 9  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 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 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?

10. Types of Requirements (5/7) - Constraints 10  Constraints are limitations on or boundaries around what you can do when you develop a solution for the system  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 Design Programming languages, databases, middleware, and just about every technology impose specific limitations Analysis Limitations imposed by policies and procedures, laws, contracts, and industry standards restrict the models that you develop to document the problem domain Implementation Implementation technologies impose performance limitations that often conflict directly with the performance requirements for the business

11. Types of Requirements (6/7) - Rules 11  Rules are more like agreements –Cf. constraints are like mandates  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  During the analysis phase, rules are a major focus of discussion –Refocus your attention onto why the client is doing the job that particular way  The UML diagrams provide places for you to capture these rules –The Use Case model to describe how the users plan to use the system for filling orders, stocking products, and so on –The Class and Object diagrams to model rules and constraints for the resources the system manipulates like shipments, products, and orders –The Activity diagram to model how the various processes are supposed to work –The Sequence, Collaboration, and Statechart diagrams to capture how objects behave when they are used in these processes

12. Types of Requirements (7/7) - Performance 12  Performance requirements define how well the system solution should perform when you use it  The challenge is that the means to achieve the required performance may require choices at any or all the project phases  Consider the impact on these design phases if the requirement is a specific response time threshold for all applications: Requirements Gathering The inventory control system users wanted to network the warehouse to the accounting office so that they can do inventory searches Design The database in use is two versions behind Analysis Users have defined product searches that bring the current system to its knees

13. Contents  The Case Study Problem Statement  Types of Requirements  An Inventory Control System –Identifying Requirements –Avoiding Early Pitfalls 13

14. An Inventory Control System (1/5) - Identifying Requirements  One approach to gathering requirements is to look for them by examining the problem statement and the supporting documents and interviews from different perspectives –Users  Users have expectations for the use of the system –Resources  Resources are represented as information that is created, used, and deleted by the system to support the system behavior –Functionality  Functionality refers to the behavior supported by the system 14

15. An Inventory Control System (2/5) - Identifying Requirements  Users –You need to know why and what they expect from their communication with the system 15 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? Rules - What policies and procedures determine how you have to do your job? 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? 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?

16. An Inventory Control System (3/5) - Identifying Requirements  Resources (i.e., information) –Examine the vocabulary of the users to find the resources –Building a dictionary of the domain vocabulary is a good place to start 16 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)? 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? 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? Performance How much time is allowed for each transaction involving this resource? Does the volume of resources affect your ability to process them effectively?

17. An Inventory Control System (4/5) - Identifying Requirements  Functionality –Functionality simply means what you expect the system to do –The cleanest way to find out is to go back to the questions you asked the users 17 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? Rules - What guidelines or policies dictate the way you perform the task? - Does this task depend on other tasks? Constraints What regulations or laws govern how you are allowed to perform the task? Performance - What factors influence or even determine how quickly you can complete the task? - How quickly does the task have to be performed?

18. An Inventory Control System (5/5) - Avoiding Early Pitfalls 18  Common pitfalls that can sabotage good communication –Pitfall #1: Making assumptions  Avoid making assumptions of any kind  Always challenge and confirm –Pitfall #2: Replicating existing implementations  Watch out for the possibility that you are simply replacing the old system with a duplicate in new attire (i.e., a new platform or technology) –Pitfall #3: Mistaking preferences for requirements  Be careful not to mistake user preferences for true requirements

19. The End