Procedure models are fixed sequences of activity to implement projects. Three different procedure models are described in this chapter with a focus on the handling of requirements. Initially, the strictly regulated Waterfall Model is presented as an extreme example of the classic methods. As an extreme example of the agile methods, the approach of Extreme Programming (XP) is subsequently highlighted. Scrum represents a certain compromise and is presented as the third example in the chapter Introduction to Scrum.
Software must be implemented in development projects in ever shorter time periods with an increasing number of requirements; the requirements for quality are thus continually increasing. To achieve the required quality in software, organizational frameworks are necessary. An organizational framework is described by a process model with the following features:
Literature distinguishes between the two different types of approaches: the classic methods and the agile methods.
The classic methods include procedure models which deal with more sequential project phases and collectively organize the over-abundance of documents. In this context it means the methods “Waterfall”, “Spiral Model”, “Rational Unified Process” (RUP) and “V-Model”. They all divide projects into stages in which certain results are achieved. Some implement these stages once and others repeat them. All of them classify activities in phases.
In the Waterfall Model, all requirements are formulated at the beginning and all subsequent phases are based on these requirements. Each change therefore means returning to the previous phase.
Diagram 1, from the year 2002, reflects the costs incurred if necessary requirements are detected in the late stages of the Waterfall Model. The cost of the changes then increases exponentially.
Diagram 1: Cost of change for the classic approach
Classic methods describe how something should be done during a project; what exactly must be recorded in which document and when, in order to develop the software. Compared with agile methods, the customer only has insight into the implementation at a late stage, meaning that even from the outset there is the risk that the formulated requirements do not correspond with what the customer had envisioned. Classic methods attempt to minimize this risk through specified documents and rules of action. They focus on achieving the greatest possible predictability of the project right from the start.
Diagram 2 illustrates the costs that emerge from changes in projects with agile procedural methodology. Change costs increase steadily in line with the duration of the project.
Diagram 2: Cost of change for the agile approach
Agile methods focus on being able to react quickly to events. In terms of requirements management, it shows that agile methods basically specify no documentation. Formulated here is the “what” not “how” something should be carried out. New requirements and the change of requirements are welcome at any time, as is described in one of the fundamental principles of the agile manifesto: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”.