Especificación de requisitos Ingeniería del Software II

Miembros BUTRAGUEÑO GUZMAN, David CERVERA RODRIGUEZ, Alejandro FLORES ACERAS, Jesús HIDALGO SALAMANCA, Raúl SANTOYO DE ANCOS, Andrés ZAMARREÑO JUANAS, Marcos

Índice 5. Calidad del software 1. Introducción. 2. Especificaciones de requisitos. 2.1Técnicas de obtención de requisitos 2.2Clasificación de requisitos 3. Características de una buena especificación. 4. Evolución de la especificación de requisitos 5. Calidad del software 6. Últimas plantillas de especificación estándares. 7. Conclusión. 8. Bibliografía.

1. Introducción Mediante la especificación de requisitos, se pretende poder establecer un diseño que se ajuste a los requerimientos solicitados por parte del cliente. Para realizar una buena especificación es indispensable que los requisitos estén bien localizados y clasificados. Además nuestra ERS debe ajustarse a las plantillas de IEEE como veremos más adelante.

2. Especificaciones de requisitos (Introducción) Las técnicas más habituales en la elicitación de requisitos son: las entrevistas, el Joint Application Development (JAD), el brainstorming o tormenta de ideas, y la utilización de escenarios, más conocidos como casos de uso

2.1 Especificaciones de requisitos (Entrevistas (I)) Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo ya que son una de las formas de comunicación más naturales entre personas.

2.1 Especificaciones de requisitos (Entrevistas (II)) Se componen de tres fases: preparación, realización y análisis. Preparación: Estudiar el dominio del problema Seleccionar las personas a las que se va a entrevistar Determinar el objetivo y contenido de la entrevista En definitiva, planificar la entrevista

2.1 Especificaciones de requisitos (Entrevistas (III)) Realización de la entrevista: Apertura: presentación de los miembros, que se espera de la entrevista, explicar el desarrollo. Desarrollo: No más de 2 horas, se deben evitar monólogos y no perder el control de la misma. Terminación: Recapitulación para confirmar que todo está claro y aclarar las dudas que surjan.

2.1 Especificaciones de requisitos (Entrevistas (IV)) Análisis de la entrevista Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, etc.

2.1 Especificaciones de requisitos (JAD (I)) La técnica denominada JAD (Joint Application Development, Desarrollo Conjunto de Aplicaciones), desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de 2 a 4 días.

2.1 Especificaciones de requisitos (Jad (II)) En estas reuniones se ayuda a los clientes y usuarios a formular problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del desarrollo.

2.1 Especificaciones de requisitos (JAD (III)) Esta técnica se base en cuatro principios: Dinámica de grupo uso de ayudas visuales para mejorar la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.) Mantener un proceso organizado y racional Una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se obtiene), por la que durante las reuniones se trabaja directamente sobre los documentos a generar.

2.1 Especificaciones de requisitos (JAD (IV)) Debido a las necesidades de organización que requiere y a que no suele adaptarse bien a los horarios de trabajo de los clientes y usuarios, esta técnica no suele emplearse con frecuencia. En general, obtiene buenos resultados en la elicitación de requisitos.

2.1 Especificaciones de requisitos (Brainstorming (I)) El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones de brainstorming suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el jefe de la sesión, encargado más de comenzar la sesión que de controlarla.

2.1 Especificaciones de requisitos (Brainstorming (II)) El brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de la elicitación, cuando los requisitos son todavía muy difusos.

2.1 Especificaciones de requisitos (Brainstorming (III)) Frente al JAD, el brainstorming tiene la ventaja de que es muy fácil de aprender y requiere poca organización. Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras técnicas.

2.1 Especificaciones de requisitos (Casos de uso (I)) Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente por Jacobson en 1993 y que actualmente forma parte de la propuesta de UML.

2. Especificaciones de requisitos (Casos de uso (II)) Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que la que los actores obtienen resultados observables. Los actores son personas u otros sistemas que interactúan con el sistema cuyos requisitos se están describiendo

2. Especificaciones de requisitos (Casos de uso (III)) Los casos de uso presentan ciertas ventajas sobre la descripción meramente textual de los requisitos funcionales, ya que facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios. Pueden servir de base a las pruebas del sistema y a la documentación para los usuarios.

2.1 Especificaciones de requisitos (Casos de uso (IV)) Los casos de uso tienen una representación gráfica en los denominados diagramas de casos de uso. Los actores se representan en forma de pequeños monigotes y los casos de uso se representan por elipses contenidas dentro de un rectángulo que representa al sistema.

2.1 Especificaciones de requisitos (Casos de uso (V)) Los diagramas de casos de uso sirven para proporcionar una visión global del conjunto de casos de uso de un sistema así como de los actores y los casos de uso en los que éstos intervienen. Las interacciones concretas entre los actores y el sistema no se muestran en este tipo de diagramas.

2.1 Especificaciones de requisitos (Casos de uso (VI)) En la mayoría de sistemas, el número de casos de uso es lo suficientemente elevado como para que sea oportuno organizarlos de alguna forma en lugar de tener una lista plana por la que no es fácil navegar. Una posible forma de organizar los casos de uso es recurrir a los paquetes descritos en la propuesta de UML.

2.2 Clasificación requisitos Requisitos funcionales Requisitos no funcionales Otros requisitos

2.2 Clasificación requisitos Requisitos funcionales Especifican la funcionalidad o servicio que la aplicación debe proporcionar. Depende del tipo de software, los usuarios esperados o el tipo de sistema donde el software esta siendo usado. Debe describir los servicios del sistema en detalle.

2.2 Clasificación requisitos Requisitos funcionales (Ejemplos) El usuario deberá ser capaz de buscar, ya sea todo el conjunto de la base de datos o un subconjunto de ella. El sistema proporcionara las herramientas necesarias para que el usuario pueda visualizar los documentos.

2.2 Clasificación requisitos Requisitos no funcionales Imponen restricciones en el producto desarrollado y en el proceso de desarrollo. Como debe realizar algo el software, no que debe realizar. Cortan transversalmente a los requisitos funcionales. Son negociables hasta cierto punto, dentro de limites aceptables.

2.2 Clasificación requisitos Requisitos no funcionales (Ejemplos) El interfaz de usuario debe estar implementado en HTML simple sin macros ni frames. El sistema no divulgarán ninguna información personal sobre los clientes, aparte de su nombre y el número de referencia a los operadores del sistema.

2.2 Clasificación requisitos Otros requisitos Requisitos inversos : son aquellos que la aplicación no debe cumplir (son infinitos) . Estos tienen las siguientes funciones: Pueden aclarar posibles malentendidos, el alcance del sistema. Seleccionar mejor aquellos que sirven para aclarar los verdaderos requisitos.

2.2 Clasificación requisitos Otros requisitos Requisitos de dominio : derivados de la aplicación de dominio, de la descripción de las características de los sistemas y características que reflejan el dominio. Si los requisitos de dominio no se cumplen, el sistema puede ser inviable.

2.2 Clasificación requisitos Otros requisitos Requisitos de usuario: debe describir requisitos funcionales y no funcionales, de tal manera que sean comprensibles por los usuarios del sistema que no tienen el conocimiento técnico detallado.

3.Características de una buena ERS Correcta No ambigua Completa Verificable Consistente Clasificada Fácil de modificar Identificable Utilizable durante las tareas de mantenimiento y uso

3.Características de una buena ERS Correcta Reflejar alguna necesidad real. No disponemos de una herramienta que nos asegure la exactitud de la ERS.

3.Características de una buena ERS No ambiguo Lenguaje natural puede llegar a ser muy ambiguo. Cada requisito declarado sólo puede tener una interpretación. Ejemplo: Todos los clientes tienen el mismo campo de control Todos los clientes tienen el mismo valor en el campo de control. Todos los campos de control tienen el mismo formato. Un campo de control se usa para todos los clientes.

3.Características de una buena ERS Completo Existe una definición de respuestas a todas las posibles entradas. Cumple con el estándar utilizado. Incluye todos los requisitos significativos del software. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc.

3.Características de una buena ERS Verificable. Cada requisito de los que en ella han sido declarado puede ser comprobable. No usar “bien”, “bueno”, “normalmente”. Ejemplo: No verificable El producto debería funcionar bien. Verificable La salida se suministrará dentro de los 20 segundos siguientes al evento el 60% de las veces, y en 30 segundos siguientes el 100% de las veces.

3.Características de una buena ERS Consistente Ningún conjunto de requisitos descritos en ella son contradictorios y entran en conflicto. Puede existir conflicto lógico o temporal entre dos acciones especificadas. un requisito puede declarar que “A” siempre debe seguir “B”, mientras otro puede requerir que “A” y B" ocurran simultáneamente.

3.Características de una buena ERS Clasificación No todos los requisitos de una ERS son igual de importantes, por eso deben de ser clasificados. Clasificados por: Importancia: Pueden ser esenciales, condicionales u opcionales. Estabilidad: Cambios que pueden afectar al requisito.

3.Características de una buena ERS Modificable puede hacerse cualquier modificación en los requisitos de manera fácil, completa y de forma consistente . Características: No ser redundante Buena organización de la información, índices, referencia cruzadas explicitas. Exprese cada requisito separadamente.

4. Evolución de la especificación de requisitos La ERS puede necesitar evolucionar Para realizar una buena especificación es indispensable que los requisitos estén bien localizados y clasificados. Es casi imposible especificar todos los requisitos al detalle, en el momento en el que el proyecto se inicia . Los cambios van surgiendo según avanza el proceso del proyecto.

4. Evolución de la especificación de requisitos (II) Dos consideraciones a tener en cuenta: Especificar los requisitos como son conocidos en el momento de su captura. Se debe especificar formalmente el cambio mediante: Identificación Control Informe

5. Calidad del Software ¿Qué es la calidad? Fuentes de baja calidad La totalidad de características y atributos de un producto o servicio, que están relacionados con satisfacer necesidades expresas o implícitas Fuentes de baja calidad Requisitos imprecisos Requisitos mal entendidos Requisitos incompletos

5. Calidad del software (II) La mayor fuente de baja calidad es la falta de claridad en los requisitos. La definición correcta de los requisitos, puede ser vital para la implementación del proyecto.

5. Calidad del software (III) Consecuencias de una definición de requisitos pobre No podemos demostrar que hemos logrado los objetivos que se establecieron en un principio. No podemos demostrar que no hemos logrado los objetivos. No podemos evaluar las alternativas de diseño. Se termina especificando el medio y no los fines. Si hay más de una forma de expresar un objetivo, tal vez no es un objetivo sino un medio para lograrlo.

6. Últimas plantillas de especificación estándares Estándar IEEE 830 - 1998 1 Introducción 1.1 Propósito 1.2 Ámbito del Sistema 1.3 Definiciones, Acrónimos y Abreviaturas 1.4 Referencias 1.5 Visión general del documento 2 Descripción General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Características de los usuarios 2.4 Restricciones 2.5 Suposiciones y Dependencias 2.6 Requisitos Futuros 3 Requisitos Específicos 3.1 Interfaces Externas 3.2 Funciones 3.3 Requisitos de Rendimiento 3.4 Restricciones de Diseño 3.5 Atributos del Sistema 3.6 Otros Requisitos 4 Apéndices 5 Índice Diferentes plantillas según el punto de vista del apartado 3

6. Últimas plantillas de especificación estándares (II) Según “Requisitos específicos”: Organizados por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Organizados por objetos: Los objetos son entidades del mundo real que son reflejadas en el sistema. Organizados por clase de usuario. Distintos usuarios poseen distintos requisitos. Organizados por la jerarquía funcional: La funcionalidad del sistema se especifica como una jerarquía de funciones que comparten entradas, salidas o datos del propio sistema. Organizados por: estímulos, exhibición de organizaciones múltiples …

6. Últimas plantillas de especificación estándares (III) Apoyo a la especificación: casos de uso Por cada caso de uso proporcionado por el sistema (producto o servicio a desarrollar) se rellenarán los campos de la tabla

6. Últimas plantillas de especificación estándares (IV) Apoyo a la especificación: especificación de escenarios: Cada caso de uso puede contener uno o varios escenarios que también son descritos siguiendo una plantilla representada de forma tabular

7. Conclusión Del buen reconocimiento y clasificación de nuestros requisitos dependerá en gran medida el éxito de la ERS. La ERS deberá sernos útil durante todo el ciclo de vida de nuestro proyecto adaptándose a los cambios que este sufra.

7. Conclusión (II) Gracias a una buena ERS podremos hacer de nuestro proyecto una obra con unas altas posibilidades de ser de calidad y además fácilmente modificable Permite una más fácil y pronta incorporación al desarrollo del proyecto a un miembro recién incorporado al equipo.

8. Bibliografía [1] http:/es.wikipedia.org/wiki/IEEE [2] https://www.tractis.com/templates/4643983 18 [3] http://www.scribd.com/doc/102017/Plantilla -Especificacion-de-Proceso [4] http://www.lsi.us.es/docencia/pagina_asigna tura.php?id=48