En ingeniería , un requisito es una condición que debe cumplirse para que el resultado de un trabajo sea aceptable. Es una descripción explícita, objetiva, clara y a menudo cuantitativa de una condición que debe cumplir un material, diseño, producto o servicio. [1]
Una especificación es un conjunto de requisitos que normalmente utilizan los desarrolladores en la etapa de diseño del desarrollo del producto y los evaluadores en su proceso de verificación.
En el desarrollo iterativo e incremental, como el desarrollo de software ágil , los requisitos se desarrollan en paralelo con el diseño y la implementación. Con el modelo en cascada , los requisitos se completan antes de que comience el diseño o la implementación.
Los requisitos se utilizan en muchos campos de ingeniería, incluidos el diseño de ingeniería , la ingeniería de sistemas , la ingeniería de software , la ingeniería empresarial , el desarrollo de productos y la optimización de procesos .
El requisito es un concepto relativamente amplio que puede describir cualquier función, atributo, capacidad, característica o calidad necesaria o deseada de un sistema para que tenga valor y utilidad para un cliente, una organización, un usuario u otra parte interesada.
El término requisito se ha utilizado en la comunidad de ingeniería de software al menos desde la década de 1960. [2]
De acuerdo con la Guía del Cuerpo de Conocimientos del Análisis de Negocio® versión 2 del IIBA (BABOK), [3] un requisito es:
Esta definición se basa en IEEE 610.12-1990: Glosario estándar IEEE de terminología de ingeniería de software. [4]
Se puede decir que los requisitos se relacionan con dos campos:
Los requisitos de producto y de proceso están estrechamente vinculados; se podría decir que un requisito de producto especifica la automatización necesaria para respaldar un requisito de proceso, mientras que un requisito de proceso podría decirse que especifica las actividades necesarias para respaldar un requisito de producto. Por ejemplo, se puede imponer un requisito de costo máximo de desarrollo (un requisito de proceso) para ayudar a lograr un requisito de precio de venta máximo (un requisito de producto); un requisito de que el producto sea mantenible (un requisito de producto) a menudo se aborda imponiendo requisitos para seguir estilos de desarrollo particulares (por ejemplo, programación orientada a objetos ), guías de estilo o un proceso de revisión/inspección (requisitos de proceso).
Los requisitos se clasifican normalmente en tipos que se producen en diferentes etapas de una progresión de desarrollo, y la taxonomía depende del modelo general que se utilice. Por ejemplo, el siguiente esquema fue ideado por el Instituto Internacional de Análisis de Negocios en su Business Analysis Body of Knowledge [5] (consulte también FURPS y Tipos de requisitos ).
Los distintos autores enunciaron las características de los buenos requisitos de distintas maneras, y cada autor generalmente hizo hincapié en las características más apropiadas para su discusión general o el dominio tecnológico específico que se aborda. Sin embargo, las siguientes características son generalmente reconocidas. [8] [9]
Hay muchos más atributos que se deben tener en cuenta y que contribuyen a la calidad de los requisitos. Si los requisitos están sujetos a reglas de integridad de datos (por ejemplo), entonces la precisión/corrección y la validez/autorización también son atributos valiosos. La trazabilidad confirma que el conjunto de requisitos satisface la necesidad (ni más ni menos de lo que se requiere).
A lo anterior, algunos añaden "Observable externamente", es decir, el requisito especifica una característica del producto que es observable externamente o experimentada por el usuario. Estos defensores argumentan que los requisitos que especifican decisiones internas de arquitectura, diseño, implementación o prueba son probablemente restricciones y deberían estar claramente articuladas en la sección Restricciones del documento de Requisitos. La opinión opuesta es que esta perspectiva falla en dos puntos. En primer lugar, la perspectiva no reconoce que la experiencia del usuario puede estar respaldada por requisitos no perceptibles por el usuario. Por ejemplo, un requisito para presentar información geocodificada al usuario puede estar respaldado por un requisito para una interfaz con un socio comercial externo de terceros. La interfaz será imperceptible para el usuario, aunque la presentación de información obtenida a través de la interfaz ciertamente no lo sería. En segundo lugar, una restricción limita las alternativas de diseño, mientras que un requisito especifica las características de diseño. Para continuar con el ejemplo, un requisito que selecciona una interfaz de servicio web es diferente de una restricción que limita las alternativas de diseño a métodos compatibles con una arquitectura de inicio de sesión único.
Todos los requisitos deben ser verificables. El método más común es mediante pruebas. Si no es así, se debe utilizar otro método de verificación (por ejemplo, análisis, demostración, inspección o revisión del diseño).
Ciertos requisitos, por su propia estructura, no son verificables. Entre ellos se incluyen aquellos que establecen que el sistema nunca o siempre debe exhibir una propiedad particular. La prueba adecuada de estos requisitos requeriría un ciclo de prueba infinito. Dichos requisitos deben reescribirse para que sean verificables. Como se indicó anteriormente, todos los requisitos deben ser verificables.
Los requisitos no funcionales, que no se pueden verificar a nivel de software, deben conservarse como documentación de la intención del cliente. Sin embargo, se pueden rastrear hasta los requisitos de proceso que se determine que son una forma práctica de cumplirlos. Por ejemplo, un requisito no funcional de estar libre de puertas traseras se puede satisfacer reemplazándolo por un requisito de proceso de utilizar programación en pares . Otros requisitos no funcionales se rastrearán hasta otros componentes del sistema y se verificarán a ese nivel. Por ejemplo, la confiabilidad del sistema a menudo se verifica mediante análisis a nivel de sistema. El software de aviónica con sus complicados requisitos de seguridad debe seguir el proceso de desarrollo DO-178B .
Actividades que conducen a la derivación de los requisitos del sistema o software. La ingeniería de requisitos puede implicar un estudio de viabilidad o una fase de análisis conceptual del proyecto y la obtención de requisitos (recopilación, comprensión, revisión y articulación de las necesidades de las partes interesadas ) y el análisis de requisitos [10] , análisis (comprobación de la coherencia y la integridad), especificación (documentación de los requisitos) y validación (asegurarse de que los requisitos especificados sean correctos). [11] [12]
Los requisitos son propensos a problemas de ambigüedad, incompletitud e inconsistencia. Se ha demostrado que técnicas como la inspección rigurosa ayudan a lidiar con estos problemas. Las ambigüedades, la incompletitud y las inconsistencias que se pueden resolver en la fase de requisitos suelen costar órdenes de magnitud menos que corregirlas cuando estos mismos problemas se detectan en etapas posteriores del desarrollo del producto. El análisis de requisitos intenta abordar estos problemas.
Hay que tener en cuenta un equilibrio de ingeniería entre los requisitos que son demasiado vagos y aquellos que son tan detallados que...
Los enfoques ágiles evolucionaron como una forma de superar estos problemas, estableciendo requisitos de base de alto nivel y elaborando detalles justo a tiempo o en el último momento responsable .
Los requisitos suelen redactarse como un medio de comunicación entre las distintas partes interesadas. Esto significa que los requisitos deben ser fáciles de entender tanto para los usuarios normales como para los desarrolladores. Una forma habitual de documentar un requisito es indicar lo que debe hacer el sistema. Ejemplo: "El contratista debe entregar el producto a más tardar en la fecha xyz". Otros métodos incluyen casos de uso e historias de usuario .
Los requisitos generalmente cambian con el tiempo. Una vez definidos y aprobados, los requisitos deben estar sujetos al control de cambios . En muchos proyectos, los requisitos se modifican antes de que el sistema esté completo. Esto se debe en parte a la complejidad del software informático y al hecho de que los usuarios no saben lo que quieren antes de verlo. Esta característica de los requisitos ha dado lugar a estudios y prácticas de gestión de requisitos .
Existen varias opiniones encontradas sobre qué son los requisitos y cómo deben gestionarse y utilizarse. Dos organismos líderes en la industria son el IEEE y el IIBA. Ambos grupos tienen definiciones diferentes pero similares de lo que es un requisito.
Muchos proyectos han tenido éxito con poco o ningún acuerdo sobre los requisitos. [13] Además, algunas evidencias indican que especificar los requisitos puede reducir la creatividad y el rendimiento del diseño. [14] Los requisitos obstaculizan la creatividad y el diseño porque los diseñadores se preocupan demasiado por la información proporcionada. [15] [16] [17] En términos más generales, algunas investigaciones sugieren que los requisitos de software son una ilusión creada al tergiversar las decisiones de diseño como requisitos en situaciones en las que no hay requisitos reales evidentes. [18]
Mientras tanto, la mayoría de las metodologías de desarrollo de software ágiles cuestionan la necesidad de describir rigurosamente los requisitos del software por adelantado, lo que consideran un objetivo en movimiento. En cambio, la programación extrema , por ejemplo, describe los requisitos de manera informal utilizando historias de usuario (resúmenes breves que caben en una tarjeta de índice que explican un aspecto de lo que debería hacer el sistema) y considera que es deber del desarrollador pedirle aclaraciones directamente al cliente. Las metodologías ágiles intentan capturar los requisitos en una serie de pruebas de aceptación automatizadas .
La alteración del alcance puede ocurrir si los requisitos cambian con el tiempo. En la gestión de requisitos, se permite la modificación de los requisitos, pero si no se realiza un seguimiento adecuado o si los pasos anteriores (los objetivos de negocio y luego los requisitos del usuario) no se controlan mediante una supervisión adicional o no se manejan como un costo y un posible fracaso del programa, entonces los cambios de requisitos son fáciles y es probable que ocurran. Es fácil que los cambios de requisitos se produzcan más rápido de lo que los desarrolladores pueden producir trabajo y, como resultado, el esfuerzo se reduce .
Existen múltiples taxonomías de requisitos según el marco en el que se esté trabajando (por ejemplo, los estándares establecidos por el IEEE, el IIBA o el Departamento de Defensa de los EE. UU.). Diferentes lenguajes y procesos en diferentes lugares o el lenguaje informal pueden causar confusión y desviaciones del proceso deseado.
Un proceso dirigido por seres humanos está sujeto a fallas humanas en la gobernanza, donde la conveniencia, los deseos o la política pueden llevar a excepciones o a una subversión total del proceso y a desviaciones de la forma en que se supone que debe proceder el proceso. Algunos ejemplos incluyen:
Dentro del proceso del Departamento de Defensa de los EE. UU., algunos ejemplos históricos de problemas de requisitos son:
{{cite book}}: |first2=tiene nombre genérico ( ayuda )