Checklist for Specification of Proposed Solution (tE1)


1 Introduction

1.1 Purpose of the document
The specification of the proposed solution serves as a technical basis for the project decision report on execution / non-execution of the project and on the type of execution to be performed, which is described in the preliminary project plan and preliminary QA plan.

Formulation proposal:
The purpose of the proposed solution specification is to check the technical feasibility and to identify a possible solution path for the planned project enterprise described below.

1.2 Validity of the document
The proposed solution specification is of only limited scope since, in the Initiation phase, it serves as a basis for making decisions on execution / non-execution of the set task as a project. The content of this document - if the project decision report is positive - will then be incorporated into the documents of the Definition phase (as a tender of software requirements specification).

This section must also specify the constraints (in addition to the primary requirements) on which the proposed solution specification is based (e.g. development at one / more sites, use of existing HW / SW licenses, etc.), if this affects the proposed solution specification or the solution path.

1.3 Definitions of terms and abbreviations
If necessary, the terms used in the document are to be defined in this section. In particular, important technical terms should be specified.
An alphabetical order is recommendable for the terms and abbreviations.

1.4 Relationship with other documents
How does this document relate to other documents (of the project, solutions of a previous project, etc.)? Does the proposed solution path have any constraints for project control and quality assurance?

2 Purpose, goal and application of the solution

This section must clearly identify the task which is to be resolved, what this is intended to achieve and how the solution is to be used.

3 Primary requirements

This section must specify the existing primary requirements. If the primary requirements which have led to the Initiation phase being triggered are available in written form, it is sufficient merely to refer to these (they would be best enclosed in an annex to the proposed solution specification).

4 Proposed solution

The "solution" describes "what": What product is to be created, what is the product to look like and what is it to do? These questions are best covered by means of a rough description of the deliverables, i.e. all components in the product which is to be supplied.

5 Proposed solution path

The "solution path" describes "how": How can we arrive at this solution? This section therefore deals with initial considerations relating to technical implementation and outlines the solution path (use of tools, use of standard software or COTS (commercial off-the-shelf software), possible reuse of components already developed).

Particularly important in this context is a preliminary decision as to whether the solution can be implemented either in full or to a large extent using existing products or whether new developments will be needed for the most part.

If the user already has a rough idea (or specifications) for the design of the system, these considerations should be stated in this section (e.g. client / server architecture, use of specific database system, etc.).

6 Possible solution alternatives

Where they are significant, possible solution alternatives must be outlined, together with their relevant advantages and disadvantages (this is particularly true for new tasks where the specifications have little detail).

Alternative solutions can relate to both the solution itself (which product features are to be developed, what form is the product interface to take, input / output media, etc.) as well as different solution paths (e.g. different HW / SW platforms, advantages and disadvantages of using specific development environments, discussion on adaptation and use of COTS (commercial off-the-shelf software) compared to complete own development, etc.).

7 Literature

This section must set out all documents cited in the proposed solution specification together with the documents which the proposed solution specification is based on (such as technical specifications, product sheets, experience reports, tenders for outsourced goods, etc.).


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.