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.
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 ModelingBusiness 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 ModelingSituations that would benefit from business modeling include the following:
Examples of Systems That May Not Need Business ModelingSituations that may not benefit from business modeling include the following:
Use Cases: A Best Practice for Capturing Business Processes and Functional RequirementsFor 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 CasesAfter 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:
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.
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:
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. |