The Role of the Current Situation

This trawling activity is best done when you need to understand a medium to large work area for which no documentation exists. Moreover, the individual users currently doing the work struggle to give you an idea of how it all fits together.

We have mentioned several timesand probably will several times more the need to understand the work. This is best done not by being a passive onlooker, but by being actively involved in modeling the work.

You can use models to help you understand the work but, paradoxically, you can't build a model without understanding the work. This paradox follows from the way the modeling activity leads you to ask all the right questions. Models are working models, so if your model is not working, you haven't asked enough questions to get enough right answers. By asking the questions prompted by the model, you discover more information and use your new knowledge to refine the model so it reflects your growing understanding of the work.

Your models also record the work and demonstrate, at least to yourself, your understanding of it. Because the model serves as a common language between you and your stakeholders, you can agree that you have the identical understanding of the work.

Robertson, James, and Suzanne Robertson. Complete Systems Analysis: The Workbook, the Textbook, the Answers. Dorset House, 1998. This book demonstrates how to build models of current, future, and imaginary work.

When you model the current work, keep in mind that you are not attempting to specify a new product, but merely establishing the work that the users currently do. Most likely the users describe their work in a way that includes the mechanisms and technology they use to get the work done. These mechanisms are not requirements for the new systemyou must look beyond them to see the underlying policy of the users' system. We call this inner meaning the essence, and discuss it a little later in this chapter.

Despite any bad reputation the current work may have, it is still useful: It contains functionality that is making a positive contribution to the business. Naturally, much of this functionality must be included in any future system. You may implement it differently with new technology, but its underlying business policy will remain almost unchanged. The objective of building a model of the current work is to identify which parts you should keep and to understand the work you are about to change.

The current work contains many functions that contribute to the business. Naturally, these functions must be included in any future work.

Keep in mind that modeling the current system should be done as quickly as possible. Figure 5.3 shows a model of an existing system, built by the authors in conjunction with staff at City University, London.

Figure 5.3.

City University researchers' process for interrogating commercial databases. This model was built by the authors working with the user of the process. As the user described the work, the authors modeled and demonstrated their understanding. The model took about 15 minutes to complete. This model uses conventional data flow notation. Most process models would do the job equally well, so use whichever model you are most familiar with.

Restrict the amount of detail you include in your models of the current system. There is little point in modeling every tiny facet of something you are about to replace. The ideal model contains enough detail to give you an understanding of the work, and no more. The detail shown in Figure 5.3 is about right. That is, it shows the major parts of the current situation. It allows the user to verify that it is a correct representation of the work that he does, and it gives the requirements analyst places to make further inquiries.

One aspect of the model that should not be restricted is the area of the work covered by the model. Here it is almostand we stress "almost"a case of "the more, the merrier." Your models should cover all the work that could possibly be relevant to your product, those parts of the business that could contribute to the new product, and those parts where operational problems have popped up in the past. The other areas worth covering are those where the business is not well understood.

The point of having a large scope for models of the current work is that requirements analysis is really work reengineering. You specify products to improve work; the more of the work you study, the more opportunities to improve things emerge. The greater the scope of your study, the better your understanding and the better your chance of finding areas that will benefit from improvement.

The current model is also used to confirm the work scope. During the project blastoff, you and the stakeholders built a context model to show the scope of the work you intended to study. Any models you build while looking at the current situation should confirm that all of the appropriate parts of the work are included in the context, as shown in Figure 5.4. If at this stage you discover areas that would benefit from your attention, parts of the work that need to be understood, or anything at all that should be included, then now is the time to adjust the context. Such a revision does entail getting the agreement of the stakeholders, but it is better to enlarge the scope now than to end up with a product that lacks important functionality.

Figure 5.4.

The first-level breakdown shows the processes contained with the context. It is used to confirm the context and to partition the scope into areas of study.

One benefit that is generated by building current system models is that you find out where to ask questions (Figure 5.5). As the model develops, it becomes increasingly more obvious what you don't know, how much you don't know, and (sometimes) what the business people don't know. The model points out those areas where understanding is lacking. If your model appears to be dysfunctional, your information about the functions and data is probably incorrect; the model guides you toward where to concentrate your questions.

Figure 5.5.

Knowing where to ask questions, and which questions to ask, is almost as useful as knowing the answers. If your model has flows going nowhere, processes without inputs, read-only or write-only data stores, or other breaches of the modeling conventions, then you need to ask your stakeholders more questions about those aspects of the work.

It is, of course, impossible to change something without knowing what that "something" is. A study of the current work shows you how to fit something new into, or change, whatever currently exists. The models of the current system ensure that you understand the situation before introducing any improvements to it.