Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Método para contratar personal.
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Manual de Administración de Proyectos

Los requerimientos de un proyecto

Por Joaquín Ibáñez, PMP® [ Acerca del autor]

El propósito de la gestión de requerimientos es asegurar que el proyecto cumple con las expectativas de sus clientes y de sus interesados, tanto externos como internos, siendo el proceso que garantiza el vínculo entre lo que esperan los clientes y usuarios, y lo que los equipos de proyecto tienen que desarrollar.

Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los proyectos de desarrollo de software donde adquieren todo su sentido, garantizando el proceso y sirviendo de referencia para asegurar y controlar los cambios que en el proyecto puedan surgir (trazabilidad). A menudo, incluye la elaboración de planes específicos para diferentes aspectos como la recolección, gestión e integración de los requerimientos.

Definición de requerimiento y Stakeholders (Interesados)

Según la definición del PMBOK®, un requerimiento es la condición o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos formalmente establecido.

Son todas aquellas características observables que cualquier interesado desea que estén contenidas en el sistema. Como requisitos se incluyen las necesidades, deseos y expectativas del patrocinador, cliente, usuarios, y otros interesados.

Como requerimiento se podría establecer:

  • Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue un objetivo.
  • Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto.
  • Una restricción impuesta por algún interesado

Definiendo el concepto de stakeholder (interesado) como alguien que está afectado por el proyecto que se desarrolla, podremos encontrar que hay de dos tipos:

  • Usuarios: Aquellos que utilizaran el sistema.
  • Clientes: aquellos que requieren el sistema y son los responsables de su validación o aprobación.

Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos encontrarnos que hay un conflicto entre los requerimientos de ambos. En la mayoría de los casos, los requerimientos de los clientes tienen prioridad sobre los requerimientos de los usuarios.

Características de los requerimientos

Un requerimiento debe cumplir ciertos criterios y características:

  • Único: El requerimiento debe poder ser interpretado inequívocamente de una sola manera.
  • Verificable: Su implementación debe poder ser comprobada. El test debe dar como resultado CORRECTO o INCORRECTO.
  • Claro: Los requerimientos no deben contener terminología innecesaria. Deben ser establecidos de forma clara y simple.
  • Viable (realístico y posible): El requerimiento debe ser factible según las restricciones actuales de tiempo, dinero y recursos disponibles.
  • Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el requerimiento o bien si la retirada de dicho requerimiento no tiene ningún efecto

Además de los criterios para los requerimientos individuales, para el conjunto de ellos debe cumplirse:

  • Independiente: Para comprender el requerimiento no debe ser necesario el conocimiento de otro.
  • Consistente: No debe existir ningún conflicto entre requerimientos. Los conflictos pueden ser:

    - Directos: Cuando ante una misma situación, cabe esperar comportamientos diferentes.
    -  Indirectos: Se produce cuando no es posible cumplir con dos requisitos al mismo tiempo, aunque describan funcionalidades distintas.

  • No redundante: Cada requerimiento debe ser formulado una sola vez, y no sobreponerse con otros requerimientos.
  • Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las condiciones que puedan ocurrir.

Organización y estructura de la gestión de requerimientos

Según el origen y características, los requisitos pueden dividirse en diferentes tipos., que pueden representarse en forma de pirámide, en cuyo nivel superior se sitúan las necesidades de los interesados. En los niveles más bajos son características, casos de uso y requisitos complementarios tal como se muestra en la figura:


  • Necesidad: Un interesado demanda un requerimiento.
  • Característica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de negocios.
  • Caso de uso: Una descripción del comportamiento del sistema descrito como una secuencias de acciones.
  • Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser contemplado en los casos de uso.
  • Caso de prueba: Una especificación de las entradas necesarias para una prueba, las condiciones de ejecución y resultados esperados. Tiene el papel de comprobar si los casos de uso derivados de los casos de prueba y los requisitos complementarios se aplican correctamente.
  • Escenario: Una secuencia específica de acciones o una ruta de acceso específica a través de un caso de uso. Ayudan a derivar en casos de uso a partir de los casos de prueba y facilitan el diseño e implementación a través de los casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles de detalle. Cuanto menor sea el nivel, más detallado es el requisito. Sin embargo, corresponde a los analistas de negocio decidir el nivel de detalle en cada nivel, aunque no sería incorrecto establece requisitos muy detallados en el nivel de necesidades.

Trazabilidad

La trazabilidad de los requerimientos se refiere a la documentación de la vida de cada uno de ellos, y debe permitir seguir el historial desde su formulación original hasta el momento actual. Cada cambio realizado debe por tanto ser documentado para conseguir dicha trazabilidad. Incluso la implementación de las características determinadas por los requerimientos debe poder ser trazada.

Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc... Todas y cada una de ellas tienen diferentes requerimientos para el producto. Utilizando la trazabilidad, puede seguirse el historial de una característica implementada hasta las personas o grupos que la solicitaron durante la generación de los requerimientos, permitiendo un rápido análisis en cada fase del proyecto para:

  • Determinar la visión original y permitir una discusión controlada de los cambios en el alcance.
  • Determinar qué elementos se verán afectados cuando consideramos agregar un nuevo requerimiento o modificar uno ya existente.
  • Verificar que el requerimiento contempla todos lo que el interesado solicitó.
  • Evitar el Gold Platting: Verificar que la aplicación no implementa funcionalidades no demandadas por el cliente.

Bibliografía:

Young, Ralph R, “Recommended Requirements Gathering Practices”,STSC, Abril 2002.
Gottesdiener, Ellen, “Good Practices for Developing User Requirements” , STSC, Marzo 2008.
Zielczynski, Peter . “Requirements Management Using IBM® Rational® RequisitePro®”, IBM Press., 2008.

indice del manual

Comparte

Qué opinan nuestros lectores… ( Comparte también tu opinión )

 

Nicolás de Rosario dijo el 12 Mayo de 2014:
Estimado Franco no existe diferencia entre requisitos y requerimientos. Son sinónimos. Saludos

Franco Zuloaga dijo el 06 Agosto de 2013:
Estimado Joaquin.
Y pudieras ilustrarnos con un ejemplo para diferenciar lo que es un requisito y un requerimiento. Que espera el cliente en ambos casos.
Atentamente
Franco

Editor dijo el 22 Febrero de 2012:
Ejemplo de servicio proporcionado por el sistema, formulado por un analista de negocio: generar factura

Jaime dijo el 22 Febrero de 2012:
Saludos, Felicitaciones por el tema, tengo una duda con respecto a la definición de
"Característica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de negocios"
Podría por favor ilustrar con un ejemplo

Muchas gracias

Editor dijo el 10 Marzo de 2011:
Hola Edward, una expectativa es algo que el cliente (dentro de este contexto) presupone que va a recibir, se lo hayas ofrecido o no explícitamente. Y si no lo recibe probablemente se moleste o se va a sentir decepcionado. Es por eso que tienes que administrar las expectativas, para que no haya confusiones y que la gente no espere más de lo que estás dispuesto y eres capaz de entregar. Esa expectativa podría ser o no el cumplimiento de un requerimiento, pero también pueden ser aspectos más sutiles y subjetivos, como la expectativa de recibir un trato amable de tu parte o una constante comunicación. En cambio un requerimiento es algo que se acuerda que se va a cumplir dentro del proyecto. Algo que el cliente te pide que cumpla el proyecto: pueden ser funciones del sistema, calidad del producto, incluso ciertos documentos que acompañen al producto a desarrollar. Estos requerimientos deberían de estar especificados en un documento realizado antes de que te contrate para llevar a cabo su proyecto, pues con base en ellos deberás de realizar tu plan y cotizarle el proyecto. Aquí el juego de palabras es que, a final de cuentas, su expectativa mínima es recibir el producto ofrecido con el 100% de los requerimientos establecidos.


Edward Mestanza dijo el 20 Octubre de 2010:
Buen día amigos de Lider de Proyecto, tengo una duda referente a lo que es una expectativa y un requerimiento. En clase mi profesor(con certificación PMP)ha manifestado que las expectativas se refieren a las necesidades y los requerimientos a las especificaciones técnicas, en ese sentido aconseja no confundir una expectativa con un requerimiento ya que son cosas distintas. Mucho agradeceré comentar el tema.
Edward



Comparte tu opinión
Los campos marcados con * son obligatorios.


*Nombre:
Correo:
Esconder mi dirección
*Texto:
 


5 Tips para manejar las brechas generacionales (Eduardo Medina)
+
.

.
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.