Saltar al contenido

Fallo épico: Especificación de requisitos

Ya empezamos mal usando la palabra requisitos

Estaba revisando un curso gratuito de introducción a la gestión de proyectos informáticos, y he visto que en una de las lecciones planteaban un ejercicio muy simple de ordenar y seleccionar los apartados que tendría un documento de especificación de requisitos software.

Un requisito, según wikipedia, es:

Una circunstancia o condición necesaria para algo. […] En ingeniería de sistemas se emplea el término requisito en un sentido análogo, como una condición necesaria sobre el contenido, forma o funcionalidad de un producto o servicio.

Por tanto, como significa lo mismo, solemos dar por hecho que las personas no técnicas, es decir, sin capacitación relacionada con ingeniería del software, entenderán lo que son los requisitos de software. Realmente «requisito» lo entienden, pero «requisito de software» no es algo tan trivial.

Los requisitos de software NO son la parte más importante del proyecto

Pues no, no lo son. Lo más importante del proyecto es entender el problema o la oportunidad para así poder proponer la mejor solución. Si la solución necesita de herramientas de software, entonces habrá que definir adecuadamente la solución e implantarla usando metodologías y buenas prácticas, pero eso no quiere decir que los requisitos de software sean la parte más importante de un proyecto de desarrollo de software.

No nos olvidemos que una especificación de requisitos de software debe ser perfectamente entendida por los desarrolladores. Un ingeniero desarrollador necesita saber, por lo menos, qué tiene que desarrollar y con qué propósito. Sin embargo, esa especificación no tiene porqué ser responsabilidad de los interesados, ni de definirlos o redactarlos, ni de certificarlos. Se tiende mucho a pensar que los requisitos de software se deben de poner en un documento firmado o certificado por el Sponsor o los interesados, y no es así.

No olvides trazar el alcance del proyecto con los requisitos

Esto sí que hay que hacerlo. El alcance es lo que va a definir el contorno y los límites del proyecto, y debería ser básicamente la definición de la solución técnica. El alcance está estrechamente relacionado con la solución al problema: debería ser al menos parte de la solución al problema. Si trazamos adecuadamente el alcance con la especificación de los requisitos de software, estaremos dando sentido a todo el trabajo de desarrollo que se realizará.

Evita caer en un fallo épico como este y ayuda a que los demás colegas no caigan en él. Todos ganaremos.

Deja una respuesta

Puedes añadir un comentario o responder a otro.

Información básica sobre protección de datos Ver más

  • Responsable: Antonio Gutiérrez Martín.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad