¿De donde salen de los requerimientos de software?
En un mundo perfecto, todas las partes interesadas podrían articular completamente lo que necesitan, haciendo la vida mucho más fácil para los analistas. En realidad, sin embargo, no siempre están en condiciones de proporcionar información sobre cuáles son sus requisitos. Esto se debe a que no siempre saben para qué solicitar.
¿Cómo pueden los interesados solicitar una característica, si no saben si les proporcionará algún beneficio o no? Si no saben nada de funciones o capacidades similares, no podrán visualizar los beneficios o el uso de dichas funciones.
El estudio de sistemas similares y sus funcionalidades puede hacer mucho para asegurar que se capturen los requisitos típicos, de implementaciones similares en otras organizaciones. Durante un proyecto reciente, las partes interesadas no tenían idea de lo que funcionaría para ellos. El equipo del proyecto tuvo que construir el sistema desde cero basándose en la visión del patrocinador. Posteriormente se llamó a las partes interesadas para verificar los requisitos y proporcionar sugerencias para mejorar. Los requisitos en este caso, no provienen todos de los usuarios del sistema.
Este caso fue peculiar porque: 1) La compañía había perdido ingresos significativos y había lanzado el proyecto como una solución potencial. El equipo de administración estaba 100% detrás del proyecto y había decidido revisar completamente el sistema existente. 2) El patrocinador del proyecto tenía una visión para el sistema y no comprometería lo que quería. Fue esta visión con la que el equipo trabajó. 3) La forma actual de hacer las cosas era defectuosa y, como tal, no parecía tener sentido dedicar tiempo a comprender cómo realizaban actualmente su trabajo ( tal como es el análisis de procesos ). El sistema existente era complicado, desordenado e inefectivo. 4) Los usuarios nunca habían trabajado con un sistema central y no tenían una idea clara de las capacidades o características que más les convenían.
Teniendo en cuenta estas peculiaridades, la mayoría de los requisitos se obtuvieron sin los usuarios. El proyecto fue impulsado por la visión del patrocinador y no por los requisitos del usuario, aunque se buscó su opinión y se llevaron a cabo. El punto es que los requisitos no siempre vienen de los usuarios. Al analista, en algunos casos, se le puede pedir que sugiera requisitos, explique sus beneficios y solicite la aceptación del nuevo sistema.
Dicho esto,
¿De dónde más provienen los requerimientos de software?
En general, los requisitos pueden surgir de la necesidad de resolver un problema, responder a la presión o aprovechar una oportunidad. Aquí hay algunas fuentes específicas de requisitos que los analistas deben conocer:
Regulación gubernamental : las normas reglamentarias impuestas por el gobierno pueden requerir que se implementen ciertos requisitos. Por ejemplo, HIPAA en los EE. UU. Y la Directiva de protección de datos requieren que las organizaciones cumplan con ciertas leyes a lo largo de la vida de los datos; estas leyes deben tenerse en cuenta cuando los datos comerciales se gestionan tanto en tierra como en alta mar. De manera similar, cuando el gobierno introduce o modifica las tasas de IVA, los sistemas contables de las organizaciones deben modificarse para adaptarse a las nuevas tasas.
Normas de la industria : tienen un impacto en los requisitos, ya que afectan el rendimiento de los productos. Por ejemplo, las normas son las que garantizan que pueda sacar dinero de cualquier cajero automático, sin importar dónde se encuentre en el mundo. Además, los fabricantes de automóviles deben cumplir con ciertos estándares de seguridad y rendimiento para mantenerse competitivos. Los estándares de la industria también pueden requerir la necesidad de implementar ciertos requisitos por encima de otros.
Presión competitiva : las características de los productos de la competencia a menudo definen los requisitos funcionales mínimos por debajo de los cuales un nuevo producto no sería competitivo. Se pueden generar requisitos cuando los competidores elevan el listón. Por ejemplo, cuando el primer banco implementó cajeros automáticos, otros bancos de calle tenían que seguir su ejemplo. Los proyectos de sistemas de información a menudo se inician como parte de la estrategia de una organización para promover su competitividad.
Investigación de mercado : la investigación centrada en los hábitos de compra de los usuarios, los precios de mercado, las preferencias de los consumidores y la distribución de productos puede revelar nuevos requisitos que deben cumplirse.
Los requisitos no son siempre visibles o acostados a la espera de ser extraídos. Siempre hay una fase de descubrimiento en la que el analista tiene que hacer una investigación de antecedentes, hablar con los usuarios y explorar información relevante de múltiples fuentes. Saber cuándo y dónde se encuentran estos requisitos es una parte fundamental de la entrega de soluciones completas, prácticas e innovadoras.