.NET Solution Architectures: Gathering and Analyzing User Requirements

Terms you'll need to understand:

• Unified Modeling Language (UML)

• Use cases

• Usage scenarios

• Globalization

• Localization

Techniques you'll need to master

• Creating use cases and use case diagrams

• Developing usage scenarios

• Gathering requirements needed to develop world-ready applications

The previous chapter covered methods for analyzing the current business state and identifying business requirements for the solution. There are many sources from which to collect information and ways to interpret this information. The next phase of the requirements process is to focus on gathering and analyzing users' specific requirements. In many ways, this phase can be one of the most challenging and frustrating aspects of developing a computer system (think of your "favorite" user). Because of time or resource constraints, you might need to start designing the system before you can adequately complete the requirements-gathering phase. You might encounter users who can't tell you what they want but still expect the perfect solution. The amount of information gathered during the requirements-gathering phase can, at times, be overwhelming or contradictory. To extend the lifespans of systems professionals and to address these issues, the development of systems applications evolved into the object-oriented approach.

Unified Modeling Language

To address the need for a commonly accepted method of object-oriented modeling, the Unified Modeling Language (UML) has been developed. The notations in UML are meant to be straightforward and consistent, and a minimal number of symbols are used. It was purposely designed to be readable on almost any medium, such as whiteboards, paper, or computer displays.

IN UML, nine types of diagrams are used to represent the various modeling viewpoints. Here, in alphabetical order, is a list of the various diagrams and a brief explanation of each:

• Activity diagrams—These diagrams represent the behavior of an operation as a "set of actions" document. Activity diagrams document the logic of a single operation or method, a single use case, or the flow of logic for a business.

• Class diagrams—These diagrams represent the static structure in terms of classes and relationships. The purpose of a class diagram is to depict classes within a model.

• Collaboration diagrams—These diagrams are a spatial representation of objects, links, and interactions. They are useful for visualizing how several objects collaborate to complete a task.

• Component diagrams—These diagrams describe software components and their relationships within the implementation environment.

• Deployment diagrams—These diagrams represent the deployment of components on particular pieces of hardware. Deployment diagrams model the hardware used in implementing a system and the association between those hardware components.

• Object diagrams—These diagrams represent objects and their relationships and correspond to simplified collaboration diagrams that do not represent message broadcasts.

• Sequence diagrams—These diagrams are temporal representations of objects and their interactions. Sequence diagrams contain the same information as collaboration diagrams but emphasize the sequence of the messages instead of the relationships of the objects.

• Statechart diagrams—These diagrams represent the behavior of a class in terms of states. Statechart diagrams emphasize the possible states of an object and the transitions between states.

• Use case diagrams—These diagrams represent the functions of a system from the user's point of view.

Although all UML diagrams are important in some aspect of the development life cycle, use case diagrams, because they are considered such an integral part of gathering user requirements, are the only UML diagram explored in detail in this chapter.

Use cases use actions and reactions to describe the behavior of a system from a user's standpoint. They show the definition of the system's boundaries and the relationships between the system and the environment.

Even with these modern methods available, the most basic task of gathering requirements, talking to the users, is still the major source of gathering requirements. So to create use cases, you still need to sit down with expected users of the system and do a thorough analysis of the functions they need from the new system. Each use case corresponds to a specific kind of system use. A use case is an image of a system's functionality, which is triggered in response to the stimulation of an external actor.

An actor represents the role played by a person or thing that interacts with a system. Actors are represented in use case diagrams by little stick people who trigger the use cases. (Additional certification for drawing stick people might be available soon.)

The name of the actor describes the role the user plays. To determine who the actors are, observe the direct users of a system, those who are responsible for its use or its maintenance, and other systems that interact with the one you're gathering requirements for. The same person can play the roles of several actors.

A good rule for determining what can be considered an actor is that they are usually the people and things outside a system, and they interact with the system by exchanging information. In this way, determining the actors also helps set the system's boundaries. There are four main categories of actors:

• Principal actors—These are the people who use the main system functions.

• Secondary actors—This category includes people who perform administration or maintenance tasks.

• External hardware—These are the hardware devices, such as printers or scanning equipment, that are part of the environment in which the application will reside and must be used. These devices are most likely not the computers running the application.

• Other systems—These are the other systems with which the system must interact.

In UML, a use case model is depicted in a diagram (see Figure 3.1). A use case diagram depicts the use cases and actors for a system. The use cases are represented as ellipses contained within the system. The two main pieces of information to determine when creating use cases are the actor's action and the expected result. (If there were any doubts, look at the diagram. I was serious about the stick people.)

Figure 3.1 A use case diagram.

Use cases are determined by observing and specifying, actor by actor, the interaction sequences (scenarios) from the user's standpoint. They are described in terms of the information exchanged and the way the system is used. A use case groups a family of usage scenarios according to a specific functional criterion. Use cases are abstractions of dialogue between the actors and the system: They describe potential interactions without going into the details of each scenario.

Use case diagrams represent use cases, actors, and relationships between use cases and actors. In UML, there are three types of links between actors and use cases:

• The communicates or association relationship—The actor's participation is signaled by a solid line between the actor and the use case. This is the only relationship between actors and use cases. An action by the actor triggers the use case. Using the Billington Pharmaceuticals case study, an action by a customer, such as placing a phone call, triggers the pharmaceutical ordering process to begin (see Figure 3.2).

Figure 3.2 The communicates or association relationship.

• The uses relationship—This type of relationship between use cases means that there is a shared activity between the connected use cases (see Figure 3.3). For example, using the Billington Pharmaceuticals case study, 75% of doctors have some type of online capability, but 25% have to use a telephone for ordering. Online processing and telephone ordering would have many similar behaviors, thus creating a uses relationship between the two use cases.

Figure 3.3 The uses relationship.

• The extends relationship—This type of relationship between use cases means that the source use case extends the behavior of the target use case (see Figure 3.4). This relationship occurs when an extra step, dependent on a specific event occurring, might be needed to complete a process. For example, using the Billington case study again, one of the identified requirements is that the system must be able to generate e-mails for refill reminders and even contact physicians if the refill count reaches zero. This extra step of contacting the physician when the refill count is zero is an example of an extends relationship.

Figure 3.4 The extends relationship.