Information Technology Reference
In-Depth Information
case through the proposed screens. Most decision makers want to see
how many clicks it will take to get to the data they need frequently.
The Process of Designing
While designing systems, there is often an urge to put the best or brightest
resource on the job. Although a technically sound person is imperative,
we feel the designer should have a good understanding of the business
domain in which the system is being built. The best designer from a
communication and networking background may be a misfit while design-
ing a mortgage or loan application.
At the start of the design process, a designer has the requirements,
and possibly the architecture documents at his or her disposal. It is
imperative to have a very good understanding of the for mer — to
understand and imbibe all that the author of the requirements document
meant to communicate (the real customer needs). It is best not to make
judgments and overlook details that one might consider trivial, especially
in the initial stages of the process. In projects with aggressive deadlines,
or where the size of the project does not warrant the use of the regular
software life cycle, it is possible that requirements are not very thorough,
or the requirements, architecture, and design phases have collapsed into
a
phase. We prefer the latter, although it may not seem
appropriate. Our philosophy of SEE dictates that the latter approach can
help in looking at the various aspects of the system, which would
otherwise have been neglected for want of time. If each of the phases
had been given inadequate attention, as a designer, one could do the
following:
specification
Insist on more customer meetings to get further details before
closing on one's design.
Build a design based on one's understanding of the application,
and get it approved by the customer. The latter is quite important.
Choose to adopt a prototyping phase in the software life cycle
(refer to Chapter 7 on life cycle for details), even if it is a straw
man that one is able to build.
Any software design should incorporate all of the following:
A structural decomposition of the application into modules and
components — a top-down approach
Detailed definition of each module and component, and their data
processing capabilities
