Easy to:

  • change to new or modified requirements
  • bring into a new or modified execution environment (e.g. new hardware, operating system or cloud provider)
  • handle changed workload


Capability of a product to serve a different or expanded set of requirements or contexts of use; or the ease with which the product can be adapted to changes in its requirements, contexts of use, or system environment


Typical Acceptance Criteria

Flexible, as we saw above, means “adaptable to change”.

When defining what exactly #flexible shall mean for a specific system and specific stakeholders, we need to consider the following questions:

  • what type of change (e.g. changed functionality, changed quality requirements, changed workload, changed infrastructure)
  • when does this change occur or when do people want to respond to the changes: at development-, compile/build-, installation-, startup- or runtime?

Typical acceptance criteria might include:

  • Effort or number/types of changed artifacts to handle changes
  • Time or money spent for such changes
  • Side-effects on other system properties

Scenario Response Measures from [Bass et al.]

Cost in terms of

  • Number, size, complexity of affected artifacts
  • Effort
  • Elapsed time
  • Money
  • Extent to which this modification affects other quality attributes
  • New defects introduced

Bass et al., 2021

flexible for Stakeholders

Stakeholder (potential) Expectation for flexible

Qualities tagged with #flexible

Requirements tagged with #flexible