Software Requirements Are A Communication Problem
Last updated: November 24, 2023 Read in fullscreen view
Recommended for you
- 15 Feb 2024
What is a Cut-Over in Software Development? 38/1197 - 02 Nov 2023 Differences between software walkthrough, review, and inspection 27/2004
- 18 Oct 2020 How to use the "Knowns" and "Unknowns" technique to manage assumptions 21/989
- 01 Oct 2020 Fail fast, learn faster with Agile methodology 13/973
- 19 Oct 2021 Is gold plating good or bad in project management? 7/754
- 10 Nov 2022 Poor Code Indicators and How to Improve Your Code? 7/213
- 01 Feb 2024 How long does it take to develop software? 6/210
- 01 Mar 2023 Bug Prioritization - What are the 5 levels of priority? 6/207
- 01 Sep 2022 Facts Chart: Why Do Software Projects Fail? 6/540
- 06 Feb 2021 Why fail fast and learn fast? 6/375
- 08 Nov 2022 4 tips for meeting tough deadlines when outsourcing projects to software vendor 6/254
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M) 4/789
- 06 Mar 2021 4 things you need to do before getting an accurate quote for your software development 4/615
- 08 Oct 2022 KPI - The New Leadership 3/557
- 31 Oct 2021 Tips to Fail Fast With Outsourcing 3/375
- 16 Apr 2021 Insightful Business Technology Consulting at TIGO 3/376
- 18 Aug 2022 What are the consequences of poor requirements with software development projects? 3/242
- 09 Mar 2022 Consultant Implementation Pricing 3/184
- 16 Feb 2021 Choose Outsourcing for Your Non Disclosure Agreement (NDA) 3/150
- 02 May 2022 What Is RAID in Project Management? (With Pros and Cons) 2/734
- 10 Apr 2021 RFP vs POC: Why the proof of concept is replacing the request for proposal 2/254
- 23 Sep 2021 INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 2/411
- 07 Jul 2021 The 5 Levels of IT Help Desk Support 2/380
- 17 Feb 2022 Prioritizing Software Requirements with Kano Analysis 2/280
- 28 Dec 2021 8 types of pricing models in software development outsourcing 2/417
- 13 Dec 2020 Move fast, fail fast, fail-safe 2/292
- 10 Dec 2023 Pain points of User Acceptance Testing (UAT) 2/416
- 07 Oct 2022 Digital Transformation: Become a Technology Powerhouse 1/216
- 01 May 2023 CTO Interview Questions 1/296
- 19 Apr 2021 7 Most Common Time-Wasters For Software Development 1/525
- 09 Feb 2023 The Challenge of Fixed-Bid Software Projects 1/191
- 30 Oct 2022 How Much Does MVP Development Cost in 2023? 1/170
- 26 Dec 2023 Improving Meeting Effectiveness Through the Six Thinking Hats 1/205
- 05 Jan 2024 Easy ASANA tips & tricks for you and your team 1/180
- 11 Jan 2024 What are the Benefits and Limitations of Augmented Intelligence? 1/434
- 14 Mar 2024 Why should you opt for software localization from a professional agency? /117
- 01 Mar 2023 How do you deal with disputes and conflicts that may arise during a software consulting project? /145
- 09 Jan 2022 How to Bridge the Gap Between Business and IT? /163
- 06 Nov 2019 How to Access Software Project Size? /236
- 07 Aug 2022 Things to Consider When Choosing a Technology Partner /249
- 03 Nov 2022 Top questions and answers you must know before ask for software outsourcing /264
- 12 Mar 2024 How do you create FOMO in software prospects? /127
- 17 Mar 2025 IT Consultants in Digital Transformation /62
- 10 Jul 2025 Building AI-Driven Knowledge Graphs from Unstructured Data /111
- 21 Oct 2025 Cloud-Native Development: Why It’s the Future of Enterprise IT /40
Let’s face it. There is no perfect solution. No perfect solution for humans to share information accurately, consistently between multiple people, and over a prolonged period of time.
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…
Written Requirements
- Can be well thought through, reviewed and edited
- Provide a permanent record
- Are more easily share with groups of people
But, are:
- Time consuming to produce
- May be less relevant or superseded over time
- Can be easily misinterpreted
Verbal Requirements
- 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
But:
- 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.
The approach of User Stories seeks to combine the strengths of written and verbal communication, supported by a picture where possible. See here for an example of a User Story Card.
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.
Kelly.
Explore more on these topics
04102024050214_thumb.jpg)
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News