We all are familiar with the SDLC process and the role reviews play in helping ensure that the final product is of good quality and is able to meet the system requirements. Reviews are of many kinds ranging from code reviews, test plan reviews, design reviews to performance reviews, audit reviews etc. Let us focus for the moment on design reviews. Typically in the software design phase, the design team receives the requirements in the form of the BRD, the FS or whatever name your organization has chosed to call the inputs. They then proceed to model the application using the tools available like Rational Rose, visio etc. The end result is a set of diagrams and maybe some code which is handed over to the development team for coding. One of the important artifacts that the quality team insists on is the traceability matrix which helps them to verify if all the requirements mentioned in the BRD, FS etc have been covered. But how to we ensure coverage throughout the SDLC process. Did the design team cover everything. If they did, then did the development team leave out something. Did the test cases cover every part of the system and was every functionality tested thoroughly. Thus it becomes essential that the coverage report exists for the design and development phases atleast. The traceability matrix is generally used for checking coverage after the development phase and before the release of the product. There is no real template to document the design coverage other than a set of checklists. You might have come across checklists that contain questions like:

1. Have all mandatory diagrams (Use Case, Class, Collaboration, Sequence, Deployment and Component diagrams) been included?
2. Have symbols and notations been used consistently?
3. Have all assumptions and dependencies been explicitly stated? Are these realistic and reasonable?
Use Cases – Every user interaction with the system must be documented as an Use Case and should be supplemented by an Use Case Diagram.
4. Define the use cases for all the possible interactions of actors with the system.
Activity diagrams - It must address all the requirements specified by the use case. (Activity diagram ensure that the data flow is as per the use case.
5. Describe the internal behavior of an operation pictorially
6. Depict activities that can occur in parallel. The discovery of activities that can occur in parallel will help us to build processes that are more efficient.
7. Help to identify activities whose responsibility belongs elsewhere
8. Allow the discovery of common functionality within a system
9. Show the dependencies, which can be easily identified during the behavior change of the system.
10. Define appropriate relationships between classes. Appropriate design patterns should be used while designing the system. The performance parameters should be taken into account during this process.

and so on

But how do we evaluate a design from an architecture perspective. How do we know that the present design would meet the peak maximum load of a 100,000 concurrent users. Would the system use the same resources irrespective of whether there are 50 users or 500 users. Would the system be able to withstand a DoS attack. Would it allow other applications running on the machine access to some resources or hog all the resources itself. How do you answer such questions by looking at a set of diagrams. Well looks like this others have thought of this before and arrived at some mechanisms to solve this problem.
The methodology is called the Software Architecture Analysis method (SAAM) and relies on a scenario based approach to evaluating software architecture against a set of quality attributes. Some of the main quality attributes include scalability, reliability, security, interoperability etc. In an SAAM evaluation, scenarios representing the quality attributes of the system are developed, prioritized,
and analyzed against the architectural approaches chosen for the system. The results of the analysis are then expressed as risks, sensitivity points, and tradeoffs.
After the scenario generation meeting(s), the refined scenarios are converted
into architectural test cases that the architecture team analyzes against the system architecture. This analysis The architectural test case development and analysis often takes place over an extended period of time (perhaps months) before the architecture team presents the results of the analysis to the stakeholders. This way the software architecture/design can be arrived at as a set of metrics that reveal how the architecture/design measures up against a set of quality attributes.

For more details regarding SAAM and software architecure evaluation can be found at
http://www.sei.cmu.edu/architecture/pub_by_topic.html#evaluation