Information Technology Reference
In-Depth Information
to deliver some functionality — inventory management, hospital admissions,
tax returns preparation, etc. The requirements related to the business pro-
cessing logic are embodied in the functional requirements.
can also be termed “auxiliary require-
ments.” In the examples discussed above, nonfunctional requirements
would be related to performance, and support for various browsers. In a
sense, this is a catch-all category. Nonfunctional requirements can have
a direct impact on the design and architecture of the solution. Others
affect the delivery of the solution, and may be a project deliverable rather
than a software deliverable. Some of the nonfunctional requirements might
be related to the application's implementation. There could be, say, a
nonfunctional requirement that technical support for the application needs
to be available from 6 a.m. to 6 p.m.
Nonfunctional requirements
Wants and Needs
In addition to functional and nonfunctional requirements, two other terms
are often encountered: “wants” and ”needs.” A customer may have many
. The customer
may not be able to distinguish clearly between the two; what he calls
requirements is often a mix of the two. A good analyst, however, knows
how to distinguish between the two.
Wants and needs are closely related. Wants may contain real require-
ments that will have to be sifted out. For example, a customer may “want”
all historical data online. A little investigation might, however, reveal that
what he needs is a year's data to be accessible should ther e be any
disputes. The point to be noted is that wants, and wish lists, reveal needs
that warrant further investigation.
There is still another reason why an analyst must separate wants from
needs. It may be dangerous to assume that the customer always knows
his requirements. It is possible that the analyst or the project team has
more experience in building and implementing such applications. If so,
they can suggest many requirements that the customer might not have
thought of.
wants,
but a system must be designed that meets his
needs
Classifying Requirements
There are various ways of classifying requirements. One is to separate
them into:
Essential
Nice-to-have
