Justification
The first argument to embrace the GDP principles is the aspect of requirements. When developing software, the strong concentration on requirements (e.g. typical for the waterfall model) causes excessive costs and reduced quality of the outcome, mainly due to the following reasons:
- Requirements are usually not identical with business objectives because of the author’s limited knowledge about technical possibilities and their costs – such requirements tend to include unnecessary expensive wishes while excluding technically simple features that would provide substantial benefit.
- Formalization of the supported business process during development usually reveals inconsistencies and gaps within that process which need to be compensated with changes to the process itself or to the role of the software system.
The result of these two effects is usually a large number of change requests during and after development (entailing time and cost overruns), therefore user involvement is considered to be a critical project success factor.
Secondly, while established software processes refine requirements down to an implementation, the Goal-driven Development Process recommends trying to find an optimal mapping between business objectives and capabilities of the technical platform in an iterative process, equally considering and adjusting business goals and technical aspects to come to an optimal, convergent solution.
Goal-driven development process allows stakeholders to:
- Discover use cases that are tailored to the requirements according to business goals
- Establish a bridge between goals and IT architecture
Read more about this topic: Goal-Driven Software Development Process