Requirements

Checklist

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.

1. Are all the inputs to your project specified? Where will the data come from? in what format? what ranges?
2. Are all the outputs specified? What format? resolution? speed?
3. Are all output formats specified for web pages, reports, databases, etc?
4. 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)?
5. Are all tasks the user wants to perform specified? You sure?
6. Is the data used in each task and the data resulting from each task specified?
7. 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.
8. Is the level of security specified?
9. Is the reliability specified? If your program crashes, is it OK to loose data? what if the computer crashes?
10. Are minimum machine memory and free disk specified? Are you planning to run on a phone? on windows mobile? on an iphone?
11. Is the maintainability of the system specified?
12. Is the definition of success included (A)? of failure (F)?
13. Can the users read the requirements?
14. Does each requirement avoid conflicts with other requirements?
15. Are acceptable tradeoffs between competing attributes specified? more features versus high reliability, more users versus more reports, richer GUI versus deeper functionality.
16. Do the requirements avoid specifying the design?
17. Are the requirements at a fairly consistent level of detail?
18. Are the requirements clear enough that you could give them to another group and they would build exactly what you want?
19. Is each item relevant to the problem and its solution?
20. Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
21. Are all possible changes to the requirements specified? Are there things the customer is unsure about and might change later on?
22. Where information isn't available before development begins (third-party library details, data) are the areas of incompleteness specified?
23. Are the requirements complete in the sense that if the product satisfies every requirement it will be acceptable?
24. 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?

1. Are you comfortable with you libraries documentation?
2. Have you written short a short program using each one of your libraries?
3. Have you written a short program that integrates all you libraries?
4. Can you get these to compile?
5. Can you check these into svn and have other team members download and re-compile them successfully?