Information Technology Reference
In-Depth Information
Functional Requirements
Functional requirements are those that take the systems requirements and
bring out detailed functionality. Functional requirements are followed by
detailed requirements. It therefore requires a judgment call as to the level
of detail that should be embraced. The functional requirements document
is directed at the business users and the technical leads, and should be
at the level of detail required to (1) satisfy the business user for whom
the requirements are being covered and (2) to allow the technical leads
to think of a technical solution to meet those requirements. For example,
functional requirements for a customer support Web site might outline
whether self-service tickets can be created and status tracked, whether
online chat help is available, and whether users can access knowledge
bases.
Detailed Requirements
Detailed requirements must carry enough details for the various designers.
For a business application, this set of designers could be UI (user interface)
designers, the program designers, or the data modelers. Detailed require-
ments are required at the “engineering” stage of the SEE model. At this
stage, certain engineering decisions must be made and there should be
sufficient details in the requirements to enable this. For example, if self-
service tickets must be created, there should be a numbering scheme, a
workflow associated with routing that ticket, and some integration, per-
haps, with a different back-end ticket management system, with bi-
directional flow of information.
This set of requirements — business, system, functional, and detailed
— is a fairly decent stack, and is achievable with reasonable efforts. It is
necessary to put all the documents together and see that there is a natural
flow and elaboration between them. This stack also works well for
enhancement requirements.
Requirements and Process
The fact that a process is being followed to gather requirements does not
itself ensure that the requirements being gathered are correct. The require-
ments gathering process might, however, add a lot of value. It is sometimes
more valuable than all the artifacts that are the outcome of the require-
ments process.
Weinberg has an important observation to make: if the user wants
something to be part of requirements, the user must explicitly ask for it.
