Datasheet

Designing Applications
15
❑ How many users will be using the system at the same time (concurrently)? How many
in total?
❑ What is the anticipated mix of insert and update activity compared to query and
reporting activity?
The problem is that the only people who can answer these questions are the customers who will
use the finished application, and sometimes it can prove difficult to get answers out of them. It
might be that the demands of their current business are so pressing that they have little time to
answer questions about some future application. It might be that the sensitivities of internal
office politics will make them unwilling to be too helpful in designing an application in which
they feel they have too little ownership. Or it may be that they are trying to be helpful, but just
don't know the answers to these questions, because it is something they have never thought
about. Don't feel bashful about asking questions, however stupid some of them might sound.
What might seem illogical and "obviously wrong" to an outsider might turn out to be a vital,
but unspoken, business practice that simply must be implemented in order for the application
to be acceptable. Once you think you understand a process it is often useful to run it past the
client again for confirmation. Use these discussions to prompt further questioning to fill in any
gaps. In any case, it is vital to try to approach this phase of the project with as few
preconceptions as possible.
Requirements analysis is a skilled art and many organizations fail to appreciate the fact that
good developers do not necessarily make good analysts. In fact, in many ways, developers
make the worst analysts. By their very nature, good developers are constantly looking for
detailed solutions to problems. Someone mentions a business requirement and you can almost
hear the cogs whirring in their brains as their eyes glaze over and they start working out how
they will produce a solution to that requirement; without stopping to ask what the value of
satisfying that requirement is, or even if the requirement truly exists. That is not what you want
from an analyst. You want an analyst to be able to take an objective look at the requirement
expressed by the user, to check that they understand it correctly, to ask what the relevance of
this requirement is to the business, to determine the metrics (ways of measuring) by which the
successful implementation of the requirement can be judged and to express that requirement in
a way that other parties involved in the project will understand.
A variety of tools and methods are available to assist the requirements analysis process. For
example, JAD (Joint Application Development) is a technique that assists requirements
definition by bringing all of the various parties who are interested in the development together
in intense off-site meetings to focus on the business problem to be solved rather than worrying
about specific technical issues.
Whether you use such techniques is up to you. What is important is that you value the
requirements analysis process. This phase of a project is so important because it is the
fundamental mechanism for defining both the scope of the project and the critical success
factors that show when the project has achieved its requirements. It forms the basis for the
contract between the users and the developers, and is the touchstone to be used when resolving
conflict or confusion later on in the project lifecycle.