Assignment 2: Requirements

Due in class on October 22 with Presetations October 22 and 24

Assignment Requirements

This assignment consists of two parts: 1) a requirements document and 2) an in-class presentation. The content of the document is outlined below. Make it look professional but be practical (don't waste time). Requirements documents should be clear, complete, correct, and concise. Grading will be based on the content and quality of the requirements document and the oral presentation. The content of the oral presentation is outlined at the end of this page.

Note: Requirements specification documents and oral presentations will vary from project to project, and team to team. Use your judgement in selecting the best approach for your project and team.

Purpose and Content

Requirements documents serve many purposes. They specifiy the goals and scope of the project. In some cases, they are like a contract between the customer and the developers. They are the basis for testing. And in this project, the requirements document will also outline a development schedule.

A good requirements document desribes what the system will do, in a clear and unambiguous way. This can be achieved through careful wording, screen mock-ups or other graphics, and requirements analysis diagrams. A good requirements document can be used to answer questions such as: Is the system supposed to do X or not? How will the system handle it if the user does Y? Who will use the system and for what purposes? Under what environments (machine type, operation system, etc.) will the system work?

The requirements document will consist of

  1. Title Page.
  2. Summary. A two page summary of the project:
  3. Glossary.
  4. Use Cases, Scenarios, Mock-up's.
  5. Deliverables. What are you going to give to the customer? (include the items that apply)
  6. Delivery Platform. What hardware/software/database/etc. will be needed to run the system? This is usually specified by your client.
  7. Development Platform. What hardware/software/database/etc. will you need to develop the system? This is usually decided by you.
  8. Milestones and Effort. A sequence of milestones. For each milestone:
  9. Acceptance Test Plan. Be specific as possible. If you have specific data sets from your client, describe or include them.
  10. Terms and Authorization. What sort of license agreement will you have for your software (open source, GNU, etc.)?
  11. Conclusion. What will your team members gain as individuals and your team gain as a whole by doing this project? Perhaps you will talk about new skills? Tangibles? Intangibles?


Projects often begin vaguely. Clients do not have complete ideas about the work that should be done. They may not fully anticipate their needs. A requirements document starts to sort out the details and make them more clear for both you and the client.

Ideally, you will write the requirements in their "final" form. In reality, the requirements will be revised over time as you and the client learn more about the project. Emphasize clarity of intent and scope over very detailed specification of particular features. Try to meet with the customer to review and revise the document, if possible.

Try to use document formatting that enhances clarity and will be maintainable. Use numbered lists when order is important, bulleted list for unordered items. Use tables when there are lots of items (rows) that must have similar parts (columns), or when computing totals. Use mathematical notation, not English, to specify mathematical relationships. Use digarams or pictures to specify visual or spacial requirements.Make sure you can unambiguously refer to a specific part of the requirements document: for example, the customer might ask you if a certain requirement is satisfied yet, you want to be sure that you are both talking about the same requirement.

Grade yourself by using your document to answer these questions: What would it be like to use this system? What and how much can a user do with the system? If the customer is unhappy with the resulting system, can you confidently say "That is what you authorized when you signed the requirements document"? Would two people who read the same requirements document imagine the same system?

There are certain sections of the document where you need to write very precise English text. Ask yourself how each sentence could be misunderstood. Avoid words with vauge meanings or double meanings. Use specific amounts instead of vauge terms when possible. Include units in any measurements. Ask one of your team members to come up with a misinterpretation of what you wrote.

Requirements Presentations/Reviews

Each team should prepare a 15 minute presentation, after which we will allow up to 5 minutes of questions. Your customer should be present. 

Prepare your presentation appropriately. 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.

ICS125 FQ01 Assignments
ICS125 FQ01
David F. Redmiles Home Page
Department of Information and Computer Science
University of California, Irvine CA 92697-3425