False Requirements

False Requeriments - If you could ask your client what their requirements were and they responded with everything they needed, the Analysis Phase would be easy. However, that is rarely the case.

In the course of the requirements gathering process, the analyst will hear statements that appear on the surface to be requirements, but really they are not.

These are False Requirements. False requirements come in many forms, including:

  • Vague requirements

These are statements that contain a hint of one or more requirements; however, they are not specific enough to be considered real requirements. 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 people to say ‘Wow’ when they see this.” This is not a requirement. The analyst must ask some follow-up questions to get more specifics.

  • Opinions

Opinion statements can be requirements, but many times they are not. For instance, if there are multiple ways that a process could work, the client may give you their opinion on the way they think would be best. If one way is better than the others, it is fine to express an opinion.

If the multiple solutions are all equally valid, then all of them should be documented as possibilities for requirements. However, if a client manager tells you that he or she thinks the company is spending too much money on the project, he/she is giving an opinion - not a requirement.

  • Project-related statements

These are statements that describe the project – not the deliverables. For example, if a client tells you that “we should prototype this solution first,” he or she is giving you input into the project approach - not a requirement.

If your manager says you are “required” to complete the work within six months, he or she is giving you a project duration constraint – not a requirement.

  • Out of scope

When you are gathering requirements, you may find that you get off on a tangent (related or unrelated to the discussion). For instance, when discussing a set of reports, the client might remark that a co-worker has a new printer and that he/she would like a similar one.

This is not a requirement. It is out of scope for the purposes of the reporting discussion. On the other hand, if the type of printers available has an influence on the reports, then it could be a requirement.

  • Not the right role

It is important to understand the role of the person giving you requirements. For example, an end user might tell you, “I think we should have a set of reports that go to our executive management staff.” However, the end user is not the right person to give us that type of requirement.

Likewise, a client might tell you that you should be using web technology on this project.” Again, the client is not the right person to make this type of technology decision. The analyst should probe more to determine what the detailed requirements are that make the user think a web solution is appropriate.

  • Unrealistic (not testable)

You might hear requirements that are really marketing hype or extreme hyperbole. For instance, a client manager may tell you that “This product needs to be able to run on the moon.”

This is not a requirement since it cannot be tested or validated. The analyst should ask follow-up questions to determine the real requirements behind the statement.

Fast Track

Libro El Director de Proyectos Práctico -

Un Método probado de 28 Pasos para completar tu Proyecto Exitosamente


Por fin ─ un libro sencillo con un método paso a paso para completar tu proyecto.

¡Y sin tener conocimiento previo sobre administración de proyectos!

Toda la "paja" de la metodología de dirección de proyectos fue eliminada, dejando solo lo que es absolutamente útil para completar la tarea.

El Director de Proyectos Práctico, Project Management for Small Projects. 

Un libro pensado en el líder de proyectos empírico que salió ganador de la rifa del tigre. Pues ya tiene la responsabilidad de un proyecto, pero que no sabe ni por donde empezar. Necesita una receta ABC para seguir.

Contiene 260 páginas perfectamente detalladas con ejemplos e ilustraciones, que te llevan de la mano hasta completar tu proyecto.

Pruébalo, síguelo, ten éxito. O sigue haciendo lo mismo... :(

Disponible en Amazon

Compra aquí El Director de Proyectos Práctico en su versión electrónica─

Entrega inmediata.

BONO ADICIONAL:  El libro incluye todos los templates─plantillas─que necesitas, listos para ser usadas. No necesitas comprar nada mas.

COPYRIGHT © 2007-2012 por Hector Olvera Padilla 1853071. Reproduction in whole or in part, or translation without written permission is prohibited. "PMP®", "PMBOK®", and "PMI®" are registered marks of the Project Management Institute, Inc.