Learn how to gather and analyze users' specific requirements in .NET Solution Architectures. You will learn the benefits of UML as well as how to use it, and you will see how 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 actorrepresents 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.

CAUTION

The various concepts related to UML, data modeling, and actors as tools for
gathering requirements have continued to gain momentum, so expect to see
questions about these topics in the exam.

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.)

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).

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.

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.