Informatics 117: Project in Software System Design

Winter Quarter 2013

Requirements

Due Date: February 1, 2013 24:00 PST. (Where? Remember the instructions given on the syllabus page....)

This document must be signed by your customer.  This will help ensure that he or she has agreed that you have met all his or her needs.  This is, after all, a contract with your customer. (An email from your customer attesting to his or her approval of your document suffices.)


Assignment Overview

Develop a specification document that satisfies the needs of your customer. This document consists of three primary components: (1) a requirements specification, (2) an acceptance test plan, and (3) an update to your project plan. Your document may also need to include a glossary defining key terms used that are specific to your application. Other accompanying documentation may be included as well.

The test plan must cover all basic software capabilities to be provided by the system by applying functional test heuristics (black box) to each capability described in the requirements specification and developing a test case for each interaction between capabilities.

You have substantial flexibility in choosing the specific form for the various sections of your deliverables. "Model documents", drawn from previous classes such as ICS 43 (nee 52) or from numerous Web sources, may be drawn upon, to help you determine how to structure this statement.

A list of the standard items that must be turned in with each assignment and posted on the team's web site are in the course syllabus. Required sections of this document are described below.


Deliverable Objectives & Requirements Qualities

Keep in mind that key objectives of a requirements document are to: In addition, keep in mind that a requirements document should possess the following qualities:

Required Document Contents

1. Introduction (Required)

Provide an introduction that discusses the scope and purpose of this document as well as your specific approaches related to the requirements of the system. This introduction should also discuss the organization of this document and guide the reader. (In other words, this section is not about the substance of your project, but rather the choices you made in describing the requirements.) Probably a very short section.

2. Project Summary (Required, but short!)

This section need not be different from that included in your prospectus if your understanding hasn't changed.

3. Requirements Specification (Required)

Use diagrams to help give appropriate overviews and understanding, supplementing the textual description. Note that pictures may well be an essential element of the complete description of any graphical interface.

Acceptance Requirements (Required)

Describes minimal requirements for system acceptance by the client, such as the minimum capabilities that must be provided in the delivered system. You can satisfy this need by simply annotating those parts of the previous section that must be provided in the delivered, end-of-the-quarter system.

4 Acceptance Test Plan (Required)

A test plan capable of demonstrating minimal functionality of all system elements: test cases or strategies should be specified for each software capability specified. If desired, the test cases can be grouped with the capability group to which they apply, otherwise a cross reference listing of some sort should be provided.

5. Glossary (Optional)

Defines all non-obvious terms used in the specifications. May include a detailed data dictionary.

6. Project Plan (Required)

Update your project plan to represent how you have accomplished the work so far. Reassess the project risks. Expand your task network or work breakdown structure to include the effort expended to complete this task. Based on the work you have done, revise your estimates on how much your team can accomplish and deliver. Provide a rationale for any significant changes to the original plan.

7. Auxillary Documentation (Optional)

This section is reserved for any documentation you may have developed during this phase of the project. Specifically, if during the course of developing the your understanding of the various technologies involved in the project, you discovered items that were not documented, but which were important, then you should include that here. Additionally you should list here the major background sources of information that you used during this phase or any that you plan to use during the remainder of the project. This would include references to similar systems and/or procedures.

Requirements Presentations/Reviews.

Dates: Week 4.

Each team should prepare a 10 minute Powerpoint presentation, after which we will allow for questions. 

Your presentation should include the following:

Be sure to focus your presentation on the key issues. Don't spend time with the obvious things. If there's something in your presentation that you find boring, so will your audience. Don't gloss over problems. Your customer wants you to succeed, your instructors want you to succeed. They can't help you unless you tell them where you think the problems are, or are likely to be.