stringtranslate.com

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

Orígenes del término

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:

  1. Una condición o capacidad que necesita una parte interesada para resolver un problema o lograr un objetivo.
  2. Una condición o capacidad que debe cumplirse o poseer una solución o un componente de 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 IEEE de terminología de ingeniería de software. [4]

Requisitos de producto versus requisitos de proceso

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

Tipos de requisitos

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 Empresarial en su Business Analysis Body of Knowledge [5] (consulte también FURPS y Tipos de requisitos ).

Requisitos arquitectónicos
Los requisitos arquitectónicos explican lo que debe hacerse identificando 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 denominan 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 empresariales
Declaraciones de alto nivel de las metas, objetivos o necesidades de una organización. Por lo general, describen oportunidades que una organización desea concretar o problemas que desea resolver. Suelen formularse en un caso de negocio .
Requisitos de los usuarios (partes interesadas)
Declaraciones de nivel medio de las necesidades de una parte interesada o un grupo de partes interesadas en particular. Por lo general, describen cómo alguien desea interactuar con la solución prevista. A menudo actúan como un punto intermedio entre los requisitos empresariales de alto nivel y los requisitos de la solución más detallados.
Requisitos funcionales (de solución)
Por lo general, son declaraciones detalladas de las capacidades, el comportamiento y la información que necesitará la solución. Algunos ejemplos incluyen el formato de texto, el cálculo de un número o la modulación de una señal. A veces también se las conoce como capacidades .
Requisitos de calidad del servicio (no funcionales)
Por lo general, son declaraciones detalladas de las condiciones bajo las cuales la solución debe seguir siendo efectiva, las cualidades que debe tener la solución o las restricciones dentro de las cuales debe operar. [7] Algunos ejemplos incluyen: confiabilidad, capacidad de prueba, mantenibilidad, disponibilidad. También se conocen como características , restricciones o ilidades .
Requisitos de implementación (transición)
Por lo general, las declaraciones detalladas de capacidades o comportamientos solo se requieren para permitir la transición del estado actual de la empresa al estado futuro deseado, pero que luego ya no serán necesarias. Algunos ejemplos incluyen la contratación, los cambios de funciones, la educación, 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 (a nivel de empresa, departamental o de proyecto).

Características de los buenos requisitos

Los distintos autores enunciaron las características de los buenos requisitos de distintas maneras, y cada uno de ellos generalmente destacó 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 la 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.

Verificación

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

  1. tardan mucho tiempo en producirse, a veces hasta el punto de quedar obsoletos una vez terminados
  2. limitar las opciones de implementación disponibles
  3. Son costosos de producir

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 .

Requisitos de documentación

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 .

Cambios en los requisitos

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 .

Asuntos

Normas en competencia

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.

Disputas sobre 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] 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 .

Los requisitos aumentan

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

Taxonomías de requisitos múltiples

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.

Corrupciones de procesos

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:

Véase también

Referencias

  1. ^ Forma y estilo de las normas, Libro Azul de ASTM (PDF) . ASTM International . 2012 . 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 28.ª conferencia internacional sobre ingeniería de software ICSE '06 . Universidad del Sur de California, Campus de University Park, Los Ángeles, CA: Association for Computing Machinery, ACM Nueva York, NY, EE. UU., págs. 12-29. ISBN 1-59593-375-1. Recuperado 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 IEEE de terminología de ingeniería de software". Archivado desde el original el 10 de enero de 2011.
  5. ^ Iiba; Análisis, Instituto Internacional de Negocios (2009). Guía del conjunto de conocimientos sobre análisis empresarial® (Guía BABOK®) Versión 2.0. ISBN 978-0-9811292-1-1. {{cite book}}: |first2=tiene nombre genérico ( ayuda )
  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, págs. 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 por el IEEE para especificaciones de requisitos de software . Instituto de Ingenieros Eléctricos y Electrónicos, Inc. ISBN 978-0-7381-0332-7.
  10. ^ Stellman, Andrew; Greene, Jennifer (2005). Gestión de proyectos de software aplicado. O'Reilly Media. pág. 98. ISBN 978-0-596-00948-9. Archivado desde el 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 de requisitos eficaces. 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). "¿La ingeniería de requisitos es inherentemente contraproducente?". Actas del 5.º taller internacional sobre los dos picos de los requisitos y la arquitectura . Florencia, Italia: IEEE. pp. 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". Ingeniería de requisitos . 18 (3): 293–296. arXiv : 1304.0116 . doi :10.1007/s00766-012-0161-4. S2CID  11499083.

Enlaces externos