ÐÒÏ things
Victor V. Metelitsa
=== Cut ===
Requirements model elements
Requirement
A requirement describes a function the system must perform in order to meet its
fundamental business objectives. Requirements also help to define the
boundaries of the system; some functions, though important, might turn out to
be outside the scope of the system being developed. Requirements are formulated
by the users of the system and describe what the system must do.
There are no strict rules governing what you can include as a requirement, nor
what level of detail is appropriate. Indeed, the list is very likely to change
over time, as you gain a better understanding of the problem domain and the
system boundaries. You can use Requirement elements to capture any information
that is useful for setting the system's objectives and that you want to capture
for documentation and tracking purposes. Ideally, requirements should be short,
succinct, and focused on the essential purpose of the system. Often, the
requirement's title alone will suffice; other times, you might want to provide
further explanation, which you can enter as hypertext.
A requirement should avoid any unnecessary descriptions of how the system will
be implemented; instead, it should describe what the system must do for the
user in order to work successfully. If you have quantifiable requirements that
must be met, such as response times or scalability objectives, you can include
these as well.
Use case
A use case is a specific case of usage, tracing a particular task through from
start to finish. Rather than concentrating on how the system functions, use
cases describe what the system must do from the user's perspective. A use case
begins with some stimulus from someone or something outside the system (an
actor, which we will discuss in more detail shortly).
Though more detailed than requirements, use cases are still quite informal. A
use case should be a natural-language description, not pseudocode, and it
should avoid any unnecessary assumptions about implementation. A use case
should do the following:
It should help to capture the purpose of the system from the user's
perspective.
It should define the system boundaries by identifying external agents (actors).
The style and level of detail to use in writing use cases are matters of
judgment and experience. The amount of detail you should include depends upon
the novelty of the system and your familiarity with the problem domain. The
level of detail can also vary from one use case to another: some might describe
high-level interactions of real-world elements, while others might describe
low-level interactions of actual system objects (when such objects are known).
But try to avoid mixing levels of abstraction within a single use case.
Above all, remember that use cases are not formal; they are written in natural
language rather than adhering to any rigorous, readily programmable semantics.
This can lead to some imprecision or ambiguity, but it has the advantage of
making the requirements readily understandable to, and verifiable by, the users
of the system.
Scenario
A scenario is an instance of a use case. In other words, a scenario traces a
particular execution of a use case from start to finish, with specific
conditions and values. While a use case might encompass several possible
outcomes depending upon conditions, a scenario describes only one outcome.
Consequently, there might be multiple scenarios associated with a single use
case.
Concept
A concept is any significant term or idea that is doesn't necessarily qualify
as an actor or a thing. This category can include any aspect of the system you
want to capture, such as real-world objects outside the system or
domain-specific terminology. You might later decide that the idea described by
a concept is also an actor or a thing, in which case you can create links to
indicate this relationship.
Actor
An actor is an entity outside the system that provides a stimulus setting a use
case in motion, or receiving the output from a use case. An actor is not
actually part of the system, but is some real-world entity that interacts with
the system. Usually, actors are human users, although they can also be other
software or hardware entities that initiate actions.
Thing
A thing (also called a domain object) is an entity inside the system. Things
are candidates to become objects in the eventual implementation.
A thing can be transformed into a protocol. See Transforms and code generation
for more information.
Responsibility
A responsibility is a duty of a thing or actor, something it must do in order
for a use case to complete successfully. Each thing or actor can have many
responsibilities, and each can collaborate with other things or actors in their
responsibilities. A responsibility of a thing is a candidate ultimately to
become one or more methods of an implementation object or a relationship
between objects.
A responsibility can be transformed into a message specification. See
Transforms and code generation for more information.
Use case diagram
A use case diagram is a UML-compliant diagram that gives a visual
representation of the system being designed, its actors and use cases, and
their relationships. For more information about use case diagrams, see Use case
diagrammer.
=== Cut ===