 |
Questions:
- What preliminary requirements exist?
Preliminary requirements can differ greatly -
they range from vague memos and personal
preferences regarding calls for tender and
internal requirement documents, right up to user
requirements specifications of varying scope. The
extent of the analysis depends greatly on the
quality of the requirements.
- Where do the preliminary requirements
originate from?
The requirements originate from calls for tender,
from Siemens-internal clients who are already
known, from new clients, etc. The source of the
requirements is important for determining the
type of cooperation to be used in clarifying
unresolved questions.
- Are the preliminary requirements
sufficiently detailed to derive what the product
is intended to achieve? - if not, where and how
can further requirements be obtained?
It is not a matter of being able to describe all
the product features in detail, but merely to
obtain a sufficient degree of certainty as to the
general scope of the product.
- How must the new software work and
how is the product to be used?
Are there any additional conditions which need to
be taken into account when the product is used,
e.g. the system environment, cost ceilings, time
limits for the development work or specifications
regarding the programming language to be used?
- Which requirements are important and
which are less important?
One possible method of rating the importance of
requirements is known as Quality Function
Deployment (based on Richard E. Zultner).
- Have projects with similar
preliminary requirements already been realized?
Perhaps you can use the experience of earlier
projects as a basis (personal know-how, domain
expertise, development environment, technical
solution, etc.) in order to save both time and
costs through reuse.
|
|
Required activities:
- Precondition for all activities for analyzing the
preliminary requirements is that the developers
familiarize themselves with the client's problem
areas.
- At the start of the analysis work, the developers
are engaged primarily in collecting facts.
- To clarify the preliminary requirements and give
vague ideas more concrete form, discussions can
be held between the client, experts in the
problem area, and developers.
- One aspect which is more important than obtaining
a deep understanding of a particular area is to
see the problem from a number of different
perspectives (viewpoint analysis), to define the
project goals and to search for a rough solution
to the problem.
- The information which is collected must be
processed in a way which facilitates planning and
decision-making. It is important in this regard
to sketch out the approach to the solution and
the solution path. Where several alternatives are
possible, the various options should be sketched
out together with their advantages and drawbacks.
- By the end of the phase, a complete overview
should be available to enable a rough assessment
of the costs and to provide reliable information
as to the technical feasibility.
|