Feasibility by jg7sgw6

VIEWS: 347 PAGES: 4

									Feasibility Study: (September 10th, 2009)

http://www.cs.cornell.edu/courses/cs501/2007sp/assignments.html

Write a short feasibility report that describes the project that you have selected.
The exact form of the report is up to you, but it should be well written and
suitable to present to an external client. The length is likely to be between two
and five pages.

The report should include the following:

      The client for whom the work will be done.
      A statement of the task to be undertaken.
      A preliminary requirements analysis.
      Suggested deliverables.
      Outline plan, showing principal activities and milestones.
      Visibility plan. How will you keep in contact with the client and report
       progress? How will you communicate among your team?
      Probable technical requirements

All members of the project team should share in the production of the report.
When you have completed your report, (a) deliver it to the client, (b) Make the
report available to everyone on the message board, and (c) submit a hardcopy to
the Instructor.

Example of a Feasibility Report Format

FEASIBILITY STUDY

The Group

Name all the members and the leader.

The Client

Name your client and his/her information.
The Task To Be Undertaken:

What is to be developed? Why?

Benefits:

List the benefits of creating such software.

A Preliminary Requirements Analysis:

List the functional requirements of the system:

Technical Requirements – Feasibility:

List what Server, Database, Web Interface or/and any other requirements to be
used.

Suggested Deliverables:

Management Deliverables:

1. Requirements Analysis – a document and a presentation to go over the formal
requirements of the project, both functional and non-functional. This deliverable
ensures that the Group is working on a system that closely matches to the wishes
of the Client. This deliverable gives the Client a chance to modify and correct
items that were wrongly communicated or missed out before allowing the Group
to proceed further in the design.

2. Design Document – a document and a presentation to go over the design of the
system. This is the Group’s opportunity to go over how the project is to be
implemented to the Client. This deliverable is done by the more technical and
experienced in the Group, based on the understanding of the requirements
established in the previous deliverable.

3. Source Code – a document, presentation along with the source code of the final
completed project. This final deliverable wraps up and concludes the project. In
this deliverable, the Group delivers the final implementation based on the
requirements specified and the design developed in previous stages. The system
would have been tested thoroughly with unit tests and with a final acceptance
test and would be ready for deployment to the production system.
Technical Deliverables:

List the Technical deliverables to the client and the instructor.

Walk-Through:

The client and the developing team are to set together and decide if the system at
hand is acceptable by the client.

Outline Plan (Milestones)

For every deliverable “milestone”, the client must be presented with and agree to
it.

Visibility Plan

External: List all meetings “date and time” made with the clients.

Internal: List all meetings made with the group members and show who
attended and who did not.



Risk Analysis

1. Changing Requirements:

Risk: The Client may have different ideas about the system during the course of
the project. Depending on the situation, the changes that the Client wishes to
have implemented may require little or major changes to the architecture.

Solution: To reduce the possibility of this occurring, the Group needs to establish
a clear visibility plan with the Client.

2. Incomplete Requirements:

Risk: It is possible that requirements may be implied but not discussed or
misunderstood. This frequently occurs after meetings.
Solution: The Group’s interpretation of the Client’s requirements will be
presented back to the Client to get a confirmation on whether the Group has
understood the Client. Frequent client updates and a high level of visibility will
also help call attention to any misunderstandings.

3. Lack of Resources, Tools:

Risk: List all risks and if there are any solutions.

Conclusion:

Decide whether the project is feasible and that the group is willing to undertake
it.

								
To top