Checklist for Analyzing the Preliminary Requirements (tT1)

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.

Siemens AG Österreich, Program and Systems Engineering PSE
Contact: stdSEM Webmaster
Last modified: 08/27/98 15:41
Copyright © Siemens AG Österreich 1997. All rights reserved.