Description

It’s of the uttermost importance to clarify the expectations and assumption of all stakeholders of a software system. There may be conflicting interests or hidden doubts among the project’s participants that could let any improvement activity fail severely. Clear goals and understandable constraints are a great way to set the direction and the rules of the game.

Goals of improvements activities can be manifold. E. g. a goal could be to make sure that the software system gets more understandable. Another goal could be to be able to add new features or capabilities more easily in the future.

Goals are restricted by constraints. Because we live in a world with finite resources, we have to work with what we have in our (project) environment. E. g. constraints could be certain finish dates, organizational or technical limitations.

Representation

  • Quality scenarios are a good way to align business’ goals with the actual technical requirements and constraints.
  • Architecture decisions contain information about goals and constraints that led to a certain decision.
  • Architecture Decision Records contain the problem statements (=goals) and the drivers (=constraints) that lead to a certain decision.
  • Impact Mapping is another nice methodology to trace goals (=Why?) over constraints (=How?) to the actual implementation (=What?).

References