$63 fixed project work
blank87
Software-Design-Document-Checklist.docxArchitecture Document Checklist
This checklist provides criteria for evaluating a software architecture document. (Architecture being high-level design, much of what is included here also applies to more detailed design specifications.) It can be used as a reminder of what is needed during the creation of a project's architecture document or as a checklist of what to look for when reviewing a completed one.
Not every architecture document needs to conform to all of the criteria listed here to be considered acceptable. In general though, the more criteria that are met the more effective the document will be.
General
The following quality assurance standards apply to all work products:
|
|
Is the document readable? Written documents don’t have to be works of art, but they should be reasonably easy to read and contain no obvious spelling or grammatical errors. When copying and modifying structure or content from earlier previous work, all traces of the earlier work that don't apply to the current document should be removed. |
|
|
Is the document uniquely identifiable? In general a document will be uniquely identifiable if it is given a standard title based on its type (i.e. Software Requirements Specification, Software Project Management Plan, etc.), unique project ID, and version number. |
|
|
Does the document include a title page? The title page should include the title of the document, date of issuance, and unique identifier. |
|
|
Is each page numbered? Having “page x of y" at the bottom of each page will come in handy if the pages should ever become scattered (which can easily occur during a review). |
|
|
Does the document include a table of contents? A table of contents provides overall perspective on the contents of the document and helps readers find the information that is important to them. |
|
|
Does the document include a change history? The changes made to each new version of a document should be recorded. This is can be included in the document or stored externally in the configuration management or version control system. Typical information recorded for each change includes: the date of the change, the person making the change, and a brief summary of the changes made. |
|
|
Are the contents of the document consistent with other documents? The contents of one document should be consistent with the contents of other related documents. |
|
|
Are external references specific? For example, rather than say "this will be specified in another document”, state the specific name and unique identifier of the other document. |
Comments
Specific
The following quality assurance standards are specific to an architecture document:
|
|
Design objectives are clearly stated. For example, if performance is more important than reusability, this should be made clear at the start of the design specification. |
|
|
Does the architecture partition the implementation into clearly defined subsystems or modules with well-defined interfaces? |
|
|
Does the architecture express in a clear way the main patterns of communication between subsystems and modules? |
|
|
Does the architecture satisfy the requirements? |
|
|
Is the architecture traceable to requirements? |
|
|
Any models created should either be expressed with a well-known modeling language, or if a well-known modeling language isn't used, the syntax and semantics of the symbols that are used should be defined. |
Comments
