![]() |
Checklist for Specification of Proposed Solution (tE1) |
|
![]() ![]() |
![]() |
1 Introduction 1.1 Purpose of the document Formulation proposal: 1.2 Validity of the document 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 1.4 Relationship with other
documents |
![]() |
![]() |
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.). |
![]() |
Contact: stdSEM Webmaster Last modified: 08/27/98 15:41 Copyright © Siemens AG Österreich 1997. All rights reserved. |