Un requisito es una necesidad física o funcional singular documentada que un diseño, producto o proceso particular pretende satisfacer. Se utiliza comúnmente en diseño de ingeniería , ingeniería de sistemas , ingeniería de software , ingeniería empresarial , desarrollo de productos y optimización de procesos . Es un concepto amplio que podría referirse a cualquier función, atributo, capacidad, característica o calidad necesaria (o a veces deseada) de un sistema para que tenga valor y utilidad para un cliente, organización, usuario interno u otra parte interesada. Los requisitos pueden tener diferentes niveles de especificidad; por ejemplo, una especificación de requisitos o una "especificación" de requisitos (a menudo denominada de manera imprecisa "las" especificaciones, pero en realidad existen diferentes tipos de especificaciones) se refiere a un requisito (o a veces, conjunto de requisitos) que debe satisfacer un material, diseño, producto o servicio. [1]
Se utiliza un conjunto de requisitos como insumos en las etapas de diseño del desarrollo del producto . Los requisitos también son un aporte importante al proceso de verificación, ya que las pruebas deben rastrearse hasta requisitos específicos. Los requisitos muestran qué elementos y funciones son necesarios para el proyecto en particular. Cuando se utilizan métodos iterativos de desarrollo de software o métodos ágiles , los requisitos del sistema se desarrollan incrementalmente en paralelo con el diseño y la implementación. Con el modelo en cascada, los requisitos se desarrollan antes del diseño y la implementación.
El término requisito se ha utilizado en la comunidad de ingeniería de software desde al menos la década de 1960. [2]
Según la Guía del Cuerpo de Conocimientos de Análisis de Negocios® 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 del producto y del proceso están estrechamente vinculados; Se podría decir que un requisito de producto especifica la automatización requerida para respaldar un requisito de proceso, mientras que se podría decir que un requisito de proceso especifica las actividades requeridas 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 generalmente se clasifican en tipos producidos 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 Empresarial en su Business Analysis Body of Knowledge [5] (ver también FURPS y Tipos de requisitos ).
Las características de los buenos requisitos son expuestas de diversas maneras por diferentes autores, y cada autor generalmente enfatiza las características más apropiadas para su discusión general o el dominio tecnológico específico que se aborda. Sin embargo, generalmente se reconocen las siguientes características. [8] [9]
Hay muchos más atributos a considerar que contribuyen a la calidad de los requisitos. Si los requisitos están sujetos a reglas de integridad de datos (por ejemplo), entonces la exactitud/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 que lo requerido).
A lo anterior algunos añaden Observable externamente, es decir, el requisito especifica una característica del producto que es observable o experimentada externamente por el usuario. Estos defensores argumentan que los requisitos que especifican la arquitectura interna, el diseño, la implementación o las decisiones de prueba probablemente sean restricciones y deberían articularse claramente en la sección Restricciones del documento de Requisitos. La opinión contrastante 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 que el usuario no percibe. Por ejemplo, el requisito de presentar información geocodificada al usuario puede estar respaldado por el requisito de una interfaz con un socio comercial externo. La interfaz será imperceptible para el usuario, aunque la presentación de la información obtenida a través de la interfaz ciertamente no lo será. En segundo lugar, una restricción limita las alternativas de diseño, mientras que un requisito especifica las características del 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 prueba. Si este no es el caso, 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. Estos incluyen requisitos que dicen 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 son verificables a nivel de software, aún deben conservarse como documentación de la intención del cliente. Sin embargo, pueden atribuirse a requisitos de proceso que se consideran una forma práctica de cumplirlos. Por ejemplo, un requisito no funcional de estar libre de puertas traseras se puede satisfacer reemplazándolo con un requisito de proceso para utilizar programación de pares . Otros requisitos no funcionales se rastrearán hasta otros componentes del sistema y se verificarán en ese nivel. Por ejemplo, la confiabilidad del sistema a menudo se verifica mediante análisis a nivel del sistema. El software de aviónica, con sus complicados requisitos de seguridad, debe seguir el proceso de desarrollo del 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 obtención de requisitos (recopilación, comprensión, revisión y articulación de las necesidades de las partes interesadas ) y análisis de requisitos , [10] análisis (verificación de coherencia e integridad), especificación. (documentar 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 abordar estos problemas. Las ambigüedades, lo incompleto y las inconsistencias que pueden resolverse en la fase de requisitos generalmente cuestan mucho menos corregirlas que cuando estos mismos problemas se encuentran en etapas posteriores del desarrollo del producto. El análisis de requisitos se esfuerza por abordar estas cuestiones.
Hay que considerar un equilibrio de ingeniería entre requisitos que son demasiado vagos y aquellos que son tan detallados que no
Los enfoques ágiles evolucionaron como una forma de superar estos problemas, estableciendo requisitos de base a un alto nivel y elaborando detalles justo a tiempo o en el último momento responsable .
Los requisitos generalmente se escriben como un medio de comunicación entre las diferentes partes interesadas. Esto significa que los requisitos deben ser fáciles de entender tanto para los usuarios normales como para los desarrolladores. Una forma común 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 usuarios .
Los requisitos generalmente cambian con el tiempo. Una vez definidos y aprobados, los requisitos deben estar bajo control de cambios . Para 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 llevado a estudios y prácticas de gestión de requisitos .
Hay varios puntos de vista opuestos 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, alguna evidencia indica que especificar requisitos puede disminuir 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 con la información proporcionada. [15] [16] [17] De manera más general, algunas investigaciones sugieren que los requisitos de software son una ilusión creada al tergiversar las decisiones de diseño como requisitos en situaciones donde no hay requisitos reales evidentes. [18]
Mientras tanto, la mayoría de las metodologías ágiles de desarrollo de software cuestionan la necesidad de describir rigurosamente los requisitos de 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 usuarios (breves resúmenes que caben en una tarjeta que explica un aspecto de lo que debe hacer el sistema) y considera que es deber del desarrollador pedirle una aclaración directamente al cliente. Las metodologías ágiles intentan capturar los requisitos en una serie de pruebas de aceptación automatizadas .
Puede producirse un desplazamiento del alcance debido a que los requisitos cambian con el tiempo. En la gestión de requisitos, se permite la alteración de los requisitos, pero si no se realiza un seguimiento adecuado o los pasos anteriores (objetivos comerciales y luego requisitos del usuario) no se limitan mediante una supervisión adicional o se manejan como un costo y una posible falla del programa, entonces los cambios en los requisitos son fáciles y es probable que sucedan. Es fácil que los cambios de requisitos ocurran más rápido de lo que los desarrolladores pueden producir trabajo y, como resultado, el esfuerzo retrocede .
Existen múltiples taxonomías para los requisitos según el marco en el que se opere. (Por ejemplo, los estándares establecidos por IEEE, Vice IIBA o los enfoques del Departamento de Defensa de EE. UU.). Los diferentes lenguajes y procesos en diferentes lugares o el habla informal pueden causar confusión y desviación del proceso deseado.
Un proceso dirigido por humanos está sujeto a fallas humanas en la gobernanza, donde la conveniencia, los deseos o la política pueden conducir a excepciones o una subversión abierta del proceso y desviaciones de la forma en que se supone que debe proceder el proceso en los libros de texto. Ejemplos incluyen:
Dentro del proceso del Departamento de Defensa de EE. UU., se encuentran algunos ejemplos históricos de cuestiones de requisitos.
{{cite book}}: |first2=tiene nombre genérico ( ayuda )