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.