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

Definition

Capability of a product to be adapted to changes in its requirements, contexts of use, or system environment.

Note: Flexibility to context of use should consider two distinguished aspects, i.e. technical and non-technical. The technical aspect is related with the execution environment of products, such as software, hardware and communication facility; and the non-technical aspect is related with the social environment, such as user and task, and the physical environment, such as climate and nature.

ISO-25010:2023

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
User  
Product-Owner  
Management  
Developer  
Tester  
Admin  
Domain-Expert  
Others  

Qualities tagged with #flexible

Requirements tagged with #flexible