Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Gathering Requirements
Chapter 1 Architects and Architecture Today 15
The analyst is usually a person who is very familiar with the problem’s domain. He gathers
requirements and writes them down to guarantee the quality and suitability of the system.
The analyst usually composes requirements in a document—even a Microsoft Offi ce Word
document—in a format that varies with the environment, project, and people involved.
Typically, the analyst writes requirements using casual language and adds any wording that is
specifi c to the domain. For example, it is acceptable to have in a requirement words such as
Fund, Stock, Bond, and Insurance Policy because they are technical terms. It is less acceptable
for a requirement to use terms such as table or column because these technical terms are
likely to be foreign terms in the problem’s domain.
Again, requirements need to be clear and verifi able. Most importantly, they must be
understandable, without ambiguity, to all stakeholders—users, buyers, analysts, architects,
testers, documentation developers, and the like.
Note It is not uncommon that analysts write functional requirements using relatively abstract
use cases. As we’ll see in a moment, a use case is a document that describes a form of interaction
between the system and its clients. Use cases created by the analysis team are not usually really
detailed and focus on what the system does rather than how the system does it. In any case, it
must come out in a form that stakeholders can understand. In this regard, a use case describes
all the possible ways for an actor to obtain a value, or achieve a goal, and all possible exceptions
that might result from that.
Specifi cations
Based on functional and nonfunctional requirements, specifi cations offer a development
view of the architecture and are essentially any documentation the architect uses to
communicate details about the architecture to the development team. The main purpose
of specifi cations is to reach an understanding within the development team as to how the
program is going to perform its tasks.
Note Typically, an architect won’t start working on specifi cations until some requirements
are known. In the real world, it is unlikely that requirements will be entirely known before
specifi cations are made. The actual mass of requirements that triggers the generation of
specifi cations depends mostly on the methodology selected for the process. In an agile
context, you start working on specifi cations quite soon, even with a largely incomplete set of
requirements.
Specifi cations for functional requirements are commonly expressed through user stories or
use cases.