Calidad de los requisitos

1. Calidad de los requisitos Daniel Correa BoteroJosé López VélezUniversidad de Antioquia 2013-II

2. F. P. Brooks, 1987 Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir… No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difícil de rectificar a posteriori…

4. Problemas • Los usuarios no saben lo que quieren. • Los usuarios no poseen una visión global del sistema. • Los usuarios no saben detallar en forma precisa lo que necesitan. • Los usuarios no saben que parte de su trabajo o proceso puede transformase en software. • Los usuarios no saben como optimizar sus procesos y trabajar en conjunto.

5. Acumulación de errores

6. Costos en el ciclo de vida del Software

7. The Chaos Report 1995 • Gasto anual en EEUU: $250 mil millones en unos 175.000 proyectos. • 31,1% son cancelados • 52,7% cuestan un 190% más de lo estimado • Un 16,2% será finalizado a tiempo y dentro del presupuesto, pero el producto final poseerá (aprox.) la mitad de los requisitos iníciales Fuente: http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf

8. Toma de requisitos Los requisitos son metas, necesidades, objetivos. Identificación de problemas • Identificar los limites del desarrollo. • Identificar los actores. • Identificar las metas. • Identificar riesgos, reglas del negocio. Los sistemas deben apoyar objetivos de las organizaciones. (Diagrama de KAOS).

9. Técnicas para la toma de requisitos • Entrevistas • Utilizar documentos existentes • Brainstorming • Cuestionarios • Tarjetas

10. Entrevistas • Es el método “tradicional”, pero debe usarse en complemente con otras técnicas y no debe ser el primer paso para la educción. Es primordial: • Entrevistar a la(s) persona(s) adecuadas. • Preparar las preguntas con antelación. • Utilizar diagramas, modelos, etc.

11. Pasos generales para la toma de requisitos • Enumerar los requisitos. (SRS) • Comprender el contexto del sistema. (Modelo del dominio). • Capturar requisitos funcionales. (Casos de uso). • Capturar requisitos no funcionales. (Información adicional en los casos de uso).

12. Req funcionales y no funcionales • Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema. El sistema aceptará pagos con MASTERCARD. • Los requisitos no funcionales son restricciones sobre los requisitos funcionales. El sistema aceptará pagos con MASTERCARD de forma segura y con un tiempo de respuesta menor de 5 segundos.

13. Requisitos no funcionales • Seguridad • Usabilidad • Disponibilidad • Rendimiento • Portabilidad • Adaptabilidad • Testabilidad • Comprensibilidad

14. Enumeración de los requisitos • Suponga que hay que desarrollar un software para la construcción de una tienda virtual de ropa. ¿Requisitos? • El valor del dólar en Colombia es de 1947 pesos. • El sistema permitirá a los usuarios realizar búsqueda por precio, categoría y nombre. • El sistema mostrará alerta y prohibirá el ingreso a los usuarios cuando el sitio web este congestionado. • El sistema permitirá realizar pagos con MASTERCARD de forma segura y con un tiempo de respuesta menor a 0.5.

15. ¿Como escribir requisitos? • La mejor forma de escribir requisitos no existe. • Lo más utilizado es el lenguaje natural. Cada requisito expresado en una frases corta (“el sistema hará tal cosa...”, “se facilitará tal cosa...”, etc). • Se puede complementar el lenguaje natural con diagramas y/o notaciones formales • La notación utilizada depende de quien lee o quien escribe los requisitos.

16. ¿Como escribir requisitos? • Es importante decir lo que el sistema NO debe hacer. • Estos requisitos “en negativo” limitan el ámbito del sistema. • Dicen donde NO se deben emplear recursos.

17. Ambigüedad en la toma de requisitos De conjunciones o disyunciones: • El asesor o el administrador y el encargado de ventas pueden registrar directamente al usuario. De origen preposicional: • El asesor puede registrar al usuario en el departamento. De cuantificadores: • Cada asesor tiene asociado algún equipo de trabajo. • Dos administradores pueden registrar a un hombre en cada sede.

18. Ambigüedad en la toma de requisitos • Sentido 1: Existen sólo 2 administradores y existe sólo un hombre y los 2 admin pueden registrar al hombre en todas las sedes. • Sentido 2: Existen sólo dos administradores y existen sólo dos hombres y cada admin puede registrar a uno de los hombres en todas las sedes. • Sentido 3: Existen sólo dos admin y existen muchos hombres (uno en cada sede) y los dos admin pueden registrar a cada hombre en cada sede.

19. Ambigüedad en la toma de requisitos • Sentido 4: Existe sólo un hombre y existen muchos admin (dos en cada sede) y los dos admin de cada sede pueden registrar al mismo hombre. • Sentido 5: Existen muchos admin (dos en cada sede) y existen muchos hombres (uno en cada sede) y cada pareja de admin pueden registrar a un hombre en su sede. • Sentido 6: Existen muchos admin (dos en cada sede) y existen muchos hombres (dos en cada sede) y cada admin puede registrar a un hombre en su sede.

20. SRS (Software requirementsspecification) • Es una plantilla para la especificación de los requisitos del software. • Contiene la descripción completa del comportamiento de un sistema a ser desarrollado. • En algunos casos contiene un set de casos de uso.

21. Formato SRS - IEEE 830 • Introducción • Propósito • Alcance • Definiciones • Referencias • Visión General • Descripción General • Perspectiva y Funciones del producto • Características del usuario • Restricciones • Suposiciones

22. Formato SRS - IEEE 830 • Requisitos específicos 1 Requisitos comunes de los interfaces: Interfaces de usuario - Interfaces de hardware - Interfaces de software - Interfaces de comunicación 2 Requisitos funcionales 3 Requisitos no funcionales - Requisitos de rendimiento – Seguridad – Fiabilidad - Disponibilidad - Mantenibilidad - Portabilidad

23. Características de una SRS • No ambigua • Completa • Correcta • Comprensible • Verificable • Internamente Consistente • Externamente Consistente • Realizable • Concisa • Modificable • Electrónicamente almacenada • Organizada • Trazada

24. Enumeración de requisitos • En el desarrollo a gran escala, la obtención manual de requisitos es conocida por ser lenta y propensa a errores, y monótona. • En el estudio realizado por Mich et al. (2004) sobre las prácticas actuales de elicitación se enfatiza en la necesidad de brindar soporte avanzado automatizado a este proceso.

25. TES – Sistemas de elicitación de tareas • Se han hecho varios intentos para avanzar en este campo, sobre todo en la parte de (TES) (task elicitation systems) • Identificación de abstraciones (Gacitua et al. 2011; Goldin and Berry 1997; Kof2004; Rayson et al. 2000) • Identificación y clasificación de requisitos(Cleland-Huang et al. 2007; Casamayor et al. 2010; Kiyavitskaya and Zannone 2008) • Etiquetado.

26. Etiquetado de documentos • A continuación se muestra una conversación entre un analista y un interesado. • Se deben señalar los siguientes elementos: • Actores • Actividades • Datos • Requisitos no funcionales

27. ENT: Simplemente comience a explicar lo que sucede después de abrir la aplicación y lo que se puede hacer? INT: Bueno, en primer lugar, es importante que la aplicación se inicie rápidamente, así que no tengo que esperar mucho tiempo. Y una vez que se inicia la aplicación, quiero una rápida visión de los campos posibles, como por ejemplo: donde iniciar el viaje, donde terminar, por supuesto posible hora de empezar el viaje. Tal vez, alguna opción para seleccionar el tren. Saber si es un tren local o un tren rápido, que es muy importante. ¿Qué más? Tal vez, alguna opción para indicar si tengo algún bono de descuento o no. Para que el cálculo del precio actual ya este aplicado. Y después de que todo esto se introduce, quiero tener un gran botón para seguir adelante para ver las posibles conexiones. ENT: Muy bien. Ahora usted ha hecho clic en el botón y que sucede a continuación? INT: Bueno, después de que entré toda la información y luego hice clic en el botón, quiero ver las conexiones posibles. Todas las conexiones posibles. Y, por supuesto, sería útil que se muestren las conexiones en las cuales no tengo que cambiar de tren con mucha frecuencia. Esto se debería mostrar correctamente. Y, por supuesto, en una forma fácil de ver. Así que no es muy complejo para que pueda ver rápidamente todas las conexiones. Por supuesto, en una lista para que pueda desplazarse hacia abajo. INT: Después de eso quiero escoger una conexión. Tal vez podría ver más información para esa conexión. Como por ejemplo: la hora de inicio, hora de finalización y tal vez las conexiones posibles entre otras. Y después de haber seleccionado esto, quiero que salgan rápidamente las opciones de reserva.

28. Actividad 1 • Fecha de entrega: 18 de septiembre hasta las 11:59 pm Enviar a: udea@danielgara.com • Realizar el etiquetado de las siguientes 2 diapositivas (seleccionar actores, actividades, datos y requisitos no funcionales). Si el actor no esta escrito explícitamente, entonces se debe agregar. Se debe especificar a que categoría corresponde cada requisito no funcional. • Describir de que tipo de aplicación cree usted que están hablando las personas (no mas de 4 renglones). • Basado en el articulo ‘CHAOS Summary 2009’ Dar una breve explicación de cada 1 de las 10 leyes de CHAOS. (no mas de 4 renglones por ley).

29. ENT: Bueno, vamos a empezar. Simplemente explíqueme lo que sucede después de abrir la aplicación. INT: Después de abrir la aplicación, se muestra una bonita pantalla de bienvenida en la que puedo entrar en mi ubicación y mi destino. Mi Smartphone con suerte insertará mi posición actual y rellenará el primer campo de texto "Desde:", para que luego yo pueda llenar mi destino. Después de haber pulsado "enter", me sale una lista de las personas con carros que se dirigen a mi destino (en un lapso desde hoy, hasta los próximos 7 días). ENT: ¿Qué pasa si se hace clic en uno de ellos? INT: Algunos datos se muestran, como la fecha estimada de salida y la hora, posiblemente el precio que el conductor propone, y el coche o por lo menos el tipo de coche que tiene y cuántas personas hay a bordo en el momento. La ubicación exacta de salida también sería agradable. ENT: Bueno, ¿y qué sucede luego? INT: Con dar click en un botón el sistema contactaría inmediatamente a la persona por correo. Por ejemplo, el sitio web envía un correo electrónico con mis datos personales, por lo que la persona puede llamarme o escribirme un correo electrónico.

30. ENT: Ahora, después de contactar a la persona y finalmente hacer el viaje, ¿podría usted imaginar algunos pasos después, como un sistema de referencia? INT: Eso es una buena idea, se podría dar una retroalimentación, acerca de su forma de conducir o cómo fue el precio. Un sistema similar al sistema de referencia de ebay, sería genial, creo. ENT: ¿Podría especificar ese proceso? INT: Simplemente ingresar una calificación de uno a cinco y un campo de texto para dejar una nota. Esto podría llevarse a cabo en una lista en la aplicación. ENT: Suena bien. Y en general, ¿usted tiene algún requisito relativo a la interfaz de usuario y la usabilidad de la aplicación? INT: En realidad no, debe ser simple y clara, de modo que usted puede encontrar rápidamente las personas con coches que conducen al mismo tiempo a su destino. La misma situación, cuando yo soy el que ofrece un asiento en el coche. Un sencillo formulario con la fecha, desde, hacia, el tipo de coche, y listo. ENT: Bueno, creo que eso es todo. ¡Gracias!

31. Bibliografía • Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma. 2011. • UML y patrones. Craig Larman. 1999. • Learning UML 2.0 O’Reilly. 2006. • Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman. 2002. • Use Case DrivenObjectModelingwith UML, Theory and Practice. Doug Rosenberg. 2007. • Material Gonzalo Méndez, Alexander Mädche

32. Bibliografía • Gacitua, R., Sawyer, P., and Gervasi, V. (2011) “Relevance-based abstraction identification: technique and evaluation,” Requirements Engineering (16:3), pp. 251-265. • Goldin, L., and Berry, D. M. (1997) “AbstFinder, A Prototype Natural Language Text Abstraction Finder for Use in Requirements Elicitation,” Automated Software Engineering (4:4), pp. 375-412. • Kof, L. (2004) “Natural Language Processing for Requirements Engineering: Applicability to Large Requirements Documents,” in Proceedings of the 19th International Conference on Automated Software Engineering. • Rayson, P., Garside, R., and Sawyer, P. (2000) “Assisting requirements engineering with semantic document analysis,” in Proceedings of the RIAO, pp. 1363-1371. • Cleland-Huang, J., Settimi, R., Zou, X., and Solc, P. (2007) “Automated classification of non-functional requirements,” Requirements Engineering (12:2), pp. 103-120. • Casamayor, A., Godoy, D., and Campo, M. (2010) “Identification of non-functional requirements in textual specifications: A semi-supervised learning approach,” Information and Software Technology (52:4), pp. 436-445. • Kiyavitskaya, N., and Zannone, N. (2008) “Requirements model generation to support requirements elicitation: the Secure Tropos experience,” Automated Software Engineering (15:2), pp. 149-173.