Adaptable Process Model Checklists: Reviewing the Analysis Model
	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.
	Reviewing the Analysis Model The analysis model serves as the foundation for all subsequent software engineering activities. For this checklist, the more questions that elicit a negative response, the higher the risk that the analysis model will not adequately serve its purpose. Have requirements elicitation activities been performed? Are the results written down? Have all output/input objects defined as part of requirements elicitation been refined (decomposed)? Have attributes of output/input objects been identified? Have data objects and their relationships (a data model) been described? For conventional software engineering: Have all functions been decomposed? Has a grammatical parse been used to begin the modeling process? Has an entity relationship diagram been developed for all data objects? Has a data flow model been developed? Is each level of the DFD represented at a consistent level of abstraction? Is information flow continuity maintained through various levels of the DFD? Are all data flow items (objects) and transforms labeled and understood? Have extensions for real-time systems been applied, when required? Is the lowest level of the DFD represented in sufficient detail? Has a control flow diagram (or its equivalent) been developed? Have process specifications been developed for each low level transform? Has a list of "events" that affect software behavior been developed? Has a state transition diagram been developed? Does the STD accurately represent system behavior? Is there a way to exit every state? Have usage scenarios (use cases) been applied to the STDs? Have the models been represented in a way that avoids implementation details? Has a CASE tool been used to support the analysis models? Is a data dictionary available? For object-oriented software engineering: Has domain analysis been conducted as a precursor or in parallel with to OOA? Is the domain to be analyzed clearly identified? Have domain objects been identified and defined in detail? Are use cases available for OOA work? Have potential classes been identified for the problem to be solved? Have potential classes been evaluated using selection characteristics? Have chosen classes been categorized by type? Have "responsibilities" (operations, attributes) for each class been identified? Is each responsibility stated as generally as possible? Is system intelligence evenly distributed across classes? Have collaborations (relationships) between/among classes been defined? Has a CRC model (SEPA, 5/e, p. 582) been created? Are CRC index cards (or their equivalent) available for review? Have appropriate class hierarchies been identified? Have appropriate subjects and subsystems been defined? Has an object-relationship model been defined? Has an object-behavior model been defined? Have all elements of the OOA model been reviewed? Have use cases been applied to validate the CRC model and other object models? Has a prototype been developed for any function that is ambiguous or unclear? Has a written Software Requirements Specification been developed? Has the specification undergone formal technical review(s)? Return to Checklist Table of Contents