The Myths Of Requirements
Last updated: February 18, 2024 Read in fullscreen view
Recommended for you
- 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
- 12 Oct 2022 14 Common Reasons Software Projects Fail (And How To Avoid Them) 10/504
- 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
- 10 Dec 2021 What is a Kano Analysis? 6/810
- 28 Jul 2022 POC, Prototypes, Pilots and MVP: What Are the Differences? 6/606
- 06 Feb 2021 Why fail fast and learn fast? 6/375
- 13 Oct 2021 Outsourcing Software Development: MVP, Proof of Concept (POC) and Prototyping. Which is better? 6/424
- 01 Mar 2023 Bug Prioritization - What are the 5 levels of priority? 6/207
- 07 Oct 2025 Case Study: Using the “Messaging House” Framework to Build a Digital Transformation Roadmap 5/45
- 05 Mar 2021 How do you minimize risks when you outsource software development? 5/317
- 31 Aug 2022 What are the best practices for software contract negotiations? 5/215
- 12 Dec 2021 Zero Sum Games Agile vs. Waterfall Project Management Methods 4/374
- 04 Oct 2022 Which ERP implementation strategy is right for your business? 4/278
- 14 Oct 2021 Advantages and Disadvantages of Time and Material Contract (T&M) 4/789
- 18 Aug 2022 What are the consequences of poor requirements with software development projects? 3/242
- 01 Dec 2023 Laws of Project Management 3/249
- 18 Jul 2021 How To Ramp Up An Offshore Software Development Team Quickly 3/516
- 08 Oct 2022 KPI - The New Leadership 3/557
- 31 Oct 2021 Tips to Fail Fast With Outsourcing 3/375
- 05 Sep 2023 The Cold Start Problem: How to Start and Scale Network Effects 3/167
- 01 May 2024 Warren Buffett’s Golden Rule for Digital Transformation: Avoiding Tech Overload 2/188
- 23 Sep 2021 INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 2/411
- 28 Dec 2021 8 types of pricing models in software development outsourcing 2/417
- 28 Oct 2022 Build Operate Transfer (B.O.T) Model in Software Outsourcing 2/361
- 04 Oct 2021 Product Validation: The Key to Developing the Best Product Possible 2/295
- 10 Dec 2023 Pain points of User Acceptance Testing (UAT) 2/416
- 17 Feb 2022 Prioritizing Software Requirements with Kano Analysis 2/280
- 13 Dec 2020 Move fast, fail fast, fail-safe 2/292
- 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
- 19 Apr 2021 7 Most Common Time-Wasters For Software Development 1/525
- 12 Aug 2024 Understanding Google Analytics in Mumbai: A Beginner's Guide 1/84
- 15 Aug 2025 Quantum Technology: Global Challenges and Opportunities for Innovators /56
- 06 Mar 2024 [SemRush] What Are LSI Keywords & Why They Don‘t Matter /131
- 14 Mar 2024 Why should you opt for software localization from a professional agency? /117
- 12 Mar 2024 How do you create FOMO in software prospects? /127
- 19 Oct 2021 Software development life cycles /628
- 06 Nov 2019 How to Access Software Project Size? /236
- 10 Nov 2021 Automated QA Outsourcing – Hire a Professional Software Testing Team /514
- 02 Apr 2022 Productivity vs. Efficiency – What Are the Differences? /196
Myth: Knowing all info from requirement gathering.
Fact: This is a trap. The more you dig for all the information, the more time, energy, and money is burned without actually delivering any work. All the while, you will never figure it out anyways. There are things that can only be learned by doing. There are also things to be learned that only come from delivering some work and getting real feedback.
Myth: Requirements and Specifications are the same thing.
Fact: Requirement generally refers to a customer need while specification refers to a detailed, usually technical description of how that need will be met.
Myth: The statement of work (SOW) and Specifications are the same thing.
Fact: SOW defines all work (non-specification) performance requirements for a contractor. The statement of work outlines the goals,, timelines, deliverables, criteria, SLA, payment terms and other conditions for the acceptance and closure of the project.
Myth: We don’t need to have domain knowledge to write good requirements.
Fact: Do you want an accountant to write requirements for the bridge you’ll be crossing or a nurse to develop the specifications for the airplane you’ll be flying? Didn’t think so. Now you don’t have to be an expert in the domain but you do have to have some knowledge so that you can effectively communicate with your stakeholders as you elicit and document their requirements.
Myth: Use of conditional statements in requirements is poor requirements writing.
Fact: NOT TRUE that conditional requirements make poor requirements – of course there can be terrible conditional requirements but many requirements are incomplete without conditions.
Myth: We don’t need requirements because we sit side-by-side with the developer, we tell him or her what we want and the developer develops. Fast, easy, uncomplicated!!
Fact: How do you know when you are done? How do you confirm completeness? How are you going to test and maintain the system/product? How are you going to prove you have met stakeholder expectations? How are you going to manage change? No, you need a baselined set of requirements, trust us on this one!!
Myth: Requirements identified as low priority will never be delivered. Same for Wont-Have and To-Be-Defined (TBD) features.
Fact: Remember the quote "Enjoy the little things in life because one day you'll look back and realize they were the big things.” – Robert Brault.“
Myth: Proposing a big, one-size-fits-all platform will solve most pain points of customer.
Fact: According to Kano Analysis, many features won't delight the customers. They might expect a minimum viable system for their needs.
Myth: Developers just need the requirements, don’t burden them with any other information.
Fact: Can you read the requirements and be 100% sure you know what they mean? Probably not, and neither can the developers. Give them rationale for each requirement. Give them great scenarios (operational concepts) and help them understand the context of the requirements. They may be really smart but they still can’t read minds.
Myth: We don’t need to define requirements for COTS (Commercial off-the-Shelf) software packages because the system comes with all the features that a company or function needs.
Fact: You will need to define your requirements for COTS software just like you would for custom developed software. The requirements you define, irrespective of the solution, state what you need the system to do. If you are evaluating packages, these requirements serve as the evaluation criteria for software selection and the basis for the fit/gap analysis you will probably perform. These defined requirements will also serve as the starting point for determining viable alternatives to needed functionality in cases where there is an incomplete fit or no fit whatsoever. Furthermore, you need to define your requirements for purposes of localizing the package for language, culture, look and feel and configuring for business settings and rules.
Myth: Craft a comprehensive product requirements all in one formal document.
Fact: Adding too much additional information would make the requirement spec or backlog overcrowded and difficult to understand. The best way to handle the additional information you want to add to each requirement is progressive disclosure. Include a link that people can follow if they want to know more. Let them explore as deep as they need to. It’s important to offer context, data and testing information on each requirement – it’s just a matter of making sure it’s not overwhelming.
Best Practice: Make sure the information is complete, but avoid being overwhelming.
Do you have a “requirement” question you would like the Requirements Experts team to address? If so, please visit www.tigosolutions.com and contact us via info@tigosolutions.com.
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!