Conceptual ArchitectureDesign Compliance Review Checklist

By Dean Ortiz,2014-04-14 06:45
10 views 0
Have all security considerations been addressed? High-level Design, Comments. ?, Does the design support both product and project goals?

Checklist Description: This checklist captures common elements that should be present in system

    architecture and application design. It is presented during the Conceptual Architecture/Design

    Compliance Review process to stimulate thought, guide brainstorming, and to ensure the architecture

    and design process being outlined contains all appropriate considerations. To ensure that the system

    envisioned fully addresses University Services Enterprise Architecture context, standards and principles, assess the Architecture/Design considerations that apply to your subject matter expertise

    and organizational needs.

    Project Name: Review Date:

Assessment and Recommendations: Notes:

     Approved without revision

     Approved with revisions (see Notes)

     Not approved

    Reviewer: Signature:

    Artifacts Reviewed: Technical/Functional Specification(s)

     Charter/Project Management Plan Application Architecture Diagram

     Business Requirements Document

    Does the architecture allow for implementation of all of the known major requirements?

    Does the architecture communicate an adequate vision of the system that will direct further design activities?

    Is the architecture well organized and provide a concise system

     overview, background information, constraints, and a clear

    organizational structure for all downstream designs?

     Is the architecture designed to accommodate likely change?

    To the extent possible, is the architecture independent of the technology that will be used to implement it?

    Are all external interfaces, including user interfaces, identified and justified?

    Is the level of robustness specified and justified (robustness generally

     means that the architecture is capable of functioning correctly - or at the

    very minimum not failing catastrophically - under many conditions)?

    Is the architecture appropriately layered (client/presentation tier, business logic tier, and data tier)?

     Is the architecture feasible for implementation?

     Can the components be integrated and tested in an incremental fashion?

     Is there any missing or incomplete logic?

     Can the parts of the architecture be traced back to requirements?

    Are standard, not proprietary, components being used wherever possible?

     Does the architecture avoid unnecessary redundancy?

    Will the proposed architecture satisfy all specified quality attributes and performance goals?

     Is an error-handling strategy described and justified?

     Have maintainability issues been adequately addressed? ? 2009 Regents of the University of Minnesota. All rights reserved. Page 1

     Have all reliability and performance needs been addressed?

     Have all security considerations been addressed?

     Does the design support both product and project goals?

     Is the design feasible from a technology, cost, and schedule standpoint?

    Have known design risks been identified, analyzed, and planned for or mitigated?

    Does the level of formality match the project size, project goals, and development expertise?

     If possible, were proven past designs reused?

     Does the design support proceeding to the next development step?

    Can the design be implemented within technology and environmental constraints?

     Does the design emphasize simplicity over cleverness?

     Does the design create reusable components if appropriate?

    Have all reasonable alternative designs been considered, including not automating some processes?

     Does the design allow for ease of maintenance?

    Have the follow areas been considered and included for detailed planning:

    Legal and Regulatory Considerations

    Information Security and Access Considerations

    User Interface Considerations

     Performance and Availability Considerations

    ? Service Level Definition

    ? Capacity Planning

    ? System Monitoring

    ? Business Continuity and Recovery

    Scalability Considerations

    Component Reuse Considerations

    Data Storage and Retention Considerations

    Error Management Considerations

    Quality Assurance Considerations

    Migration/Conversion Considerations

    Reporting and Management Information Considerations

? 2009 Regents of the University of Minnesota. All rights reserved. Page 2

Report this document

For any questions or suggestions please email