Project Management Software Requirements Checklist
Requirements content
- Are all the inputs to the system specified including their source, accuracy, range of values, and frequency?
- Are all the outputs from the system specified including their destination, accuracy, range of values, frequency, and format?
- Are all the report formats specified?
- Are all the external hardware and software interfaces specified?
- Are all the communication interfaces specified including handshaking, error checking, and communication protocols?
- Is the expected response time, from the user’s point of view, specified for all necessary operations?
- Are other timing considerations specified, such as processing time, data transfer, and system throughput?
- Are all the tasks the user wants to perform specified?
- Does each task specify the data used in the task and data resulting from the task?
- Is the level of security specified?
- Is the reliability specified including the consequences of software failure, vital information protected from failure, error detection, and recovery?
- Are acceptable tradeoffs between competing attributes specified, for example, between robustness and correctness?
- Is maximum memory specified?
- Is the maximum storage specified?
- Is the definition of success included? Of failure?
- Is the maintainability of the system specified, including the ability to respond to changes in the operating environment, interfaces with other software, accuracy, performance, and additional predicted capabilities?
Requirements completeness
- Where information isn’t available before development begins, are the areas of incompleteness specified?
- Are the requirements complete in the sense that if a product satisfies every requirement, it will be acceptable?
- Are you uneasy about any part of the requirements? Are some parts impossible to implement and included just to please your customer or boss?
Requirements quality
- Are the requirements written in user language? Do the users think so?
- Do all the requirements avoid conflicts with other requirements?
- Do the requirements avoid specifying the design?
- Are the requirements at a fairly consistent level? Should any requirement be specified in more detail? Should any requirement be specified in less detail?
- Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?
- Is each item relevant to the problem and its solution? Can each item be traced to its origin in the problem environment?
- 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 including the likelihood of each change?
