Information Technology Reference
In-Depth Information
Scope, therefore, is an artificial delineation, more to be used for planning.
A designer or an architect must look beyond it.
Looking Back
Over the life cycle of the application, one finds that a lot of requirements
have been addressed. Looking back, we may find that there was some
logic to the order in which the requirements were picked up. Such phasing
of requirements may be driven by business or technical reasons, resource
constraints, product roadmaps, or based on the whims of the development
groups. At times, this is necessary because later requirements cannot be
fully understood or specified, until some earlier ones are designed or
rolled out. For example, one can leave internationalization requirements
of an application to a later phase.
Roadmaps
While such phasing is unavoidable, it is advisable to prepare a roadmap
for the application or product. The design and architecture of the product
should be driven by the roadmap, although the delivery of the features
and functionality is phased. This approach is reflected in the oft-encoun-
tered statement, “We should design top down and build bottom up.” This
is another reason why architectures transcend projects. Architectures must
look at the larger set of requirements and design for that even if one
builds it up slowly. Local and short-term mindsets should be avoided —
they will only add to the cost of the projects. This is similar to a situation
in building a house where it is designed to be a multi-story building
although only the ground floor is being built at the current time, or in
the first phase.
Insist on getting the long-term picture when gathering requirements.
One need not get into the details of the long-term plans. It would be
enough to identify and recognize that such requirements will be coming
down the line. It is the analyst's role to encourage such thinking through
good questions and suggestions.
Types of Requirements
Functional and Nonfunctional Requirements
We have already mentioned the two categories of requirements: (1) func-
tional and (2) nonfunctional.
is what is generally
meant by the use of the term “requirements.” The application is being built
Functional requirements
