A software product commission can be described as follows: The customer has wishes and needs (requirements) that the contractor satisfies using a software solution, within the given framework for time and costs.
Traditionally, software development focused on the adherence to deadlines and budgets, and not on ensuring that the customer requirements were actually met. Countless memes make fun of the fact that software products do not meet the customer’s requirements. The cartoon with the tire swing is very famous, but less well-known is the fact that this cartoon is from the year 1973.
Source: https://knowyourmeme.com/photos/475752-tree-swing-cartoon-parodies
Fifty years later, software development still occasionally struggles with this same problem. Why is that?
The assembly line
Classical software development procedures, such as the waterfall model, plan a process like an assembly line. With the requirements, the ordering customer provides a clear outline of what they expect from the product. In the waterfall model, this is referred to as a “requirements specification.” The contractor analyzes these requirements and a creates solution concept (“functional specification”), in other words, a description of how they will implement the requirements.
Once the ordering customer’s functional specification is accepted, the contractor proceeds with the implementation, which the solution concept takes as a blueprint, and implements the components described within it. These are tested against the solution concept. Once all the defects have been removed, the finished product is delivered.
Satisfying the customer’s wishes and needs can be tracked using a chain of evidence. Every function in code can ultimately be traced back to a requirement in the functional specification, and this has indeed been communicated. So what can go wrong?
Experience has shown that this procedure has many problems: Requirements change over the course of time; time and expenses cannot be reliably estimated at the beginning of the project; the product is only delivered at the end of the project, and only then can the customer determine if it corresponds to what they have had in mind, etc. Many problems can be attributed to the procedure model’s lack of flexibility, though an often-overlooked cause is miscommunication throughout the process.
This is because even if the customer knows exactly what the requirements are at the beginning, it is not guaranteed that all parties concerned understand them the same way. The reason for this is…
The telephone game
Central to the traditional procedures is documentation. As with series production, the work products – requirements specification, functional specification, detailed plans, test cases, etc. – are sent from one work space to the next. Communication is done sparingly and only between stations that are directly adjacent to one another.
Information is lost with every interaction. Important information can be distorted or not even arrive. Often, the developers do not even receive input on the customer’s perspective, thus contributing to the danger that the functionalities will not be implemented in accordance with the customer’s requirements.
The most direct route
Agile software development prioritizes communication. A requirement can only be successfully implemented according to agile principles if a common understanding prevails with respect to what exactly this requirement means. This is why according to the Manifest für agile Softwareentwicklung (2001) (“Manifesto for Agile Software Development”) “individuals and interactions” are “more valued than processes and tools.”
Agile methods such as Scrum usually describe the requirements utilizing user stories. A user story is primarily a placeholder for communication: it emerges in a raw form as a general explanation of what a user of the system wants or needs, and is continuously refined during the agile process.
What this specifically means is that the development team can directly discuss its questions and concerns with the customers, specialist contact persons, and end users. This way, the customer perspective is always included.
As a result, communication occurs frequently, and in a way that is both open and non-linear. This facilitates a common understanding of the requirements. The insights gained through this communication are included in the user story and form the basis for their implementation. In doing so, one must take care that they are precisely formulated so that misunderstandings are avoided.
A proven method for achieving this is acceptance criteria.
Structured requirements
Acceptance criteria are conditions that have to be fulfilled through their implementation. This is so that a user story can be successfully concluded. They describe testable properties of the required functionality that can be reviewed during the acceptance phase. For this reason, they are also known as “acceptance criteria.”
They form the link between user stories and test cases. Even before development, test cases that can be used to verify the accuracy and completeness of the implementation can be derived from the acceptance criteria. These test cases also contribute to the common understanding of the requirement.
As a result, acceptance criteria help with adhering to the understanding that is achieved through refinement. This is done by checking during and upon conclusion of development whether the understanding meets the requirement.
To this end, acceptance criteria must be assessable, value-generating and testable. In other words, they describe small but functional conditions that give the customer an added value and are so precisely formulated that they can be verified through tests.
Communication Must Occupy Center Stage
A software product can only be successfully completed if the customer’s wishes and needs are satisfied. In order to assure this, a common understanding of these wishes and needs must prevail.
Experience has shown that a documentation-based procedure does not achieve this understanding: Communication must occupy center stage, and agile methods are best suited for this. The use of acceptance criteria in the description and refining of user stories is an instrument from the agile toolbox that has proven successful in achieving a common understanding of requirements and expressing this in a testable form.
