IEEE 830

IEEE 830                                                  [emaze,2008]

La buena especificación de requerimientos es fundamental para el correcto desarrollo de la aplicación, la falta de herramientas  y negligencia de los encargados de este proceso es un obstáculo en el proceso eficiente de la ingeniería de requerimientos. El estándar IEEE 830-1998 está enfocado en recomendaciones prácticas para la especificación de requerimientos, fue desarrollado por la IEEE y la IEEE-SA (Standards Association), indica la estructura y organización de toda la información que debe incluirse en un buen documento de especificación de requerimientos de software. Los objetivos que tiene este estándar son: ayudar a los clientes a describir con precisión lo que quieren en el software y a las personas encargadas de recibir esta información establecer una estructura estándar (definir el formato y contenido de las especificaciones de requerimientos de software y manual del mismo) para la especificación de requerimientos de software (ERS) en sus organizaciones. La especificación de requerimientos de software obliga a los involucrados en el desarrollo del software a considerar todos los requerimientos de forma rigurosa antes de iniciar el diseño y codificación del mismo, con la finalidad de evitar el rediseño, proporcionando las bases necesarias para la estimación de tiempo y costo, referencias de verificación y validación, esto ayuda a tener una ventaja de utilizar una metodología (Bonilla Huerta, Ramírez Cruz, & Sánchez Lucero, 2014).

Estructura del documento:

• Introdución
• Descripciones Generales
• Especificaciones Requerimientos
• Información de soporte

La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe decirlas de una determinada manera. En este documento se presentará una de las formas que viene especificada por el estándar IEEE 830. Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no más de los necesarios. Esta documentación no debería describir ningún detalle de diseño, modo de implementación o gestión del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementación. Así pues, el grado y el lenguaje utilizado para la documentación de los requisitos estarán en función del nivel que el usuario tenga para entender dichas especificaciones.

Características de una buena ERS Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes [Chalmeta, 2000][Piattini, 1996]: · Correcta 

• No ambigua 
• Completa 
• Verificable 
• Consistente 
• Clasificada 
• Modificable 
• Explorable 
• Utilizable durante las tareas de mantenimiento y uso

Esquema de la ERS 

La siguiente figura muestra la estructura de la ERS propuesta por el IEEE en su estándar 830 [IEEE, 1998] [upm, 2000].

Estructura de una ERS                                         [zeus,2007]

Referencias: 

Bonilla Huerta, E., Ramírez Cruz, F., & Sánchez Lucero , E. (2014). Advances in Intelligent Information. LATINDEX, 17.

[IEEE, 1998]: IEEE
 Recommended practice for software requirements specification. Artículo obtenido de la web del instituto de ingenieros eléctricos y electrónicos (Institute of Electrical and Electronics Engineers).
 http://www.computer.org/

[thehath, 2000]:
 Sitio web con abundante información sobre análisis. http://www.thehathway.com/ [
upm, 2000]: 
Web de la universidad politécnica de Madrid, aparecen algunos artículos sobre la IEEE 830 y sobre análisis de requisitos en general. http://www.upm.com.

https://app.emaze.com/@ACWIQRLR#1