Dealing with Requirements

To show the importance of requirements, we will first refer to the definition of quality according to ISO 9000 from 2005:

Quality is the totality of features of an entity regarding its suitability to fulfill specified and given requirements.

Quality is therefore to achieve what has previously been defined. This definition shows us how important requirements analysis and requirements documentation are. So, we now have some challenges in the documentation of requirements. They are to make sure that what “was wanted” is implemented as a system. It is precisely this that is often not achieved in projects.

Since 1995, the Standish Group examined a large number of IT projects over a period of around two years. The study is called “Chaos Report” and should detect factors which bring projects to a successful conclusion.

Diagram 7 originates from the “Chaos Report” and gives an overview of the factors of successful and unsuccessful projects.

Overview of successful and unsuccessful projects (“Chaos Report”)

Diagram 7: Overview of successful and unsuccessful projects (“Chaos Report”)

It is clearly visible that the success rate has stagnated since 1996 by more or less 30%. This means that despite knowing the success factors, not more projects have been successful.

Also, the company PA Consulting and the Association for Project Management have been conducting annual studies on the subject of success factors since 2004. Diagram 8 illustrates the reasons that make companies accountable for the failure of projects.

Reasons for the failure of projects

Diagram 8: Reasons for the failure of projects

This study illustrates the importance of clear requirements for projects. To meet this demand, it must be ensured through requirements analysis and requirements documentation that all of the important requirements for the project are located and recorded with the quality necessary for the project.

Since not all requirements are always known or are not formulated in detail at the beginning of a project, there are various ways to respond to this. For this reason, different procedure models have been developed.

The following cartoon illustrates the handling of requirements in the IT market in the year 2000.

Handling of requirements in the IT market

Diagram 9: Handling of requirements in the IT market (2000) (Source: http://www.uidesign.at/journal/2007/05/16/die-anforderungen-der-nutzer-verstehen/)

Here it is necessary to distinguish whether or not the requirements are clear at the beginning and initially “only” have to be documented, or whether they are still unclear and will emerge at a later date.

Requirements that are clearly available to the requirements actuator must correspond to some kind of quality criteria (compare section Quality Criteria according to IEEE 830 up to INVEST-characteristics according to Cohn) so that they can reach the development team in a clear and comprehensible manner. With this in mind, particularly in agile processes, it is important to convey the requirements not only on paper, but also to communicate them clearly to the team. The documentation can then support the development appropriately.