by Cheryl Hill, PMP
Sometimes I think that requirement-related myths are more numerous than those related to Yeti, UFOs and the Chupacabra combined. So, let’s dispel some of the more popular myths that have absolutely no basis in fact.
Fact: NOT TRUE that conditional requirements make poor requirements – of course there can be terrible conditional requirements but many requirements are incomplete without conditions.
Fact: Oh no no no no…a Requirement is a statement of one thing a product or system must do or a quality it must have. A Requirement Specification is a collection of the set of all requirements that are to be imposed on the design and verification of a product or system.
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.
Fact: When someone says this, listen closely. Hear any bitterness in their voice??!! Now for the straight scoop – the synonym for “low priority” is NOT “ignore”!! Unless a waiver is received, all shall statements are binding and must be delivered and will be verified – whether they be high, medium or low priority.
Fact: Ooookkkkkaaaayyy. 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!!
Fact: Maybe you are luckier than most but I’ve seen people who staked this claim inevitably perform a LOT of rework later on the address those pesky “silence-equals-consent” stakeholder requirements. My advice, get every stakeholder’s review comments and address them completely and on a timely basis. Also, do not declare victory until after you have received approval from ALL of your key stakeholdersl!!
Fact: The customer is the customer. Right has nothing to do with it. If what the customer asks for sounds funny, wrong, insane – go talk to the customer. Do not tell them they are insane. Just say politely, “I am confused, I read this as …… is that really what you want?
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.
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.
There are a number of other myths we could dispel but I think that you get the message that your requirements need to be documented, validated with the stakeholders, reviewed and baselined. You do this, and I promise there will be far less drama in your project life!!!
Now about the Chupacabra…
Do you have a “requirement” question you would like the Requirements Experts team to address? If so, please visit www.reqexperts.com and contact us.
You might also find interesting: