Architecture Analysis method
Clarifies quality goals, assesses risks and investigates important questions about the software.
LASR by Stefan Toth and Stefan Zörner guides a software review through four steps. First, the team clarifies the software’s purpose and sets quality goals such as availability or modifiability. Risks are then assessed. A gap profile shows where the assessed system state falls short of the goals. Unusual or disputed assessments are investigated in more detail.
How well does our software meet its quality goals, and which risks should we investigate further?
The first three steps provide a reasoned assessment. In the fourth, you investigate unusual findings about quality attributes. Additional measurements and tests provide the technical evidence still needed.
Mission
Describe the value the software should provide and which parts you will examine.
Criteria
Translate the system’s purpose into a few important quality goals and a shared target profile.
Risks
Collect possible causes of problems and assess their effects on the quality goals.
Analyze
Investigate selected quality attributes further and update the profile using the findings.
Update risks and the gap profile after each deeper analysis. Repeat the review after significant changes to the system or its quality goals.
For development teams that know their software and want to clarify its main quality risks together. You can also use LASR on your own. Record which assumptions and perspectives you want to check with others afterwards.
An overview of quality goals, the assessed state of the system and justified gaps.
Findings about the risks investigated, their causes and remaining questions.
Fictional teaching example
A document template to accompany the LASR result chart. A separate fictional example shows a portal review.
Record the system, scope and three or four key statements about its value.
B2B portal: accept orders reliably; partner adapter included, ERP excluded.
Document three to five quality attributes, expectations, scales and a link to the target profile.
Availability, modifiability, security; the portal should accept orders during a partner outage.
Map risks to quality goals. Record likelihood, effects and uncertainty, and link them to the gap profile.
Order acceptance may have to wait for the partner’s response; team assessment, with a technical check still needed.
Record the quality attribute investigated, precise expectations, causes, findings and profile changes.
Flow analysis shows that order acceptance waits for the partner. The team adds a justified availability gap.
Record further checks and possible improvements with owners. Add the results to the profile later.
Plan an outage test; investigate a queue to hold orders; test effectiveness after implementation.
The example illustrates the method using invented information.
Define the system you will review and its purpose. Invite people who know the software and its development well.
LASR helps development teams identify where their software falls short of important quality goals and which improvements to consider. A small group with existing system knowledge can make an initial assessment and investigate open questions in more detail.
Summarize the software’s purpose in a Lean Mission Statement. Derive the most important quality goals and evaluation criteria: the Evaluation Criteria step. Identify and assess risks in the Risk-based Review. Compare the targets and the estimated current state in the results diagram. Examine notable or disputed assessments through Quality-focused Analysis and update the profile.
LASR can be performed alone or in a small team. Three or four people who know the system well are particularly suitable. Product owners help clarify the software’s purpose and quality goals in the first two steps. The results diagram shows targets and estimated gaps. Its values reflect qualitative judgments. In the fourth step, the team examines disputed or implausible assessments more closely: What quality is expected, what risks exist, and what might cause them? This work may require further meetings. Plan any needed code analyses or runtime measurements as additional investigations and document their results separately.
Clarify the reason for the review and arrange access to system knowledge and documents. Define a few quality goals that matter to the business. Support each judgment with observations or assumptions. Use differing assessments to investigate open questions in more detail. When working alone, record which perspectives are still missing and seek them out. Finish with an updated quality profile and assign owners to open investigations.
The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.
Open method guideYour perspective
Your feedback helps shape the next improvements to methodatlas.
Plan an initial assessment. Use the gap profile to select deeper analyses and allow time for them.
To be confirmed
To be confirmed
Entire review Time: An initial assessment often takes a few hours or half a day. Allow additional time for the deeper analyses you select.
Complete this worksheet on paper or in your own document during the work.
Record the system, scope and three or four key statements about its value.
...
Document three to five quality attributes, expectations, scales and a link to the target profile.
...
Map risks to quality goals. Record likelihood, effects and uncertainty, and link them to the gap profile.
...
Record the quality attribute investigated, precise expectations, causes, findings and profile changes.
...
Record further checks and possible improvements with owners. Add the results to the profile later.
...
Add actual information and evidence. Mark unresolved items explicitly.
Expected artifact: Lean Mission Statement with review boundaries
The key statements guide the quality goals in the next step.
Entry:
...
Expected artifact: Quality goals and target profile
Add the specific meaning of the scale values for your software to the chart.
Entry:
...
Expected artifact: Initial risk and gap profile with uncertainties
Link each estimated gap to the risks and assumptions behind it.
Entry:
...
Expected artifact: Refined gap profile and focused follow-up checks
Record why an assessment changed and which questions still need checking.
Entry:
...
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/lasr/run-sheet
Fitting alternatives with decision guidance, followed by other related methods.
Choose ATAM for an evaluation across several phases with broad participation that explicitly examines sensitive architecture decisions and trade-offs.
Uses concrete tasks to show how well an architecture supports use and change.
Documents an architecture decision with context, alternatives, and consequences so later reviews remain traceable.
Gathers system goals, constraints, and building blocks into a compact view for early architecture decisions.
Moves architecture context, options, and consequences toward a concrete result through "place the architecture diagram or plan in the center", "set risk categories such as technical, organizational, and external", and "assign an owner and next steps for each top risk".
Prepares stakeholders, core messages, and artifacts so architecture communication connects deliberately.
