Understanding the Work


The product you intend to build must improve your client's work. Your product will be installed in the client's area of work and will do part of (sometimes all of) that work. It does not matter what kind of work it is commercial, scientific, embedded real-time, manual, or currently automated you always have to understand it before you can decide what kind of product will best help with it. By "work," we do not mean just a computer system (either the current system or an anticipated one); instead, we mean the system for doing business. We include the human tasks, the computers, the machines, and the low-tech devices like telephones, photocopiers, manual files, and notebooksin fact, anything that is used to produce your client's goods, services, or information. Until you understand this work and its desired outcomes, you cannot know which product is the optimal one to build.

Figure 4.1 presents an overview of how we intend to proceed. You might wish to refer back to this figure as you read the text, as it will help smooth the way.

Figure 4.1.

The scope of the work is agreed to by all parties at the blastoff. It defines both the work area to be studied and the adjacent systems that surround it. The adjacent systems supply data to the work and/or receive data from it. Business events happen in the adjacent systemsusually the event is a demand for a service provided by the work. In addition, time-triggered business events occur when it is time for the work to provide some information to the adjacent system. The response the work makes to the business event is called a business use. It includes all of the processes and data needed to make the correct response. The requirements analysts study the functionality of the business use case with the help of the appropriate stakeholders. From this study, they determine the optimal product to build and construct a product use case scenario to show how the actor and the product will interact. Once agreement is reached on this product and scenario, the requirements analysts write the requirements for the product.


While it is necessary to understand the work, the scope of this work is likely too large to be digested in its entirety. If we attempt to treat the work as an indivisible whole, the requirements analysts and designers will fail to understand it, and the stakeholders will have little chance of explaining it to them. By finding smaller parts of the work, you have a better chance of finding stakeholders who are specialists in that part of the work and can give you a more comprehensive explanation of it. Thus the work must be partitioned into smaller pieces. For the purposes of requirements gathering, we are looking for pieces that meet the following criteria:

  • They are "natural" partitionseach one makes an obvious and logical contribution to the work.

  • They have minimal connectivity to other parts of the work.

  • They have a clearly defined scope.

  • They have rules for defining their scope.

  • They have boundaries that can be observed and defined.

  • They can be named using names that are recognizable to stakeholders.

  • Their existence can be readily determined.

  • They have one or more stakeholders who are experts for that part of the work.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net