Professional Computing 3200

Definition of Deliverable A

This definition will be based entirely on the Template for the Requirements Analysis Document.

You are to modify the template in accordance with the instructions below and to submit it as a document via cssubmit (pdf is preferred. Otherwise MS-Word 2003 is acceptable, i.e. .doc, but not .docx )

Please ALSO provide a hard copy to your client. Feedback from your client should inform Del B. (However, you are not required to client sign-off at this stage - see Del B.)

NOTE: This means that you have to take the html document and re-format it as a Writer or Word document.

Note that you will develop this document further in Deliverable B.

Modifications

Up to Section 3.1

Modify as appropriate. In addition add:

Section 3.2

Give a table of the functional requirements. Each row of the table should contain the requirement name, the requirement description, and the Client Value.

If possible, order the table by the ranking of the requirements, calculated from the table in section 3.2.1 below.

(NOTE: Functional requirements describe the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe constraints on how the system accomplishes its functional requirements and are non functional requirements, covered in section 3.3 of the RAD. )

Section 3.2.1

Using the Method of the Value Estimate Ratio described in Lecture 2, create a table of the Requirement Rankings. Each row of the table should contain the name of the requirement, the Client Value out of $100, your Estimated Time to complete the requirement in person hours and the Value Estimate Ratio (computed as Client Value/Estimated time) and the rank (descending order of Ratio).

Sections 3.3-3.4

Complete as appropriate. In many instances "NA" for not applicable will suffice. Where elaboration is required, usually restrict to 2 or 3 lines maximum.
In Deliverable A there is no need to supply any Use Case, Object or Dynamic models: these can be left until Deliverable B.

Section 3.5

What you will be providing here is a first cut at the System Model section - usage scenarios, screen mockups, etc. These will be developed further in Deliverable B. In general, the more detail you can provide your client at this stage, the more feedback you will get to inform Deliverable B.

A scenario is a description of a particular path through a use case. It is a description of what someone would do to carry out a particular function. Two to Three scenarios should be described.

Sections 3.5.2 to 3.5.5.1 (Navigation Paths) will be expanded in Deliverable B. Just put the headings in place but do not provide any content for Deliverable A.

Section 3.5.1

Section 3.5.5.2 

Screen mock ups.  will go here. They need not be exhaustive but a few screens to show the essence of your proposed system.

NEW Section 4

Use this to give a GLOSSARY of terms, building it up as you go.



School of Computer Science & Software Engineering
The University of Western Australia

Last modified: July 22 2013

Modified By: Michael J Wise

UWA