Information Technology Reference
In-Depth Information
reviews can be completed in a short period of time and could add
considerable value to the solution building process.
Requirement enhancement requests should be handled through proper
change control procedures. They can be classified along many vectors,
one of them being the impact the change has on the design and archi-
tecture of the application. Of course, this impact is a function of where
one stands in the life cycle of the project. Early requests can, probably,
be accommodated with less impact than later ones, just as post-deployment
enhancements requiring architectural modifications are likely expensive.
The analyst needs to have a good understanding of the design and
architecture of the application so that he or she can modulate requests
for future enhancements. This is a dialogue that is sometimes missing,
with the analyst sticking to “providing requirements” and leaving the
design to the designers. In fact, there should be active sharing of infor-
mation about the requirements, design, and architecture between the
analyst, the business user, and the designer. Users sometimes stay away
from details of the design and architecture because they are too “technical.”
However, users who understand the architecture, including its limitations,
can come up with more feasible requirements. This again appears to be
a violation of the rule that requirements must be drawn in pristine isolation
from other ground realities, but that a practical approach is generally
cheaper and more efficient for the organization.
Changes in Requirements
Requirements change. A good delivery system handles such changes
smoothly and efficiently, recognizing that the SEE model (solution, engi-
neering, and execution) remains at work even for handling changes. A
well-thought-out solution must be selected for the changes requested,
proper engineering decisions must be made, and all aspects of handling
the execution or implementation of the change must be carefully planned
(Figure 4.3).
Reasons for Change
Why do application requirements change? The most obvious reason is
that the business requirements have changed. As there is a close relation-
ship between the two, a change in the business requirements must result
in a change in the application requirements — unless these new business
requirements can be handled through other non-software means.
