Introduction
Requirements managers, project managers, and business analysts will find the most interest in this article. Developers will find a nice challenge at the end. 🙂 In this article, I attempt to show that written requirements are no longer necessary….and a new tool, using new media….is necessary.
Why did written requirements fail us?
Requirements gathering, analysis and management has never been easy. It’s hard work filled with nuance, half-truths, mis-interpretations, ulterior motives, impressions, imagination, emotion and misunderstanding. It’s vision crafting.
Getting everyone on the same page to a clear and sufficiently detailed model of the proposed system requires a conductor with the right skills. Too critical to be ignored, a lack of depth in this area can doom a project.
To help codify that vision the software industry quickly turned to documentation and documentation standards. But, written requirements have proven to be an inadequate fit with the abstract nature of software and these flaws became apparent:
- “That’s not how I read it”
- Versioning Changes
- Big complex software = big complex requirements = never read/hardly understood
It was realized by a myriad of software professionals that relying exclusively on the documents and omitting en
gaged conversations to clarify the written word was a mistake. But….spoken requirements and conversations have these flaws:
- “That’s not what I heard or understood. That’s not what I remember.
- Hallway conversations, informal clarifications that aren’t heard by all parties.
- Complex requirements can’t easily be remembered, conveyed through conversation alone.
- Change management is non-existent.
User stories attempt to blend the spoken and written worlds and emphasize the continuous interaction between customer and software development team. They rightfully restored the need for conversations and engaged business domain involvement and got us away from the never ending refinement or versioned requirements books. They get us closer to where we need to be. But, they still miss the mark. Some flaws of user stories and their crafting are becoming apparent:
- Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
- An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
- It’s a fine line. How much to write? How much to discuss? Too little and the story is worthless. Too much and we’re back to writing all our requirements.
- Complex business domains and logic need to be documented in detail. A simple story ( or many simple stories ) with acceptance criteria may not be enough. Think about requirements for the Boeing 787 flight control system.
- User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
Where are we headed?
With the proliferation of digital video, cell phone cameras, webinars, social media, and whiteboards we have a new set of building blocks to create the 21st century requirements management tool. And that is my challenge to the community. Build it. Use these pieces to create a new tool for managing requirements that further reduces the risk of interpretation. Here are some advantages I see:
- The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
- Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
- Whiteboarded artifacts could easily be recorded and saved along with the video. Adding to a thorough documentation of the conversation.
- While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
- Productivity in requirements gathering and recording could potentially jump helping out the entire software development process.
If you feel you’re up to the challenge…:)….then contact me ( chris@effectivelogic.biz ) and I’ll give you further guidance requirements.
About the Author
Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager throughout his career. Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.
Pragilematic 
Pingback: Agile or Waterfall — Aren’t We Just Struggling With Requirements Understanding? « An Agile Story
Pingback: Requirements Documentaries – A Recipe « An Agile Story
I think you may be looking for technology to solve what is a human process problem. I am in the business of facilitating requirements discovery sessions with groups of managers and domain experts. A few of our ‘rules’ have to do with gaining consensus and avoiding side-bars. The result is is indeed a set of written functional requirements, reviewed and owned by the group. In order to gain that consensus, one thing we do is NOT record who said what, it is the group “voice” we want. We have also found that most people have an aversion to being recorded in these sessions, sound or video; the ability to be verified or challenged later immediately reduces the level of involvement in the sessions, with a much poorer result. … effective facilitation of requirements discovery will still trump technology for now, I think.
Hi David,
Thanks for the insightful comments. You make some very salient points. Would people be less open in front of a camera….less willing to disclose their ideas? I think the natural answer today is ‘yes’. But is that going to be true for the generations coming up? The ones who’ve grown up with digital video as a part of normal communication?
That’s where my article is focused…the future. I’m camera shy myself and it will take some time for me to be completely comfortable with requirements documentaries. But perhaps that’s a growth point.
Take care. 🙂