False Requirements-Requirement Elicitation

In project management, requirements describe how a product or service should act, appear, or perform. These details explain the features and functions of the products or deliverables the project needs to have.

If you could ask your clients about requirements and know they were responding with exactly everything they needed, gathering requirements would be a piece of cake. However, in the course of the requirements-gathering process, it just usually isn’t that easy.

In fact, you’ll often hear information from clients that, on the surface, appear to be requirements when they actually aren’t requirements at all. We call these items false requirements.

False requirements come in many forms. Here are some of the more prevalent categories:

Vague requirements: How many times does a client offer a statement that contains a hint of one or more requirements but doesn’t offer any kind of specifics? Vague requirements require good follow-up and probing questions to make sure you have the correct level of detail. For instance, your sponsor might tell you, “I want this application to make employees’ lives easier.” This is not specific enough to be a requirement. You need to ask some follow-up questions to learn exactly how the client wants the application to help employees.

Opinions: While opinion statements can be requirements, many times they’re not. In many cases, the client will provide an opinion on the features and functions of a deliverable, and these are valid statements. However, if a client manager tells you that he thinks the company is spending too much money on the project, he’s offering an opinion — not a requirement.

Project-related statements: Requirements describe deliverables — not the project. For example, if a client tells you that “we should prototype this solution first,” he’s giving you input for the project approach — not a requirement. If a client states that she wants the project completed by a certain date, she’s giving you a schedule constraint — not a requirement.

Out-of-scope statements: When gathering requirements, you may find that you get off on a tangent (either related or unrelated to the discussion). For instance, when discussing a set of reports, the client might remark that a coworker has a new printer and that she would like a similar one. This is not a requirement; it’s out of scope for the purposes of the reporting discussion.

Comments from the wrong person: It’s important to know the role of a person providing requirements, so you can determine if the information he’s providing is consistent with his authority. For example, a user might tell you, “I think we should allow our vendors access to this information.” This isn’t a requirement since the typical user doesn’t have the power to make this type of decision.

Unrealistic or not testable: You might hear requirements that are really just marketing hype or extreme hyperbole. For instance, a client manager may tell you, “This product needs to be able to run on the moon.” This isn’t a real requirement since you can’t test or validate it. Make sure to ask follow-up questions to determine the real requirements behind the statement.

Learning how to quickly recognize these false requirements and how to dig deeper for the details is vital for a project manager. It can help save time in reworking the project as well as prevent further confusion later in the project.