Requirements Analysis - Deliverables

The evidence of requirements analysis is the documentation produced. The level of formality in documentation should be appropriate to the project. Each type of information could reside in its own document, be split into multiple documents, or they could be subsections in a single, combined document. The type of information never changes across projects – only the level of formality. Documentation produced by the requirements analysis process is:

• Software Requirements Specification (SRS). Written software requirements document.
• Test Objectives. Written test objectives. May also be titled as a Unit and Integration Test Plan. A test objective is a brief description of the condition to test and the expected result. It says what to test, not how.
• Verification or Validation Protocol. Written test steps.

Example Requirement

The software will maintain configuration information in a CRC protected file. At program start, the software will verify that the configuration CRC is correct. If the CRC is not correct, the user will be informed and the program will exit.

(CRC = Cyclic Redundancy Check)

Example Test Objectives

1. Use a configuration file with a good CRC. Start the program. Verify that the program starts normally.
    
2. Alter the configuration file and do not correct the CRC (file is corrupted). Start the program. Verify that the user is informed of the error and that the program then exits.
    
3. Use a configuration file with a good CRC, but alter the CRC so that it no longer matches (CRC is corrupted). Start the program. Verify that the user is informed of the error and that the program then exits.
    
4. Use a configuration file with a good CRC. Start the program. Verify that the program starts normally. (This is a sanity check to ensure that the system can be restored to proper operation.)