Want to create interactive content? It’s easy in Genially!
Especificación de Requisitos según la norma IEEE 830
Ruiz García Itzi Mariana
Created on February 20, 2024
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Audio tutorial
View
Pechakucha Presentation
View
Desktop Workspace
View
Decades Presentation
View
Psychology Presentation
View
Medical Dna Presentation
View
Geometric Project Presentation
Transcript
Especificación de Requisitos según la norma IEEE830
Unidad 1
Grupo: 6SA Profesora: Diaz Sarmiento Bibiana
Ingeniería de Software Alumna: Ruiz García Itzi Mariana
índice
INGENIERÍA DE SOFTWARE
Introducción - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3
IEEE, Estandar y requerimiento- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4
Historia del estandar IEEE 830 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6
Caracteristicas de la ERS segun el estandar IEEE 830 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8
Estructura de la ERS segun el estandar IEEE 830 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 9
Conclusión - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10
Referencias - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11
El establecimiento de los requisitos para el desarrollo de software juega un papel muy importante pues es la base para comprender, documentar y gestionar las necesidades y expectativas de los usuarios finales. Es por esto existe el IEEE 830 que es utilizado como guía a la hora de la creación de los mismos, proporcionando la estructura para la especificación de requisitos de software. Esta presentación se enfoca en analizar el estándar IEEE 830, estudiando su historia, estructura y algunas características para el éxito de los proyectos de desarrollo de software. En resumen, esta investigación tiene como objetivo proporcionar una visión informada del estándar IEEE 830 y su papel en el proceso de la creación de requisitos de software, destacando su estructura y características para garantizar la entrega de sistemas de software de alta calidad que satisfagan las necesidades y expectativas de los usuarios finales.
INTRODUCCIÓN
Según el mismo IEEE, es la asociación de profesionales más grande del mundo dedicado a la promoción de la innovación tecnológica y excelencia en beneficio de la humanidad. IEEE y sus miembros inspiran una comunidad global a través de sus publicaciones muy citadas, conferencias, estándares de tecnología y actividades profesionales y educativas (IEEE, 2010, como se citó en Borja & Cuji, 2013)
¿Qué es un estándar?
Borja & Cuji (2013) conceptualizan a Estándar como la definición clara de un modelo, criterio, regla de medida o de los requerimientos mínimos aceptables para la operación de procesos específicos, con el fin de asegurar la calidad.
¿Qué es IEEE?
Según la IEEE “un requerimiento es una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal” (Diéguez, Sepúlveda, Canullan, 2010)
El estándar 830-1998 fue generado por el Institute of Electrical and Electronics Engineers (IEEE), consiste en la integración de los requerimientos de un sistema desde la perspectiva de los actores involucrados en su diseño, desarrollo y utilización: usuario, cliente y desarrollador.
(Diéguez, Sepúlveda, Canullan, 2010)
Historia del estandar
ieee 830
La IEEE publicó un conjunto de guías y recomendaciones para escribir especificaciones de requerimientos de software. Este documento, conocido como estándar IEEE 830 (Software Engineering Standards Committee of the IEEE Computer Society, 1998) (Software Engineering Standards Committee of the IEEE Computer Society, 1998), fue revisado por última vez en el año 1998. Las recomendaciones de la IEEE incluyen tópicos como organización del documento de especificación de requerimientos, el rol de los prototipos, y las características que debe poseer un buen requerimiento. (Izarrualde,2013)
Una de las características más distinguibles del estándar IEEE 830 (Software Engineering Standards Committee of the IEEE Computer Society, 1998) (Software Engineering Standards Committee of the IEEE Computer Society, 1998) es que los requerimientos deben ser escritos de la siguiente manera: “El sistema debe…”.
A continuación, se muestra un fragmento de una especificación de requerimientos de software según el estándar IEEE 830 (Cohn, What stories are not, 2009, como lo cito Izarrualde,2013):
La documentación de los requerimientos del software a este nivel es tediosa, propensa a errores y consume mucho esfuerzo de armado (Cohn, What stories are not, 2009). Por otro lado, los documentos de especificación de requerimientos escritos de esta manera son muy difíciles de leer.
El sistema debe permitir a las compañías pagar con tarjetas de crédito por el servicio de ofertar trabajos.
X.1
El sistema debe entregar un número de confirmación único.
X.1.3
El sistema debe cargar el pago en la tarjeta de crédito antes de publicar la oferta de trabajo en el sitio.
X.1.2
El sistema debe aceptar las siguientes tarjetas de crédito: Visa, MasterCard y American Express.
X.1.1
CaracterísticaS
de una buena ERS
consistente
correcta
clasificada
no ambigua
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)(Agut,2001):
modificable
completa
explorable
verificable
Utilizable durante las tareas de mantenimiento y uso
La estructura de la Especificacion de Requisitos de Software (ERS) propuesta por el IEEE en su estándar 830 es la siguiente:
(IEEE, 1998) (upm, 2000) (Agut,2001)
3. Requisitos Específicos
1. Introducción
1.1. Propósito
3.1. Interfaces Externas
1.2. Ámbito del Sistema
3.2. Funciones
1.3. Definiciones, Acrónimos y Abreviaturas
3.3. Requisitos de Rendimiento
1.4. Referencias
3.4. Restricciones de Diseño
1.5. Visión general del documento
3.5. Atributos del Sistema
3.6. Otros Requisitos
2. Descripción General
4. Apéndices
2.1. Perspectiva del Producto
2.2. Funciones del Producto
5. Índice
2.3. Características de los usuarios
2.4. Restricciones
2.5. Suposiciones y Dependencias
2.6. Requisitos Futuros
Conclusión
En conclusión, el estándar IEEE 830 proporciona una estructura y metodología crucial para el proceso de establecimiento de requisitos para el desarrollo de software, lo que resulta fundamental en el desarrollo de sistemas. A través de su enfoque en la corrección, no ambigüedad, completitud, verificabilidad, consistencia, clasificación, modificabilidad, explorabilidad y facilidad de mantenimiento, este estándar garantiza que los requisitos sean claros, comprensibles y gestionables a lo largo del ciclo de vida del software. Esta investigación ha proporcionado una visión profunda del estándar, examinando su historia, estructura y características clave para el éxito de los proyectos de desarrollo de software. Al proporcionar una estructura y metodología para la especificación de requisitos de software, el IEEE 830 facilita la comprensión, documentación y gestión de las necesidades y expectativas de los usuarios finales. Con una comprensión informada del estándar IEEE 830, los profesionales de la industria pueden garantizar la entrega de sistemas de software de alta calidad que satisfagan las necesidades y expectativas de los usuarios finales de manera efectiva y eficiente.
Además, la documentación de requisitos siguiendo estas directrices permite una mejor comunicación entre los diferentes actores involucrados en el desarrollo de software y facilita el proceso de diseño, implementación y evaluación de sistemas de software. En resumen, la adopción del estándar IEEE 830 contribuye significativamente al éxito de los proyectos de desarrollo de software al proporcionar una base sólida para la creación de sistemas de alta calidad que cumplan con las necesidades y expectativas de los usuarios finales.
REFERENCIAS
Agut, R. M. (2001). Especificación de Requisitos Software según el estándar de IEEE 830. Universidad Jaume I. Departamento de Informática. Paper.
Ieee 830. (2016). SlideShare; Slideshare. https://es.slideshare.net/amerino2010/ieee-830
Aguilar, N. I. Z., Valdés, Á. A., Verdín, K. C., & Arriaga, J. C. P. (2014). Especificación de requerimientos con Áncora y el estándar 830. Res. Comput. Sci., 79, 109-119.
Borja Buestán, C. D., & Cuji Torres, V. A. (2013). Metodología para la especificación de requerimientos de software basado en el estándar IEEE 830-1998 (Bachelor's thesis).
Izaurralde, M. P. (2013). Caracterización de Especificación de Requerimientos en entornos Ágiles: Historias de Usuario. Trabajo de especialidad, Febrero.
Diéguez, M., Sepúlveda, S., & Canullan, D. (2010). Diseño de un documento para la Elicitación y Especificación de requerimientos: Caso práctico. In WorkShop International EIG (Vol. 11).
COMPLETITUD
Una ERS es completa si:
• Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas). • Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.
• Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente por qué no se ha utilizado dicho apartado. • Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.
La ERS debe ser siempre completa, aunque en ocasiones esto no será posible. Por ejemplo, si todavía no se han determinado los formatos de los informes finales o por cualquier razón se está esperando la publicación de un Real Decreto o un reglamento sobre impuestos.
CORRECIÓN
La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.
Clasificación
No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios:
- Importancia: Pueden ser esenciales, condicionales u opcionales.
- Estabilidad: Cambios que pueden afectar al requisito.
Utilizable durante las tareas de mantenimiento y uso
En la ERS también se deben tener en cuenta las necesidades de mantenimiento. El personal que no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su mantenimiento. Así, dicha ERS actúa a modo de plano de la aplicación, permitiendo incluso modificaciones que no requieran un cambio en el diseño. En ocasiones, el equipo de desarrollo supone unos conocimientos que el personal que se encargue del mantenimiento no tiene por qué tener. Por esta razón es necesaria una correcta documentación de las funciones, ya que, si no se conoce en detalle su origen, difícilmente podrán ser modificadas.
Verificabilidad
Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual una persona o una máquina pueda chequear que el software satisface dicho requerimiento. No verificables: * El producto debería funcionar bien * El producto debería tener una buena interfaz de usuario Verificable: La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100%
MODIFICABILIDAD
Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente. Para ello, es deseable tener una organización coherente y fácil de usar en la que aparezca el índice o una tabla de contenidos fácilmente accesible. También es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en más de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa será mucho más cómodo si no tenemos que buscar el mismo requisito en varios lugares.
AMBIGÜEDAD
Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación. Cada característica del producto final debe ser descrita utilizando un término único y, en caso de que se utilicen términos similares en distintos contextos, se deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado específicamente.
Los analistas deben poner un cuidado especial a la hora de especificar los requisitos. El hecho de utilizar el lenguaje natural para hacer la ERS comprensible a los usuarios supone un riesgo muy elevado, porque el lenguaje natural puede llegar a ser muy ambiguo.
En términos generales, el lenguaje natural es de los más ambiguos. Por el contrario, existen los lenguajes formales que no son ambiguos, pero son más difíciles de aprender y menos comprensibles para el que no los conoce.
Ejemplo:
Todos los clientes tienen el mismo campo de control 1.- ¿Todos tienen el mismo valor en el campo de control? 2.- ¿Todos los campos de control tienen el mismo formato? 3.- ¿Un campo de control se usa para todos los clientes?
Explorabilidad (traceability)
Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito). Cuando un requisito de la ERS representa un desglose o una derivación de otro requisito, se debe facilitar tanto las referencias hacia atrás como hacia adelante en el ciclo de vida. Las referencias hacia delante de la ERS son especialmente importantes para el mantenimiento del software. Cuando el código y los documentos son modificados, es esencial poder comparar el conjunto total de requisitos que puedan verse afectados por estas modificaciones.
Consistencia
Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella es contradictorio o entran en conflicto. Se pueden dar tres casos:
- Requisitos que describen el mismo objeto real utilizando distintos términos.
- Las características especificadas de objetos reales. Un requisito establece que todas las luces son verdes y otro que son azules.
- Conflicto lógico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones serían perfectamente válidas (¿sumar o multiplicar?)
Esta subsección debe relacionar el futuro sistema con otros productos. Así pues, podríamos dividir ésta en pequeñas subsecciones indicando cada uno de los puntos a tener en cuenta:
2.1.1. Indicar si es un producto independiente o parte de un sistema mayor 2.1.2. Interfaces de sistema 2.1.3. Interfaces de usuario 2.1.3.1. Características lógicas del interfaz 2.1.3.2. Cuestiones de optimización del interfaz de usuario 2.1.4. Interfaces hardware 2.1.5. Interfaces software 2.1.5.1. Descripción del producto software utilizado 2.1.5.2. Propósito del interfaz 2.1.5.3. Definición del interfaz: contenido y formato 2.1.6. Interfaces de comunicaciones 2.1.7. Limitaciones de memoria
2.1.8. Operaciones2.1.8.1. Modos de operación de los distintos grupos de usuarios2.1.8.2. Periodos de operaciones interactivas y automáticas2.1.8.3. Funciones respaldo del procesamiento de datos2.1.8.4. Operaciones de backup y recuperación2.1.9. Requerimientos para adaptarse a la ubicación2.1.9.1. Indicar cualquier dato o secuencia de inicialización específico de cualquier lugar, modo de operación.2.1.9.2. Características que deben ser modificadas para una instalación en particular.