Feasibility Study

Document Management

History of changes

Version
Status
Date
Person resp.
Reason for Change

Persons authorized to make changes

Document was created using the following tools:
Microsoft Word for Windows

Contents

1 Introduction
1.1 Purpose of the document
1.2 Validity of the document
1.3 Definitions of terms and abbreviations
1.4 Relationship with other documents
2 Tasks of the feasibility study
3 Conducting the feasibility study
4 Results
5 Résumé

1 Introduction
1.1 Purpose of the document
This section must specify both the general and specific reasons for drawing up the feasibility study. Generally speaking, it is important to ensure that only requirements which can be fulfilled are included in the software requirements specification (generally in anticipation of the Design phase and possibly the Implementation phase).
Possible specific reasons for drawing up feasibility studies include:
* Uncertainties concerning the feasibility in principle
* Difficult requirements (e.g. with respect to performance)
* Planned use of new, untried tools (check for suitability for the project)
* Existence of multiple possible solution paths (if alternatives are available, how the actual goal can be attained)
* Uncertainties as regards costs / deadlines of possible solution paths.

Possible formulation for a specific case:

The purpose of this feasibility study is to ensure that the requirements set out in the software requirements specification relating to the data throughput rate of 100 Mbit/s can be achieved using the available HW (see section of the software requirements specification).
1.2 Validity of the document
This section must be used to specify the areas of the project for which the feasibility study applies. In most cases, feasibility studies have a limited scope of validity which applies solely to the Definition phase and as a basis for taking certain decisions.
1.3 Definitions of terms and abbreviations
If necessary, this section is to be used to define important terms. If this is done in parallel with drafting the software requirements specification (and is done in greater detail) then it is better to refer to the definitions in the software requirements specification (avoid redundancy!). It is advisable to use alphabetical order for terms and abbreviations.

Example:
COTS Commercial off-the-shelf software
1.4 Relationship with other documents
How is this document related to other documents in the project and to superordinate documents?
Typical references include: Specific primary requirements on the part of the client, specification of proposed solution, user requirements specification, results of the risk analysis, etc. The software requirements specification is often created in parallel with the feasibility study. This often generates important mutual references.
2 Tasks of the feasibility study
This section is to describe the task of the feasibility study in detail (this naturally depends heavily on the purpose set out in section 1.1):
* Why was the study conducted?
* What exactly was to be studied?
* What requirements existed in terms of conducting the study?
3 Conducting the feasibility study
Possible questions include:
* Who conducted the study?
* How was the study conducted? Were any problems encountered using this procedure?
* Under what constraints was the study conducted; did these differ from real conditions?
* What period and effort were required for conducting the study?
4 Results
This section must set out the results of the study. The subdivision is to be based on the relevant tasks:
* If the study was conducted to compare alternative solutions, it is advisable to outline the various solutions first and then to compare them.
* If the task in hand was to test out the fundamental solutions or specific individual solutions, the solution path must be set out in detail and any unresolved or problematical points must be brought to the fore.

HINT FOR OBJECT-ORIENTED DEVELOPMENT
It may also be reasonable to make use of diagrams in object-oriented notification.

Depending on the particular task, it may be important to take into account not only the technical feasibility, but also additional aspects such as e.g.:
* Technical data (performance, storage requirements, etc.)
* Development effort and subsequent effort (e.g. for changes to existing SW)
* Resulting costs (not only personnel costs, but also licenses, investments, etc.)
* Deadlines (in the case of own development; delivery dates in the case of COTS, etc.)
* Various other constraints (e.g. support by manufacturer, secure investment for the future, etc.)
5 Résumé