Modeling the Business Process


Successful projects involve close collaboration between the development organization and the contractor. One of the first activities in this collaboration is for the contractor to thoroughly understand the business process.

You're the Expert

I once asked the manager of an outsourcing organization about his user requirements. He said, "You're the expert. You tell us how the software should work." I replied, "Well, yes and no. It's true we're very knowledgeable about software development and associated technologies. However, you're the expert on your business. In fact, no one knows more about your business than you and the people in your organization. We need your help so that we can become as knowledgeable as you."


To ensure a proper set of requirements, the development organization should learn everything it can about the outsourcing organization's business. There is more to this than simply reading piles of documents. There is no substitute for spending lots of face time with your customers. Learn everything you can about how they conduct their business. Take tours of the facilities where they conduct their business, if possible. Meet everyone you can who is involved with the business process the software will affect. Obtain their contact information and store along with it their titles, to whom they report, and who reports to them, and indicate what aspects of the business process they are involved with. As the requirements elicitation process takes place, you will have lots of questions, and this list of contacts will prove invaluable.

Definition of Business Modeling

Business modeling is the process of discovering and documenting the processes an organization uses to achieve a certain goal or objective. The key is to do this completely from the business perspective, without regard for the fact that you may be automating some or all of this process with a software system. The business could even use the artifacts produced by this process to train new employees. In this activity, the stakeholders do all the talking. Your role as contractor is to initiate the discussion. It is important to stress to the users not to get ahead of themselves by thinking of the system to be built. The emphasis at this point is only on the business processes. In other words, the participants need to talk about their jobs as they relate to the areas that will eventually be implemented by the system to be built. Activity diagrams are very useful for documenting these processes. For each business process diagram produced, you may find that you need several sessions with the stakeholders, initially identifying and documenting the business flow and conducting meetings to review the artifacts produced to validate that you have correctly captured the information.

A strong understanding of the business process is essential to producing software that the stakeholders will find useful. However, in some scenarios business modeling is not needed. The following examples illustrate how to recognize projects that are candidates for business modeling and projects that may not need it.

Indicators That a System Will Benefit from Business Modeling

Situations that would benefit from business modeling include the following:

  • Any system that involves processing or tracking some sort of the business entity. Examples include company sales, contacts, assets, and information.

  • Any system that tracks information or assets that involve levels of approval or concurrence in the organization.

  • Any system involving workflow management.

  • Any system that has significant interaction with users where the users have multiple roles.

  • Any project involving migration of legacy systems to new software architecture frameworks. The associated business processes may benefit from Business Process Reengineering (BPR), depending on the users' needs.

Examples of Systems That May Not Need Business Modeling

Situations that may not benefit from business modeling include the following:

  • Systems that have little or no user interaction (integration software, embedded systems, hardware controllers, and so on).

  • Adapting existing systems to work with new hardware, operating systems, and so on.

  • Modifying an existing system to accommodate a new feature.

Use Cases: A Best Practice for Capturing Business Processes and Functional Requirements

For each major business process that is identified, typically an actor initiates some transaction, followed by various flows illustrating who performs an activity and when. This is what activity diagrams illustrate. It is important to remember that these actors are roles defined in the business and are not necessarily tied to an individual. It is not unusual for a single individual to have multiple roles and therefore to be represented as multiple actors. This can be misleading for the stake-holders and should be clarified in the beginning. The collection of actors, the flows, and the sequence of events can be written as a business use case. The business use case is written completely from the perspective of the business, without regard for any implementation concerns. Business use cases are a high-level representation of the business activities identified for the new system. If any misunderstandings, disagreements, or concerns occur among the stakeholders on the business use cases, it is important to discuss and resolve these before the subsequent system use cases are identified.

When a strong understanding of the business processes, actors, flows, and so on is established, the focus can start turning toward identifying the system use cases. The system use cases represent a shift in perspective from business use cases. Whereas business use cases focus only on business processes, system use cases identify how an actor interacts with a system that implements the business processes. Instead of going into detail on the art of writing business and system use cases and how to transition between them, I'll refer you to several of the references in the bibliography. I will focus on the role and importance of use cases when working on outsourced projects. Use cases are such an important and useful tool that it is imperative that you understand and use them.

Transitioning to System Use Cases

After the stakeholders have documented, reviewed, and approved the business process, the task of identifying and writing the system use cases begins. While the business modeling activities are completely from the perspective of the business itself (without regard for the fact that you may be automating all or part of the business process with a software system), the system use cases describe how the end users will interact with the system to be built. The developers use these to develop the system; therefore, it is important that care be taken to describe all-important interactions with the system fully and completely.

The system use cases are perhaps the most important artifact produced in the RUP. The reason is that so much depends on the system use cases being correctly and completely defined. The following is a list of work products and activities that depend on the system use cases:

  • Class diagrams, state diagrams, sequence/collaboration diagrams

  • System architecture (for the architecturally significant use cases)

  • All code produced based on the diagrams

  • Test cases and associated test scripts, test requirements, and so on

  • User documentation

  • User training materials

  • Iteration plans and schedules

  • Project tracking

  • Project estimation and planning (some estimation tools utilize use cases and scenarios/flows to estimate project resources needed)

If the use cases are incomplete, or wrong, there is a good chance that these work artifacts and activities are wrong as well. On the other hand, if a team has done a good job of identifying and detailing the system use cases, and they have been validated and verified by the stakeholders, confidence in the ability to execute the project to successful completion increases.

Note that the notion of what constitutes complete varies from project to project and from one situation to another. For example, on one government project in which users were very concerned about security, we had a system use case to describe how the user logs into the system. For this customer, we described many alternative flows, including flows for aging and changing passwords. If the password were changed, we verified that the new password conformed to a series of rules regarding password length, composition, and whether the same password had been used before. On the other hand, a similar use case for a client with little interest in security would not be nearly as detailed. The key is to ask your customer what is important to them. Most customers are happy to discuss this.

I am a big fan of using rapid user interface development tools to help define and validate use cases. Technically, use cases should not contain any implementation-specific constructs. In other words, when specifying a user's interaction with a system, the use case should not refer to how the user interface is designed. In most cases, the user expects, and the contractor plans, to employ the use of graphical user interface (GUI) screens to implement a system. If this is known and expected, there is no reason not to use them in use cases to the best advantage.

Something to Show the Users Besides Use Cases

Several years ago, I worked with a client during a large business process modeling effort. Most of the stakeholders attending were attorneys who knew very little about software development (nor did they care to learn!). At the beginning of the time spent with them, I introduced them to the notion of activity diagrams. This was a painful effort, but most of them managed to learn how to read them and check them for accuracy against their business processes. In fact, some of the stakeholders began to appreciate the clarity it brought to modeling their business processes. With increasing confidence, we began to focus our attention on writing and developing the system use cases. To get the stakeholders comfortable with the process, we identified a couple of the initial use cases, wrote them in Word documents, and brought them to the next meeting for review.

Triumphantly, I said, "Look! These documents are written in English! There are no special diagrams or symbols to learn! These are even easier to review than the activity diagrams!" As we walked through the flows, only one user seemed to have any significant input. The others were quiet, only occasionally nodding. The next couple of meetings were equally uneventful. Finally, at the conclusion of one meeting, I asked one of the attendees why they were so quiet and had so little feedback. He said, "We're attorneys! All we do all day long is review documents. The last thing we want to do is come to more meetings to review more documents." I started to respond with the usual spiel about how important the use cases were, but I decided not to. It was clear that the group would not be excited about reviewing use case documents, no matter how well they were written.

Back at my office, I raised the issue in a team meeting. In the same meeting, an analyst communicated the status of a user interface prototype she was working on. In only a couple days' time, she had created a complete prototype of several screens that encompassed the use cases we were developing. "Great," I said. "We'll have something to show the users besides the use cases."

At the next meeting, we proceeded to show the users the screens. One of the users asked how the screens related to the use cases. We projected the prototype screen on the wall and began to walk them through the flows in the use case while illustrating how it would be done on the user interface prototype. The reaction amazed me. The entire group came alive with questions, comments, and useful feedback. From that point on, all the use case review meetings included an accompanying user interface prototype.


This example illustrates the usefulness of user interface prototypes. (It also illustrates how a review of software releases produced by an iterative development process can be.) If you decide to supplement use cases with user interface prototypes, you should keep in mind some important points:

  • Stakeholders with little experience in software development will not understand that the user interface prototype is nothing more than a facade. The "real" work remains to be done even though the user interface looks complete. Figure 9-1 shows a humorous example illustrating this point.

    Figure 9-1. A user interface prototype

    By permission of Leigh Rubin and Creators Syndicate, Inc.

  • It is important to emphasize the kind of feedback that is useful. Although you are happy to take comments regarding screen color, placement of buttons, and so on, these issues are not your primary focus. What you actually want to hear about are issues such as the following:

    • Have all required data items been accounted for on the user interface?

    • Is any data missing?

    • When a function is invoked on the user interface, are any prerequisite actions required first?

    • Have business rules regarding security, roles, and so on been accounted for in the flows of the corresponding use case?

    • Is any functionality missing?

    • Can you envision using a tool with this user interface to accomplish your job function? Why or why not?

I generally like to walk through the user interface prototype by reading the various use case flows. Of course, the functionality behind the user interface buttons is not operational, but it is enough to give the stakeholders an idea of what the system will be like.

There is one caveat to using user interface prototypes. When the project you are working on involves replacing a legacy system, particularly one that has been in service for many years, it is difficult for the users to "forget" about their current system while helping design the new one. If the user interface of the legacy system is well-liked by most of the stakeholders, it may not be necessary to utilize user interface prototyping. On the other hand, if you are creating an entirely new user interface, exercise care when introducing it to the end users. Although the users may dislike the legacy system's user interface, they will tend to reject an entirely new user interface, simply because it is unfamiliar to them.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

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