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.

1. 1

   Mission

   Lean Mission Statement: clarify purpose

   

   Goal

   A shared view of the software’s value gives the review direction.

   Inputs for this step

   • System context
   • Product perspective and system knowledge

   Actions

   • Name the system and the parts you will examine. Also record which areas fall outside the review’s scope.
   • Collect claims about benefits, important capabilities and expectations, as if introducing the software on a short product page.
   • Summarize the purpose in three or four key statements and agree them with the participants.

   Output

   Lean Mission Statement with review boundaries

   The key statements guide the quality goals in the next step.

   Quality check

   Do the key statements describe the intended value of the software?

   Pitfall

   The team starts with a technology list and no shared purpose. Describe the intended value and agree which parts of the software you will examine.

   Timing: Short joint clarification block.

2. 2

   Criteria

   Evaluation Criteria: set quality goals

   

   Goal

   Quality goals provide a shared assessment benchmark.

   Inputs for this step

   • Mission Statement
   • Stakeholder expectations

   Actions

   • Choose three to five quality attributes that support the intended value, such as availability or security. Use the LASR quality cards if helpful.
   • Use concrete examples to describe what the software should achieve. Agree a scale and target values.
   • Plot the target values in a spider chart. Each axis represents a quality attribute. Record what the values on each axis mean.

   Output

   Quality goals and target profile

   Add the specific meaning of the scale values for your software to the chart.

   Quality check

   Is it clear what the target values mean for this software?

   Pitfall

   Every goal receives the highest level without justification. Connect goals to concrete expectations and state deliberate priorities.

   Timing: Joint assessment block.

3. 3

   Risks

   Risk-based Review: assess risks

   

   Goal

   You identify which risks could threaten the quality goals.

   Inputs for this step

   • Target profile
   • System experience
   • LASR risk cards if useful

   Actions

   • Imagine a future failure of the software and collect possible causes. Add system-specific risks to the LASR risk cards.
   • Map the risks to quality goals. Assess how likely they are and how serious their effects would be. Explain the scales you use.
   • Use the risks to assess where the software might fall short of its goals. Plot this assessed state alongside the target values. Record assumptions and differences of opinion.

   Output

   Initial risk and gap profile with uncertainties

   Link each estimated gap to the risks and assumptions behind it.

   Quality check

   Does each gap show which risks support the assessment?

   Pitfall

   The diagram is presented as measured system quality. Label values as assessments and link them to risks and rationale.

   Timing: The main part of the initial joint assessment.

4. 4

   Analyze

   Quality-focused Analysis: investigate further

   

   Goal

   Focused analysis clarifies how well unusual assessments are supported.

   Inputs for this step

   • Initial gap profile
   • Architecture knowledge and available evidence

   Actions

   • Select quality attributes where assessments differ or gaps seem surprisingly large, small or absent.
   • Describe more precisely what the software should achieve for these attributes. Investigate risks and causes using architecture knowledge and available evidence. Record the results of this qualitative analysis.
   • Update the gap profile and explain each change. Also check where the software exceeds requirements and whether this harms other quality goals.
   • Assign owners for the measurements, experiments or specialist checks needed. Mark the evidence still to collect.

   Output

   Refined gap profile and focused follow-up checks

   Record why an assessment changed and which questions still need checking.

   Quality check

   Are profile changes justified and remaining uncertainties named?

   Pitfall

   The team votes again on a disputed assessment without investigating its causes. Investigate the expectations and possible causes. Use the findings to reassess the gap.

   Timing: Plan separately according to analysis needs.