Information Technology Reference
In-Depth Information
This is a simple yet profound observation about the requirements process.
Users may assume that there is something about the requirements gath-
ering process that will allow analysts to determine “true” requirements,
even if they do not spell it out. In the end, however, it may turn out that
the requirements are what the user tells them are the requirements. What
the user does not tell the analyst may not get “discovered” and included
in the requirements.
Approaching Requirements
If a problem can be put in a form — an equation, a model — for which
a solution exists, then there can be drastic savings in terms of the time
required to arrive at solutions. This is a popular, general problem-solving
approach: look at a problem and try to convert it to a form that has a
known solution. Similar approaches are possible in applications develop-
ment. If the analyst can bring the requirements into a form or framework
that allows reuse of available work, and the use of available solution
frameworks, then development can be speeded up. Accordingly, analysts,
architects, and development team leads have to work as a team. And
successful teams often stay together and are more productive than teams
formed on-the-fly. This also strengthens the argument as to why the three
should be more actively working together during the requirements phase,
instead of their roles emerging sequentially in the development process.
“…the architect must be the one who develops require-
ments. Even though the user may have provided a pre-
liminary set of requirements with the RFP, it is essential
that the development team and the architect conduct
their own requirements study to identify and analyze
the logic, the way the system is used and the opera-
tional requirements.
As the project moves through the requirements phase,
design concepts begin to emerge based upon early
perceptions of functionality and performance. These
design concepts are essentially theoretical models.
They help the system architect to “floor plan” the ele-
ments of the system and help both the design team and
the user team to understand the relationships and
dependencies between each and every module.
The whole point of doing an in-depth study is that the
people who will design and build the … system must
