Software Requirements Are A Communication Problem
Especially when you add into that equation the level of detail that’s needed to capture the requirements for a major software application.
And then there’s the complexity of software. And the fact it’s plyable. Its evolutionary nature means it simply isn’t comparable to the creation of many other products. And certainly not comparable to construction projects, where once built the requirements are literally fixed in stone.
Software requirements, therefore, are a uniquely challenging communication problem. Such a challenging problem, we mustn’t kid ourselves into thinking there’s a solution. Personally, I am pretty sure there is not.
However, there are ways of mitigating some of the problems, whether it’s in written or verbal form. Let’s look at some of the pros and cons of each…
–can be well thought through, reviewed and edited
–provide a permanent record
–are more easily share with groups of people
–time consuming to produce
–may be less relevant or superseded over time
–can be easily misinterpreted
–provide opportunity for instantaneous feedback and clarification
–are an information-packed exchange
–can be easier to clarify and gain common understanding
–are more easily adapted to any new information known at the time
–can spark ideas about problems and opportunities
–are spur-of-the-moment and not always well thought through
–are harder to share across groups of people, particularly if not co-located
–conversations can be remembered differently by different people
Whichever form of requirements capture you prefer, we must all remember the old addage: “A picture is worth a thousand words”. It’s so true. Whether it’s a diagram in a spec, or a sketch on a whiteboard, pictures add a dimension that is immensely valuable.
And some key principles of agile development seek to address some of the weaknesses of both forms of communication, in an effort to create a best of both worlds:
- Active user involvement to ensure continuous visibility and feedback
- Agile teams must be empowered to make decisions, so details can be clarified at the time of development
- An acceptance that requirements emerge and evolve as the software is developed
- Agile requirements are ‘barely sufficient’, so they are not too onerous to produce and the latest information can be incorporated at the time of development
- Requirements are developed in small bite-sized pieces, so details can be captured verbally whilst minimising the risks of people forgetting details or not being involved when the requirements are developed
- Enough’s enough – apply the 80/20 rule; capturing every detail isn’t necessary to produce a quality product; verbal clarification, visible software and feedback works better
- Cooperation, collaboration and communication is essential between all team members, as everyone involved must know the outcome of any discussions about requirements.