Your requirements document will appear on the wiki. It should
describe your software in plain English, so that your client can
read it and make comments and additions.
Read Chapter 3 to learn why the requirements document is the
most important part of a software project. The items below are
taken from the checklist in page 42.
On the programming side (you must understand your libraries before you get started with design):
- Are all the inputs to your project specified? Where will the data come from? in what format? what ranges?
- Are all the outputs specified? What format? resolution? speed?
- Are all output formats specified for web pages, reports, databases, etc?
- Are all external hardware and software interfaces specified? What third-party libraries are you assuming? what do you expect them to do for you? do you have to interface with external hardware (joystick, death-ray, robosapiens)?
- Are all tasks the user wants to perform specified? You sure?
- Is the data used in each task and the data resulting from each task specified?
- Is the expected response time, from the user's point of view, specified for all neccessary operations? frames per second, time to sort 1000 row table, startup time, save time, etc.
- Is the level of security specified?
- Is the reliability specified? If your program crashes, is it OK to loose data? what if the computer crashes?
- Are minimum machine memory and free disk specified? Are you planning to run on a phone? on windows mobile? on an iphone?
- Is the maintainability of the system specified?
- Is the definition of success included (A)? of failure (F)?
- Can the users read the requirements?
- Does each requirement avoid conflicts with other requirements?
- Are acceptable tradeoffs between competing attributes specified? more features versus high reliability, more users versus more reports, richer GUI versus deeper functionality.
- Do the requirements avoid specifying the design?
- Are the requirements at a fairly consistent level of detail?
- Are the requirements clear enough that you could give them to another group and they would build exactly what you want?
- Is each item relevant to the problem and its solution?
- Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
- Are all possible changes to the requirements specified? Are there things the customer is unsure about and might change later on?
- Where information isn't available before development begins (third-party library details, data) are the areas of incompleteness specified?
- Are the requirements complete in the sense that if the product satisfies every requirement it will be acceptable?
- Are you comfortable with all the requirements? Have you eliminated requirements that are impossible to implement and included just to appease your customer of boss?
- Are you comfortable with you libraries documentation?
- Have you written short a short program using each one of your libraries?
- Have you written a short program that integrates all you libraries?
- Can you get these to compile?
- Can you check these into svn and have other team members download and re-compile them successfully?
Jose M Vidal
Last modified: Wed Sep 3 14:36:40 EDT 2008