UC IRVINE - ICS 125 PROJECT IN SYSTEM DESIGN
Assignment 2: 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.
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
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.
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.