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.