Written requirements in the age of agile development

Many of today’s agile software projects are characterized by a lack of written requirements and other documentation. The rationale behind this is that requirements change “too often” to be written down. Project management might also be afraid that writing documents consumes too much time of developers and stakeholders. However, my personal experience is that projects with clearly defined and written requirements run much smoother and have less delays. Written documents are forcing developers to think and clarify open issues before they start coding. Sprint planning meetings tend to be shorter as well.

The June 2013 issue of Communications of the ACM contains an insightful article about the lessons learned during Space Shuttle software development at NASA:

A common excuse used today for not writing requirements first is that the requirements are “unknown” or may change. In fact, in these cases, it is even more important to put major effort into upfront requirements analysis and specification. The software requirements for the Shuttle were continually evolving and changing, even after the system became operational and throughout its 30-year lifetime. NASA and its contractors made over 2,000 requirements changes between 1975 and the first flight in 1981. After the first flight, requirements changes continued. The number of changes proposed and implemented required a strict process to be used or chaos would have resulted.

Learning from the past to Face the risks of today, Nancy G. Leveson, Communications of The ACM, June 2013

Other important recommendations include:

  • Verification must be thorough and proceed through a sequence of steps without skipping any or being rushed to try to save time (“there is no time to save time”).
  • Experienced personnel should be assigned to a project early, rather than using the start of a project for training inexperienced personnel.
  • Software should not be declared complete in order to meet schedules, requiring users to work around errors. Instead, quality should be the primary consideration.
  • Quality cannot be added after the software is written.
  • Contractors should be closely managed. Commercial projects often use outsourcing and subcontracting without careful and detailed oversight of the process.

Note that these recommendations are independent of the management technique being used. Scrum, for example, can not replace solid engineering practices. Agile development requires even more rigor than traditional processes. Otherwise, incomplete implementation of requirements, structural inefficiency and avoidable bugs are the result.