Hispanopedia Wiki
Articulo de referencia

Requisito

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 cuan...

Hispanopedia WikiContenido en espanolLectura gratuita

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 o pliego de condiciones es un conjunto de requisitos que suelen utilizar los desarrolladores en la fase de diseño del desarrollo de un producto y los evaluadores en su proceso de verificación.

En el desarrollo iterativo e incremental , como el desarrollo ágil de software , 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 la 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 cualidad necesaria o deseada de un sistema para que tenga valor y utilidad para un cliente, organización, usuario u otra parte interesada.

Orígenes del término

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 Empresarial® versión 2 del IIBA (BABOK), [ 3 ] un requisito es:

  1. Una condición o capacidad necesaria para que una parte interesada pueda resolver un problema o alcanzar un objetivo.
  2. Una condición o capacidad que debe cumplir o poseer una solución o un componente de la solución para satisfacer un contrato, estándar, especificación u otros documentos impuestos formalmente.
  3. Una representación documentada de una condición o capacidad como en (1) o (2).

Esta definición se basa en IEEE 610.12-1990: Glosario estándar de terminología de ingeniería de software de IEEE. [ 4 ]

Requisitos del producto frente a requisitos del proceso

Se puede decir que los requisitos se relacionan con dos ámbitos:

  • Los requisitos del producto prescriben las propiedades de un sistema o producto.
  • Los requisitos del proceso prescriben las actividades que debe realizar la organización desarrolladora. Por ejemplo, podrían especificar las metodologías que deben seguirse y las restricciones que la organización debe cumplir.

Los requisitos de producto y de proceso están estrechamente vinculados; un requisito de producto especifica la automatización necesaria para cumplir con un requisito de proceso, mientras que un requisito de proceso especifica las actividades necesarias para cumplir con un requisito de producto. Por ejemplo, se puede imponer un requisito de costo máximo de desarrollo (un requisito de proceso) para ayudar a alcanzar un requisito de precio máximo de venta (un requisito de producto); el requisito de que el producto sea mantenible (un requisito de producto) a menudo se aborda imponiendo requisitos para seguir estilos de desarrollo específicos (por ejemplo, programación orientada a objetos ), guías de estilo o un proceso de revisión/inspección (requisitos de proceso).

Tipos de requisitos

Los requisitos se clasifican normalmente en tipos generados en diferentes etapas de un proceso de desarrollo, y la taxonomía depende del modelo general que se utilice. Por ejemplo, el Instituto Internacional de Análisis de Negocios ideó el siguiente esquema en su Cuerpo de Conocimientos de Análisis de Negocios [ 5 ] (véase también FURPS y Tipos de requisitos ).

Requisitos arquitectónicos
Los requisitos arquitectónicos explican lo que hay que hacer al identificar la integración necesaria de la estructura del sistema y el comportamiento del sistema , es decir, la arquitectura del sistema.
En ingeniería de software , se les llama requisitos arquitectónicamente significativos , que se definen como aquellos requisitos que tienen un impacto medible en la arquitectura de un sistema de software . [ 6 ]
Requisitos del negocio
Declaraciones de alto nivel sobre las metas, objetivos o necesidades de una organización. Suelen describir oportunidades que la organización desea aprovechar o problemas que quiere resolver. A menudo se incluyen en un caso de negocio .
Requisitos del usuario (partes interesadas)
Declaraciones de nivel intermedio sobre las necesidades de un grupo o partes interesadas específicas. Suelen describir cómo se espera que interactúen con la solución propuesta. A menudo, actúan como un punto intermedio entre los requisitos empresariales de alto nivel y los requisitos de solución más detallados.
Requisitos funcionales (de la solución)
Generalmente, se trata de descripciones detalladas de las funciones, capacidades, comportamiento e información que la solución proporcionará. Algunos ejemplos son el formato de texto, el cálculo de números y la modulación de señales. También se las conoce como capacidades .
Requisitos de calidad de servicio (no funcionales)
Generalmente, son declaraciones detalladas de las condiciones bajo las cuales la solución debe seguir siendo efectiva, cualidades que debe tener o restricciones dentro de las cuales debe operar. [ 7 ] Algunos ejemplos son: confiabilidad, capacidad de prueba, mantenibilidad y disponibilidad. También se conocen como características , restricciones o ilidades .
Requisitos de implementación (transición)
Por lo general, las descripciones detalladas de las capacidades o el comportamiento solo son necesarias para facilitar la transición del estado actual de la empresa al estado futuro deseado, pero posteriormente ya no serán necesarias. Algunos ejemplos son la contratación, los cambios de rol, la formación y la migración de datos de un sistema a otro.
Requisitos reglamentarios
Requisitos definidos por leyes (federales, estatales, municipales o regionales), contratos (términos y condiciones) o políticas (de la empresa, del departamento o del proyecto).

Características de los buenos requisitos

Las características de los buenos requisitos son enunciadas de diversas maneras por diferentes autores, quienes generalmente enfatizan las características más apropiadas para su análisis general o el dominio tecnológico específico que abordan. Sin embargo, las siguientes características son generalmente reconocidas. [ 8 ] [ 9 ]

Existen muchos otros 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 precisión/corrección y la validez/autorización también son atributos importantes. La trazabilidad confirma que el conjunto de requisitos satisface la necesidad (ni más ni menos de lo requerido).

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 pruebas son probablemente restricciones y deberían estar claramente articulados en la sección de Restricciones del documento de Requisitos. La visión opuesta es que esta perspectiva falla en dos puntos. Primero, no reconoce que la experiencia del usuario puede estar respaldada por requisitos no perceptibles para el usuario. Por ejemplo, un requisito para presentar información geocodificada al usuario puede estar respaldado por un requisito de 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á. Segundo, una restricción limita las alternativas de diseño, mientras que un requisito especifica 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 (SSO).

Verificación

Todos los requisitos deben ser verificables. El método más común es mediante pruebas. Si esto no es posible, 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. Esto incluye aquellos que establecen que el sistema debe exhibir una propiedad determinada de forma permanente o inexistente . La correcta comprobación de estos requisitos requeriría un ciclo de pruebas infinito. Dichos requisitos deben reformularse para que sean verificables. Como se mencionó 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, pueden vincularse a requisitos de proceso que se consideren una forma práctica de cumplirlos. Por ejemplo, un requisito no funcional que exija la ausencia de puertas traseras puede satisfacerse sustituyéndolo por un requisito de proceso que utilice la programación en parejas . Otros requisitos no funcionales se vincularán a otros componentes del sistema y se verificarán a ese nivel. Por ejemplo, la fiabilidad del sistema suele verificarse mediante análisis a nivel de sistema. El software de aviónica, con sus complejos 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 incluir 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 (verificación de la coherencia y la exhaustividad), 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 presentar ambigüedades, deficiencias e inconsistencias. Se ha demostrado que técnicas como la inspección rigurosa ayudan a abordar estos problemas. Las ambigüedades, deficiencias e inconsistencias que se pueden resolver en la fase de requisitos suelen costar mucho menos que cuando se detectan en etapas posteriores del desarrollo del producto. El análisis de requisitos busca solucionar estos problemas.

Hay que considerar un equilibrio de ingeniería entre los requisitos que son demasiado vagos y los que son tan detallados que...

  • Su producción lleva mucho tiempo, a veces hasta el punto de quedar obsoleta una vez terminada.
  • limitar las opciones de implementación disponibles
  • son costosos de producir

Los enfoques ágiles surgieron como una forma de superar estos problemas, estableciendo requisitos básicos a un alto nivel y elaborando los detalles según el momento oportuno o en el último momento posible .

Requisitos de documentación

Los requisitos suelen redactarse como un medio de comunicación entre las distintas partes interesadas. Esto significa que deben ser fáciles de entender tanto para los usuarios habituales como para los desarrolladores. Una forma común de documentar un requisito es indicar qué debe hacer el sistema. Por ejemplo: «El contratista debe entregar el producto antes de la fecha xyz». Otros métodos incluyen casos de uso e historias de usuario .

Cambios en los requisitos

Los requisitos suelen cambiar con el tiempo. Una vez definidos y aprobados, deben someterse a 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 y a que los usuarios no saben lo que quieren hasta que lo ven. Esta característica de los requisitos ha dado lugar a estudios y prácticas de gestión de requisitos .

Asuntos

Estándares en competencia

Existen diversas perspectivas sobre qué son los requisitos y cómo deben gestionarse y utilizarse. Dos de las organizaciones líderes en el sector son el IEEE y el IIBA. Ambos grupos tienen definiciones diferentes, aunque similares, de lo que constituye un requisito.

Disputas relativas a la necesidad y los efectos de los requisitos de software

Muchos proyectos han tenido éxito con poco o ningún acuerdo sobre los requisitos. [ 13 ] Algunas evidencias indican además 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 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 presentar erróneamente 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 de desarrollo de software ágil cuestionan la necesidad de describir rigurosamente los requisitos del software desde el principio, ya que los consideran un objetivo en constante evolución. En cambio, la programación extrema, por ejemplo, describe los requisitos de manera informal mediante historias de usuario (resúmenes breves que caben en una ficha y explican un aspecto de lo que el sistema debería hacer), y considera que es deber del desarrollador solicitar directamente aclaraciones al cliente. Las metodologías ágiles intentan capturar los requisitos en una serie de pruebas de aceptación automatizadas .

Aumento progresivo de los requisitos

La desviación del alcance puede ocurrir debido a cambios en los requisitos a lo largo del tiempo. En la gestión de requisitos, se permite la modificación de los mismos, pero si no se realiza un seguimiento adecuado o si los pasos previos (objetivos de negocio y luego requisitos del usuario) no se controlan mediante una supervisión adicional o no se gestionan como un coste y un posible fallo del programa, entonces los cambios en los requisitos son fáciles y probables. Es fácil que los cambios en los requisitos se produzcan más rápido de lo que los desarrolladores pueden producir trabajo, y el esfuerzo para retroceder como consecuencia.

taxonomías de requisitos múltiples

Existen diversas taxonomías para los requisitos, dependiendo del marco de trabajo que se utilice (por ejemplo, los estándares establecidos por IEEE, IIBA o los enfoques del Departamento de Defensa de EE. UU.). Las diferencias en el lenguaje y los procesos en distintos entornos o en el lenguaje informal pueden generar confusión y desviaciones del proceso deseado.

Corrupciones de procesos

Un proceso dirigido por humanos está sujeto a fallos humanos en la gobernanza, donde la conveniencia, los deseos o la política pueden dar lugar a excepciones o a la subversión total del proceso y a desviaciones del procedimiento estándar. Algunos ejemplos son:

  • Un proceso sin rigor no recibe respeto. Si las excepciones o los cambios son frecuentes, como por ejemplo que la organización que lo gestiona tenga poca independencia o poder, o no sea fiable ni transparente en sus registros, esto puede llevar a que se ignore el proceso en su conjunto.
  • Nuevos participantes que desean una segunda oportunidad: por ejemplo, la tendencia natural de las personas nuevas a querer cambiar el trabajo de sus predecesores para demostrar su poder o sus pretensiones de valor, como un nuevo director ejecutivo que quiere cambiar la planificación del director ejecutivo anterior, incluidos los objetivos comerciales, de algo (como una solución de software) que ya está en desarrollo, o los objetos de oficina recién creados para el desarrollo actual de un proyecto porque no existían cuando se elaboraron los requisitos del usuario, por lo que comienzan un esfuerzo para retroceder y volver a establecer la línea base del proyecto.
  • Salirse de lo convencional: por ejemplo, los usuarios que desean tener más control no solo ingresan información que cumpla con la definición de "requisito del usuario" o el nivel de prioridad según la gestión de requisitos, sino que también insertan detalles de diseño o características del proveedor preferido como requisitos del usuario, o todo lo que su oficina considera de máxima prioridad.
  • Llegar tarde, por ejemplo, dedicar poco o ningún esfuerzo a la recopilación de requisitos antes del desarrollo. Esto puede deberse a que piensan que obtendrán el mismo beneficio independientemente de su participación individual, o que no tiene sentido si pueden simplemente añadir requisitos en la fase de pruebas y en la siguiente iteración, o a la preferencia por tener siempre la razón esperando la crítica posterior al trabajo.

Dentro del proceso del Departamento de Defensa de los Estados Unidos, algunos ejemplos históricos de problemas de requisitos son:

  • los problemas del M-2 Bradley con los requisitos informales del movimiento representados en Pentagon Wars ;
  • El crecimiento del F-16 a partir del concepto de caza ligero de la mafia de los cazas , atribuido al programa F-15 que intentó sabotear la competencia o a oficinas individuales que impusieron deseos locales que erosionaron el concepto de ser ligero y de bajo costo.
  • El entusiasmo surgido alrededor de 1998 por 'Net-Ready' llevó a que se le impusiera como Parámetro Clave de Rendimiento por parte de la oficina de Net-Ready, fuera del proceso de definición de requisitos de dicha oficina y sin ser coherente con el proceso previamente definido por esa oficina, su definición de lo que era un KPP, o que algunos esfuerzos podrían no ser apropiados o capaces de definir lo que constituía 'Net-Ready'.

Véase también

Referencias

  1. ↑ Forma y estilo de las normas, Libro Azul ASTM (PDF) . ASTM International . 2012. Archivado del original (PDF) el 6 de noviembre de 2015. Consultado el 5 de enero de 2013 .
  2. ↑ Boehm, Barry (2006). "Una visión de la ingeniería de software de los siglos XX y XXI" . Actas de la ICSE '06, 28.ª conferencia internacional sobre ingeniería de software . Universidad del Sur de California, Campus University Park, Los Ángeles, CA: Association for Computing Machinery, ACM, Nueva York, NY, EE. UU. pp. 12–29 . ISBN  1-59593-375-1. Consultado el 2 de enero de 2013 .
  3. ↑ "1.3 Conceptos clave - IIBA | Instituto Internacional de Análisis Empresarial" . www.iiba.org . Consultado el 25 de septiembre de 2016 .
  4. ↑ "IEEE SA - 610.12-1990 - Glosario estándar de terminología de ingeniería de software de IEEE" . Archivado del original el 10 de enero de 2011.
  5. ↑ Guía del Cuerpo de Conocimientos de Análisis Empresarial® (Guía BABOK®) Versión 2.0 . 2009. ISBN 978-0-9811292-1-1.
  6. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Caracterización de requisitos arquitectónicamente significativos". IEEE Software . 30 (2): 38– 45. doi : 10.1109/MS.2012.174 . hdl : 10344/3061 . S2CID 17399565 . 
  7. ↑ Ralph, P., y Wand, Y. Una propuesta para una definición formal del concepto de diseño. En Lyytinen, K., Loucopoulos, P., Mylopoulos, J. y Robinson, W. (eds.), Ingeniería de requisitos de diseño: una perspectiva de diez años: Springer-Verlag, 2009, pp. 103-136.
  8. ↑ Davis, Alan M. (1993). Requisitos de software: objetos, funciones y estados, segunda edición . Prentice Hall. ISBN 978-0-13-805763-3.
  9. ↑ IEEE Computer Society (1998). Práctica recomendada de IEEE para especificaciones de requisitos de software . Institute of Electrical and Electronics Engineers, Inc. ISBN 978-0-7381-0332-7.
  10. ↑ Stellman, Andrew; Greene, Jennifer (2005). Gestión de proyectos de software aplicados . O'Reilly Media. pág. 98. ISBN  978-0-596-00948-9Archivado del original el 9 de febrero de 2015.
  11. ↑ Wiegers, Karl E. (2003). Requisitos de software, segunda edición . Microsoft Press. ISBN 978-0-7356-1879-4.
  12. ↑ Young, Ralph R. (2001). Prácticas efectivas de requisitos . Addison-Wesley. ISBN 978-0-201-70912-4.
  13. ↑ Checkland, Peter (1999). Pensamiento sistémico, práctica sistémica . Chichester: Wiley.
  14. ↑ Ralph, Paul; Mohanani, Rahul (mayo de 2015). "¿Es la ingeniería de requisitos inherentemente contraproducente?" . Actas del 5.º Taller Internacional sobre los Dos Picos de los Requisitos y la Arquitectura . Florencia, Italia: IEEE. págs. 20-23 . 
  15. ↑ Jansson, D.; Smith, S. (1991). "Fijación del diseño". Design Studies . 12 (1): 3– 11. doi : 10.1016/0142-694X(91)90003-F .
  16. ↑ Purcell, A.; Gero, J. (1996). "Diseño y otros tipos de fijación". Design Studies . 17 (4): 363– 383. doi : 10.1016/S0142-694X(96)00023-3 .
  17. ↑ Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (mayo de 2014). "Fijación de requisitos" . Actas de la Conferencia Internacional sobre Ingeniería de Software . Hyderabad, India: IEEE. págs. 895–906 . 
  18. ↑ Ralph, Paul (2012). "La ilusión de los requisitos en el desarrollo de software". Requirements Engineering . 18 (3): 293– 296. arXiv : 1304.0116 . doi : 10.1007/s00766-012-0161-4 . S2CID 11499083 . 
  • Descubriendo los requisitos del sistema