SlideShare a Scribd company logo
1 of 4
Architecture and Design Review Checklist
Performance
How does it map to the performance curve?
Does it negatively impact other areas, such as landing pages?
What is the expected longevity test needs?
What is the expected capacity test needs?
Is there minimum use of system resources, including memory and execution time?
Does the design facilitate a perceived quick response to user actions?
Is the most critical information relayed back to the user first?
Is asynchronous processing effectively used to improve performance?
Are there any potential sources of bottlenecks in the system?
Is caching being utilized appropriately?
Are there any potential race conditions in the system?
Failover
What are the failover points?
Will the feature as a whole require fault tolerance?
What specific components of the feature need failover capabilities?
What persistent state information is required to support failover?
How will state be handled?
Failure
What are the failure points in the system?
What is the expected user experience for each failure point?
What is the expected system action for each failure point?
Security
From what channels is this feature accessible?
What mechanism is used to secure the feature?
Who has authority to use the feature?
How will this authority be handed out?
Robustness, Reliability, Exceptions, and Logging
Is transaction logging going to a common place?
Is clickstream logging going to a common place?
Where is any other application logging going?
What logging needs to be rolled up to the long-term reporting facility?
What will be logged at each point? What will be rolled to the long-term reporting?
How will the support team query the logs?
Are resources appropriately released during errors and timeouts?
Are all resources properly relinquished as soon as possible?
Are resources held onto when they will be re-used?
Does the system do sufficient data validation of input?
Does the system properly handle unavailable resources?
Does the system employ retry logic properly?
Does the system recover from unexpected events?
Does the design ensure that end users cannot carry out any incorrect actions in case of an error?
Are exceptions being caught and reported at the appropriate / correct nested level?
Does the design address generation of detailed debug/trace messages?
Is all critical error information being logged?
Are all necessary elements of a transaction being logged?
Monitoring
Who is expected to monitor the status of the system?
Have transaction test pages/points been identified?
How will the monitoring group be notified of failures?
What is the escalation procedure for faults raised by this app?
Physical Deployment
What hardware will a transaction flow through during its lifetime?
What is the capacity estimates for this feature?
Will additional hardware be required to support this app?
Have URL naming conventions been followed?
Consistency and Reuse
Is the design consistent with other aspects of the system?
Are existing components re-used?
Are design patterns being applied properly?
Are components that have the strong potential of reuse being designed for reuse?
Are components that “probably won’t be reused” being over-designed for reuse?
Is there a clear separation of responsibilities between components?
Manageability
How will load balancing be performed?
Does the system provide a “system health status check” capability?
Does the system provide for graceful startup/shutdown capability?
Does the system provide view and modify capability for application characteristics?
Do the error conditions provide understandable messages with enough level of detail to
specify the cause and action that should be taken?
Have all utility program requirements been addressed?
Simplicity
Are Class & Interface names appropriate, easy to understand?
Do any class hierarchies have unnecessary levels of inheritance?
Are classes the “right size” (split apart or merged appropriately)?
Are protocols/handshakes between systems simple and optimized?
Are subsystems loosely coupled and adequately independent?
Is the design flexible (can be modified as requirements change)?
Is the design understandable and coherent?
Are business rules clearly and truly separated from the display components (e.g. no rules in JSPs)?
Miscellaneous
Does the architecture address all roles?
Have existing frameworks been leveraged?
Does the design use and comply with the tools, technologies currently in use?
Does the design meet all business requirements?
Does the design account for backward compatibility?
Does the design minimize impact to existing applications and infrastructure?
Does the design consider packaging/dependency issues?
Are any special security considerations adequately handled?
Are any special deployment issues being considered?
Are there any special fail-over considerations?
Is the design adequately configurable for different environments (dev, prod, etc.)?
Is the system testable?
Have opportunities for testing & monitoring hooks been taken?
Is it possible to isolate run-time problems?
Is transaction scope adequately handled (i.e. something must be a two phase commit)?
Are valid/invalid state transitions being considered (handle browser back button, bookmarks etc)?
Does the design have/require a sufficient authentication system?
Does the design have/require a scalable authorization system?
Does the design take into account globalization compatibility?

More Related Content

What's hot

Software Engineering Diversity
Software Engineering DiversitySoftware Engineering Diversity
Software Engineering DiversitySayedMokarrom
 
Quality attributes testing. From Architecture to test acceptance
Quality attributes testing. From Architecture to test acceptanceQuality attributes testing. From Architecture to test acceptance
Quality attributes testing. From Architecture to test acceptanceIT Weekend
 
System analysis and_design.docx
System analysis and_design.docxSystem analysis and_design.docx
System analysis and_design.docxAlaJebnoun
 
Software Architectures - An Overview
Software Architectures - An OverviewSoftware Architectures - An Overview
Software Architectures - An OverviewVishwas Sutar
 
CIS 2303 LO2 Part 3
CIS 2303 LO2 Part 3CIS 2303 LO2 Part 3
CIS 2303 LO2 Part 3Ahmad Ammari
 
IS-1 Short Report [Muhammad Akram Abbasi]
IS-1 Short Report [Muhammad Akram Abbasi]IS-1 Short Report [Muhammad Akram Abbasi]
IS-1 Short Report [Muhammad Akram Abbasi]Akram Abbasi
 
Critical System Validation in Software Engineering SE21
Critical System Validation in Software Engineering SE21Critical System Validation in Software Engineering SE21
Critical System Validation in Software Engineering SE21koolkampus
 
Evaluation of an Interactive Device : Microsoft Surface RT
Evaluation of an Interactive Device : Microsoft Surface RTEvaluation of an Interactive Device : Microsoft Surface RT
Evaluation of an Interactive Device : Microsoft Surface RTsampahdavid
 
Resume_Alok_IT_Audit
Resume_Alok_IT_AuditResume_Alok_IT_Audit
Resume_Alok_IT_AuditAlok Sharma
 
Non Functional Requirement.
Non Functional Requirement.Non Functional Requirement.
Non Functional Requirement.Khushboo Shaukat
 
Online compliant response system for corporation
Online compliant response system for corporationOnline compliant response system for corporation
Online compliant response system for corporationDhavamani Prakash
 
6 reasons contract management tools fail
6 reasons contract management tools fail6 reasons contract management tools fail
6 reasons contract management tools failAavenir
 
Stakeholders, viewpoints and concerns
Stakeholders, viewpoints and concernsStakeholders, viewpoints and concerns
Stakeholders, viewpoints and concernssommerville-videos
 
3.2 Years Experience as Test Engineer.DOC
3.2 Years Experience as Test Engineer.DOC3.2 Years Experience as Test Engineer.DOC
3.2 Years Experience as Test Engineer.DOCRaushan kumar
 

What's hot (20)

Sdlc
SdlcSdlc
Sdlc
 
Software Engineering Diversity
Software Engineering DiversitySoftware Engineering Diversity
Software Engineering Diversity
 
Quality attributes testing. From Architecture to test acceptance
Quality attributes testing. From Architecture to test acceptanceQuality attributes testing. From Architecture to test acceptance
Quality attributes testing. From Architecture to test acceptance
 
System analysis and_design.docx
System analysis and_design.docxSystem analysis and_design.docx
System analysis and_design.docx
 
Software Architectures - An Overview
Software Architectures - An OverviewSoftware Architectures - An Overview
Software Architectures - An Overview
 
CIS 2303 LO2 Part 3
CIS 2303 LO2 Part 3CIS 2303 LO2 Part 3
CIS 2303 LO2 Part 3
 
IS-1 Short Report [Muhammad Akram Abbasi]
IS-1 Short Report [Muhammad Akram Abbasi]IS-1 Short Report [Muhammad Akram Abbasi]
IS-1 Short Report [Muhammad Akram Abbasi]
 
Lession 5
Lession 5Lession 5
Lession 5
 
Critical System Validation in Software Engineering SE21
Critical System Validation in Software Engineering SE21Critical System Validation in Software Engineering SE21
Critical System Validation in Software Engineering SE21
 
Evaluation of an Interactive Device : Microsoft Surface RT
Evaluation of an Interactive Device : Microsoft Surface RTEvaluation of an Interactive Device : Microsoft Surface RT
Evaluation of an Interactive Device : Microsoft Surface RT
 
Resume_Alok_IT_Audit
Resume_Alok_IT_AuditResume_Alok_IT_Audit
Resume_Alok_IT_Audit
 
Non Functional Requirement.
Non Functional Requirement.Non Functional Requirement.
Non Functional Requirement.
 
Online compliant response system for corporation
Online compliant response system for corporationOnline compliant response system for corporation
Online compliant response system for corporation
 
Automated matching
Automated matchingAutomated matching
Automated matching
 
Software testing
Software testingSoftware testing
Software testing
 
Chap1 RE Introduction
Chap1 RE IntroductionChap1 RE Introduction
Chap1 RE Introduction
 
6 reasons contract management tools fail
6 reasons contract management tools fail6 reasons contract management tools fail
6 reasons contract management tools fail
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Stakeholders, viewpoints and concerns
Stakeholders, viewpoints and concernsStakeholders, viewpoints and concerns
Stakeholders, viewpoints and concerns
 
3.2 Years Experience as Test Engineer.DOC
3.2 Years Experience as Test Engineer.DOC3.2 Years Experience as Test Engineer.DOC
3.2 Years Experience as Test Engineer.DOC
 

Similar to Arch Review Check List

TREA - transparent enterprise architecture
TREA - transparent enterprise architectureTREA - transparent enterprise architecture
TREA - transparent enterprise architectureJernej Vrčko
 
Eliciting Non-Functional Requirements
Eliciting Non-Functional RequirementsEliciting Non-Functional Requirements
Eliciting Non-Functional RequirementsLisa Combest
 
Software Architecture and Design Introduction
Software Architecture and Design IntroductionSoftware Architecture and Design Introduction
Software Architecture and Design IntroductionUsman Khan
 
Eliciting non functional requirements
Eliciting non functional requirementsEliciting non functional requirements
Eliciting non functional requirementsLisa Combest
 
Quality Attributes of Web Software Applications ∗
Quality Attributes of Web Software Applications ∗Quality Attributes of Web Software Applications ∗
Quality Attributes of Web Software Applications ∗hasnainqayyum1
 
Project Documentation Student Management System format.pptx
Project Documentation Student Management System format.pptxProject Documentation Student Management System format.pptx
Project Documentation Student Management System format.pptxAjayPatre1
 
Software Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesSoftware Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesKiran Munir
 
Project on multiplex ticket bookingn system globsyn2014
Project on multiplex ticket bookingn system globsyn2014Project on multiplex ticket bookingn system globsyn2014
Project on multiplex ticket bookingn system globsyn2014Md Imran
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riportDilip Prajapati
 
Software Process and Requirement
Software Process and RequirementSoftware Process and Requirement
Software Process and Requirementcricket2ime
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riportDilip Prajapati
 
System_Analysis_and_Design_Assignment_New2.ppt
System_Analysis_and_Design_Assignment_New2.pptSystem_Analysis_and_Design_Assignment_New2.ppt
System_Analysis_and_Design_Assignment_New2.pptMarissaPedragosa
 
02. Fault Tolerance Pattern 위한 mindset
02. Fault Tolerance Pattern 위한 mindset02. Fault Tolerance Pattern 위한 mindset
02. Fault Tolerance Pattern 위한 mindseteva
 
Different Approaches To Sys Bldg
Different Approaches To Sys BldgDifferent Approaches To Sys Bldg
Different Approaches To Sys BldgUSeP
 
Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...Editor IJCATR
 

Similar to Arch Review Check List (20)

TREA - transparent enterprise architecture
TREA - transparent enterprise architectureTREA - transparent enterprise architecture
TREA - transparent enterprise architecture
 
Eliciting Non-Functional Requirements
Eliciting Non-Functional RequirementsEliciting Non-Functional Requirements
Eliciting Non-Functional Requirements
 
Criteria For EA Tool Selection
Criteria For EA Tool SelectionCriteria For EA Tool Selection
Criteria For EA Tool Selection
 
Software Architecture and Design Introduction
Software Architecture and Design IntroductionSoftware Architecture and Design Introduction
Software Architecture and Design Introduction
 
Eliciting non functional requirements
Eliciting non functional requirementsEliciting non functional requirements
Eliciting non functional requirements
 
chapters
chapterschapters
chapters
 
Quality Attributes of Web Software Applications ∗
Quality Attributes of Web Software Applications ∗Quality Attributes of Web Software Applications ∗
Quality Attributes of Web Software Applications ∗
 
Project Documentation Student Management System format.pptx
Project Documentation Student Management System format.pptxProject Documentation Student Management System format.pptx
Project Documentation Student Management System format.pptx
 
Software Requirements Engineering Methodologies
Software Requirements Engineering MethodologiesSoftware Requirements Engineering Methodologies
Software Requirements Engineering Methodologies
 
Feasible
FeasibleFeasible
Feasible
 
Project on multiplex ticket bookingn system globsyn2014
Project on multiplex ticket bookingn system globsyn2014Project on multiplex ticket bookingn system globsyn2014
Project on multiplex ticket bookingn system globsyn2014
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
 
sat_presentation
sat_presentationsat_presentation
sat_presentation
 
Software Process and Requirement
Software Process and RequirementSoftware Process and Requirement
Software Process and Requirement
 
Online auction system srs riport
Online auction system srs  riportOnline auction system srs  riport
Online auction system srs riport
 
System_Analysis_and_Design_Assignment_New2.ppt
System_Analysis_and_Design_Assignment_New2.pptSystem_Analysis_and_Design_Assignment_New2.ppt
System_Analysis_and_Design_Assignment_New2.ppt
 
Ch21
Ch21Ch21
Ch21
 
02. Fault Tolerance Pattern 위한 mindset
02. Fault Tolerance Pattern 위한 mindset02. Fault Tolerance Pattern 위한 mindset
02. Fault Tolerance Pattern 위한 mindset
 
Different Approaches To Sys Bldg
Different Approaches To Sys BldgDifferent Approaches To Sys Bldg
Different Approaches To Sys Bldg
 
Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...Improved Strategy for Distributed Processing and Network Application Developm...
Improved Strategy for Distributed Processing and Network Application Developm...
 

Arch Review Check List

  • 1. Architecture and Design Review Checklist Performance How does it map to the performance curve? Does it negatively impact other areas, such as landing pages? What is the expected longevity test needs? What is the expected capacity test needs? Is there minimum use of system resources, including memory and execution time? Does the design facilitate a perceived quick response to user actions? Is the most critical information relayed back to the user first? Is asynchronous processing effectively used to improve performance? Are there any potential sources of bottlenecks in the system? Is caching being utilized appropriately? Are there any potential race conditions in the system? Failover What are the failover points? Will the feature as a whole require fault tolerance? What specific components of the feature need failover capabilities? What persistent state information is required to support failover? How will state be handled? Failure What are the failure points in the system? What is the expected user experience for each failure point? What is the expected system action for each failure point? Security From what channels is this feature accessible? What mechanism is used to secure the feature? Who has authority to use the feature? How will this authority be handed out?
  • 2. Robustness, Reliability, Exceptions, and Logging Is transaction logging going to a common place? Is clickstream logging going to a common place? Where is any other application logging going? What logging needs to be rolled up to the long-term reporting facility? What will be logged at each point? What will be rolled to the long-term reporting? How will the support team query the logs? Are resources appropriately released during errors and timeouts? Are all resources properly relinquished as soon as possible? Are resources held onto when they will be re-used? Does the system do sufficient data validation of input? Does the system properly handle unavailable resources? Does the system employ retry logic properly? Does the system recover from unexpected events? Does the design ensure that end users cannot carry out any incorrect actions in case of an error? Are exceptions being caught and reported at the appropriate / correct nested level? Does the design address generation of detailed debug/trace messages? Is all critical error information being logged? Are all necessary elements of a transaction being logged? Monitoring Who is expected to monitor the status of the system? Have transaction test pages/points been identified? How will the monitoring group be notified of failures? What is the escalation procedure for faults raised by this app? Physical Deployment What hardware will a transaction flow through during its lifetime? What is the capacity estimates for this feature? Will additional hardware be required to support this app? Have URL naming conventions been followed? Consistency and Reuse Is the design consistent with other aspects of the system? Are existing components re-used? Are design patterns being applied properly? Are components that have the strong potential of reuse being designed for reuse? Are components that “probably won’t be reused” being over-designed for reuse?
  • 3. Is there a clear separation of responsibilities between components? Manageability How will load balancing be performed? Does the system provide a “system health status check” capability? Does the system provide for graceful startup/shutdown capability? Does the system provide view and modify capability for application characteristics? Do the error conditions provide understandable messages with enough level of detail to specify the cause and action that should be taken? Have all utility program requirements been addressed? Simplicity Are Class & Interface names appropriate, easy to understand? Do any class hierarchies have unnecessary levels of inheritance? Are classes the “right size” (split apart or merged appropriately)? Are protocols/handshakes between systems simple and optimized? Are subsystems loosely coupled and adequately independent? Is the design flexible (can be modified as requirements change)? Is the design understandable and coherent? Are business rules clearly and truly separated from the display components (e.g. no rules in JSPs)? Miscellaneous Does the architecture address all roles? Have existing frameworks been leveraged? Does the design use and comply with the tools, technologies currently in use? Does the design meet all business requirements? Does the design account for backward compatibility? Does the design minimize impact to existing applications and infrastructure? Does the design consider packaging/dependency issues? Are any special security considerations adequately handled? Are any special deployment issues being considered? Are there any special fail-over considerations? Is the design adequately configurable for different environments (dev, prod, etc.)? Is the system testable? Have opportunities for testing & monitoring hooks been taken? Is it possible to isolate run-time problems? Is transaction scope adequately handled (i.e. something must be a two phase commit)? Are valid/invalid state transitions being considered (handle browser back button, bookmarks etc)?
  • 4. Does the design have/require a sufficient authentication system? Does the design have/require a scalable authorization system? Does the design take into account globalization compatibility?