Reference no: EM132447628

Assignment

Requirements Phase

The creative idea begins with requirements (and includes the next phase, specifications).

The Requirements phase has a "problem" focus. You are analyzing the problem to be solved. You must understand the problem, and then understand what is needed (required) in order to solve the problem.

From an IT perspective, the requirements phase focuses on "outputs." What output information is required of the ultimate product?

Your investigation in this phase focuses on answering "why" questions (eg, why is there a problem? why is a computerized solution needed? etc).

There are three parts to the requirements phase and three objects to be created:

Part 1 - problem definition document

As part of the "requirements phase," the first step in the system development lifecycle is to understand the problem. By stating the client's problem clearly and concisely you demonstrate understanding of the problem at hand.

The purpose of this document is to state the problem to be solved in a clear, complete and concise fashion. Its purpose as a communicational tool is to ensure that expectations between the "client" and the "designer" (you, the IT professional) are met. By stating the problem, the designer demonstrates an understanding of it which the client can use to validate that the correct problem is being solved.

This document will not discuss solutions (client needs and wants); instead focus on the problem. A possible format for the document is:

- Date
- Developer's (your) name
- Client's name
- Abstract of the problem (brief summary statement)
- Detailed Problem Definition (might include answers to the following:)
- why is there a problem?
- what is the origin of the problem?
- why is a computerized solution necessary?
- what, exactly, is the problem?
- what problems exist in the current method (manual or computerized)?
- what is the existing environment?

The problem definition document will be used to facilitate further discussion between developer and client.

Part 2 - Prototype

The rapid prototype in this phase is an image of what the final product might be. The rapid prototype serves as a visualization tool for both developers and client.

The rapid prototype will be built as a tool to facilitate discussion of requirements and specifications between the client and the developers. It is much easier to discuss aspects of the product when a prototype can be used for demonstration purposes. For some projects, the prototype is easy to envision. For other projects, what a prototype encompasses may not be obvious. Check with your instructor to ensure you understand what is meant by a prototype.

An example of a prototype might be a wireframe image of the product's UI. In this phase the prototype is a visual representation of a possible system.

Part 3 - requirements document

This document is your first attempt at understanding user needs (needs will be finalized during the Specifications phase). This document answers the question: "What is needed (required) in order to solve the problem?" Additionally, the document will begin to answer the question: "What does a good solution to this problem look like?" The primary focus of this document is to identify system outputs by listing the information required by the user to solve the problem.

A possible format for this document is:
Requirements Document
- Date
- Developer's (your) name
- Client's name
- Abstract of the problem (brief summary statement)
- Requirements
- identify what is needed in order to solve this problem
- identify user interface concerns and goals
- identify and describe required outputs
- identify constraints
- transcript of questions/answers with client

The requirements document is used to create a sense of user empathy in the developers. The document should list specifics relating to the requirements and demonstrate how the requirements will solve the problem. Along with the rapid prototype, this document will list user interface possibilities and make a "first pass" at identifying system outputs.

Create this document after "meeting" with the client. Clarify any points by asking questions. Your document should include client questions and answers.

As with all documentation created during the capstone project, you can expect to revise and re-do this document incorporating my suggestions and/or corrections.

Attachment:- Theory of Computation.rar