We keep talking and writing blog posts, recording podcasts, and publishing an edition of this magazine dedicated to requirements because most software engineers and managers have a conflicting relationship with them. Engineers and managers will complain that writing requirements down (even in small cards) is against the ethos of Agile (spoiler alert: it is not), while the same engineers and managers will blame project failure to, guess what? Insufficient or incomplete requirements. Shocker.
Let us see what some authors have to say about requirements gathering.
Ian Sommerville’s “Software Engineering” textbook dedicates a section to requirements gathering, establishing a counterpoint between extremes. On one corner, we have IEEE/ANSI 830/1998, the heavyweight champion in the requirements category. We have Kent Beck’s agile cards and flyweight category champion on the other corner. Let the match begin!
Fred Brooks’ is very clear on page 199 of his classic book “The Mythical Man-Month”:
The hardest single part of building software is deciding what to build.
So much for opening Visual Studio Code and having GitHub copilot write code for us right away, damn.
Steve McConnell not only agrees with Fred Brooks’ assessment (page 113 of “Software Project Survival Guide”) but also talks about requirements gathering on page 25 of “Code Complete”–that is, really, really, really at the beginning of the 900 pages volume. According to him, gathering requirements reduces project risk. The risk of what? The risk of failure, of course, which in software engineering has been a rampant and pervasive problem since, well, always.
Software quality screams for requirements:
Software quality is a complex and widely studied topic, but it is not hard to provide a simple definition: quality means that the software does the right things, and does them right. These “things” that a software system does are known as its requirements. Not surprisingly, requirements engineering is a core area of software engineering.
(Bruel, Jean-Michel, Sophie Ebersold, Florian Galinier, Alexandr Naumchev, Manuel Mazzara, and Bertrand Meyer. 2020. “The Role of Formalism in System Requirements (Full Version).” ArXiv:1911.02564 [Cs], April. http://arxiv.org/abs/1911.02564.)
Speaking about Monsieur Meyer, he explained in his book “Agile!” that the agile school rejects the idea of upfront requirements, which leads to downright professional malpractice (page 34) fueled by one critical component of ninja-intensive teams:
The problem here is dogmatism.
Last but not least, let us not forget that “have a spec” is point 7 in the 22-year-old Joel Test.
Why are requirements so necessary? And why is it that so few software practitioners take the time to get them right? Why do teams not write requirements down?
As with many other things in our industry, there are many options between the IEEE standard and Kent Beck. Let us mention two of them, both in the Pragmatic Bookshelf. “Domain Modeling Made Functional” by Scott Wlaschin advocates using the F# programming language to gather and document requirements and turn them into a solid foundation for the final implementation. If F# is not your cup of tea, maybe Ruby is? In that case, for the past 15 years, the various editions of “Agile Web Development with Rails” by Sam Ruby, Dave Thomas, and David Heinemeier Hansson have always included a walkthrough describing the interaction with a fictional customer, leading to the creation of a new software product. The idea behind both books is the realization that spending time thinking about the problem is not a sin committed against a holy Agile Manifesto.
Both Meyer & McConnell agree on a critical misconception of our industry: there is no conflict between “being agile” and gathering and documenting requirements. As pointed out by McConnell, the issue is not to have fewer requirements but to defer them to a later stage of the process when the cone of uncertainty of your project starts shrinking.
Being an engineer requires the evaluation of all forces in a project to find the proper solution for the problem at hand. Requirements are a significant step towards adequate software engineering. Before going down the dogma drain, we should consider if cards are better suited for your project than the IEEE standard. Requirements can take various forms, and your project deserves at least one of them at any given time.
Cover photo by Markus Winkler on Unsplash.
