6 Part 6: V-Modell Reference Activities

6.3 Activities

6.3.7 Requirements and Analyses

6.3.7.4 Preparing Requirements Evaluation

Work Product:

Requirements Evaluation

Method Reference:

Evaluation Process

Purpose

The aim of the activity »Preparing Requirements Evaluation is that the acquirer checks and evaluates the user requirements that are available by that time in a way that the possible realization risk becomes as transparent and manageable as possible for him. This task can be performed successfully only if all stakeholders are involved in this process.

The functional and non-functional requirements that will be available by that time will be checked by the acquirer for their technical feasibility, affordability, cost-effectiveness and importance. This task shall be performed by the acquirer.

This approach will be characterized by the fact that the evaluation criteria for the evaluation of the requirements will be at first established, prioritized and evaluated. Finally the evaluated requirements shall be integrated into the project (see Figure 18 ).

Activity Flow

Figure 18: Activity Diagram "Preparing Requirements Evaluation"

6.3.7.4.1 Specifying Evaluation Criteria

Subject:

Requirements Evaluation: Evaluation Criteria

For the activity »Preparing Requirements Evaluation it will be important that all stakeholders know at the outset according to which evaluation criteria the requirements will be tested.

In order to be able to negotiate the functional (use cases) and the non-functional requirements in a transparent and rational way, evaluation criteria shall be defined.

As far as possible the »Requirements Engineer (Acquirer) may already make a suggestion for the assignment of the respective relevant evaluation criteria to the functional requirements/use cases and the corresponding non-functional requirements.

In a (standardized) evaluation catalog in any case the following evaluation criteria should be observed, and the criteria should be sorted according to their importance:

• Accomplishment of tasks and missions
• Compliance with statutory obligations
• Compliance with standardization and harmonization requirements
• Benefits (possible types of benefits may be gained for example in the public sector in the field of IT cost effectiveness considerations)
• Cost-effectiveness, costs (subdivision into cost categories)
• Realization risks
• Technical feasibility within the specified timeframe
• Availability of and demand for budget funds
• Framework conditions and requirements, e. g. political guidelines, standards, infrastructure requirements
• Possibilities of saving costs by using off-the-shelf products
• Target dates, schedules
• Quality aspects, performance aspects
• Safety and security aspects

In order to achieve relevant results, the use of weighted evaluation procedures - e.g. WSM (weghted scoring mdel) or HAP (analytic hierarchy process) - may be useful particularly for the evaluation of off-the-shelf poducts.

The evaluation criteria shall be archived in suitable form so that their reuse will be possible.

6.3.7.4.2 Evaluating Requirements

Work Product:

Requirements Evaluation

The requirements shall be evaluated on the basis of the previously defined »Evaluation Criteria. Together with the developers of the user requirements and supported by experts for system architecture and system design, the »Requirements Engineer (Acquirer) of the acquirer will perform the following work steps:

Analysis of Operational Necessity

The stakeholders will review the operational necessity of individual requirements. Both the non-functional and the functional requirements shall be reviewed. The result of the review will be candidates for requirements that are not classified operational.

How relevant the requirements are shall be discussed in each case by the stakeholders. In this process risks and safety and security aspects of the individual requirements shall be weighed, roughly estimated and possibly reclassified with regard to their importance. It may also be necessary to check to what extent individual requirements can be dropped by merging them with others.

Should there be no agreement on the necessity of individual requirements when evaluating the various requirements, the »Requirements Engineer (Acquirer) shall prepare a proposal for the decision maker.

Analysis of Technical Feasibility

Is the necessity of the »Requirements Specified , the requirements shall be checked for their technical feasibility. When doing this, it is recommended to fall back on possible approximate technical solutions for the realization of the functional and non-functional requirements. The result will be documented in the »Outline of the Life Cycle and the Overall System Architecture. Should the acquirer be unable to perform this task, the »Requirements Engineer (Acquirer) shall take care that an »Outline of the Life Cycle and the Overall System Architecture will be prepared by experts. This outline ("approximate system architecture"), where the requirements will be already assigned to the respective elements of the architecture, will form a valuable basis for describing possibilities for technical solutions.

The requirement that the solution to be developed should be cost-effective and that the consumption of resources should be calculable necessitates a preliminary analysis regarding the possible use of off-the-shelf products. Practice shows that acquirers increasingly have and develop technical solution know-how and competence. In many cases, this is one of the capabilities required of an acquirer (particularly in IT organizational units executing IT projects for functional areas).

A »Market Survey for Off-the-Shelf Products provides the necessary data base. The use of the defined (weighted) evaluation procedures can determine the further proceedings in the project. This corresponds to a qualified make-or-buy decision on side of the supplier.

All results of the technical feasibility studies shall be unambiguously related to the functional and non-functional requirements. It will be especially important that at this point a possible use of off-the-shelf products will be already evaluated. The approach employed should be analogous to the subactivity »Evaluating Off-the-Shelf Products.

Checking Cost-effectiveness and Affordability of the Requirements

Within the scope of the activity »Preparing Requirements Evaluation, considerations regarding the cost-effectiveness shall be made. They are to provide an answer to the question whether a cost-effective realization of the requirements will be possible and whether meeting individual requirements will be profitable in the sense of that the benefits will exceed the costs. When the cost-effectiveness considerations are made, attention should be paid to the following aspects:

• The requirements and their resulting costs shall be made so transparent that the decisions made can be traced by the responsible decision makers of the project.
• Should it be not possible to quantify the cost estimates, at least an order of priority of the possible costs for the individual requirements shall be established.
• The users should once more seize the opportunity to look critically at the "value" of individual functional and non-functional requirements of the planned IT system.

• Should it not be possible to express the benefits in monetary units (for example replacement of the old process with cost savings), qualitative aspects of the benefits should be used (for this purpose in the public sector IT cost effectiveness considerations may be used). If the benefits are not quantifiable, the following aspects should be considered:

  • a possible increase in performance when carrying out tasks and acceleration of work flows and processes
  • that it will be made possible to provide information to decision makers and the controlling staff by supporting the decision and/or command and control process
  • the urgency of a replacement and the lack of flexibility of the legacy system will be highlighted for example by a high error rate, failures, system crashes, maintenance problems, manpower shortages, too narrow limits concerning development or expansion, interface problems and lack of user-friendliness.
  • the stipulated compliance with statutory requirements, e. g. by meeting data protection/data security requirements and orderly work flows according to internal standards.

To estimate costs, allocate funding or determine the budget, concepts - which at this time may still be very rough - of an architecture that provides a solution and technical solutions provided by the market in off-the-shelf products shall be considered.

Preparing Evaluation Results

On the basis of the evaluation, the following alternatives for further handling of user requirements will have to be identified:

• Confirmation that it is possible to realize a requirement economically.
• Changes of requirements:

• • Those requirements that are absolutely necessary for the operational use of the system shall be realized in any case with suitable technical solutions, possibly neglecting cost-effectiveness considerations.

  • Those requirements that can not or only partly covered economically by possible technical solutions - in particular by off-the-shelf products - shall be indicated. Their relevance to the system shall be shown and a suggestion shall be made how to meet those requirements. In this connection the following options will be conceivable:

    • Requirements that do not have to be covered should be marked "non realizable", since they cannot be realized within a foreseeable planning period. This does not mean, however, that they are cancelled completely.
    • Requirements that are not covered may be modified in a way that they are met by the functionality of one or more off-the-shelf products.
    • For requirements that are not covered, "adaptation" work on the finished product will be suggested that is still affordable within the framework of the budget. In requirements controlling risks and safety and security will be examined and discussed.

The result of the subactivity »Evaluating Requirements will be the harmonized functional and non-functional requirements that are cost-effective, necessary, affordable and technically feasible.

6.3.7.4.3 Integrating Evaluation Results

Work Product:

Requirements Evaluation

The acquirer shall document the result of the evaluation of the user requirements in the product »Requirements Evaluation and make it available to all roles participating in the evaluation process.

Subsequently the »Evaluation Results shall be integrated in the product »Requirements Specification by changing and supplementing the requirements concerned.

The »Requirements Engineer (Acquirer) shall take care that the results achieved in the evaluation process can be reconstructed also by persons not involved in the activity »Preparing Requirements Evaluation.

The resulting consequences for the projects may be evaluated differently. One possibility is that the results developed for the preliminary system architecture and off-the-shelf products are not integrated into the request for proposals since the acquirer expects innovative and cost-effective solutions proposals from the industry.

An other possibility is the use of the result for defining the scope of delivery for the future development of the RFP concept.