A redesigned Web site ... we've done a major redesign and added many new features

Adaptable Process ModelChecklists:
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?