Adaptable Process Model Checklists: Software Requirements Specification
	IMPORTANT NOTICE: The complete Adaptable Process Model (APM) is provided for informational purposes and for assessment by potential users. The APM is copyrighted material and may not be downloaded, copied, or extracted for use in actual project work. The full hypertext (html) version of the APM may be licensed for use and customization within your organization. Contact R.S. Pressman & Associates, Inc. for complete licensing information.
	Software Requirements Specification Checklist The Software Requirements Specification is the work product that is often produced as a consequence of the analysis activity. The checklist that follows will help you to assist the quality of this document. . For this checklist, the more questions that elicit a negative response, the higher the risk that the specification will not adequately serve its purpose. Do stated goals and objectives for software remain consistent with system goals and objectives? Have important interfaces to all system elements been described? Have all data objects been described? Have all attributes been identified? Do major functions remain within scope and has each been adequately described? Have functions been refined (elaborated) to an appropriate level of detail? Is information flow adequately defined for the problem domain? Are diagrams clear; can each stand alone without supplementary text? Is the behavior of the software consistent with the information it must process and the functions it must perform? Have events and states been identified? Are design constraints realistic? Have technological risks been fully defined? Have alternative software requirements been considered? Have validation criteria been stated in detail; are they adequate to describe a successful system? Have inconsistencies, omissions or redundancy been identified and corrected? Is the customer contact complete? Has the user reviewed the Preliminary User's Manual or prototype? How are the Software Project Plan estimates affected? During the review of a requirements specification we attempt to uncover problems that may be hidden within the specification content. The following guidelines for a detailed specification review are suggested: Be on the lookout for persuasive connectors (e.g., certainly, therefore, clearly, obviously, it follows that), ask why? Watch out for vague terms (e.g., some, sometimes, often, usually, ordinarily, most, mostly); ask for clarification. When lists are given, but not completed, be sure all items are understood. Keys to look for: "etc., and so forth, and so on, such as." Be sure stated ranges don't contain unstated assumptions (e.g., Valid codes range from 10 to 100. Integer? Real? Hex?) Beware of vague verbs such as "handled, rejected, processed, skipped, eliminated." There are many ways they can be interpreted. Beware of ambiguous pronouns (e.g., The I/O module communicates with the data validation module and its control flag is set. Whose control flag?) Look for statements that imply certainty (e.g., always, every, all, none, never), then ask for proof. When a term is explicitly defined in one place, try substituting the definition for other occurrences of the term When a structure is described in words, draw a picture to aid in understanding. When a calculation is specified, work at least two examples. For additional questions and perspective, a comprehensive requirements review checklist has been prepared by Dan Mosley. Return to Checklist Table of Contents