Daniel Correa Botero
José López Vélez
Universidad de Antioquia 2013-II
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…





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.

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
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).





Entrevistas
Utilizar documentos existentes
Brainstorming
Cuestionarios
Tarjetas

-
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.




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).

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.








Seguridad
Usabilidad
Disponibilidad
Rendimiento
Portabilidad
Adaptabilidad
Testabilidad
Comprensibilidad

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.




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.



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.
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.



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.



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.



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.
Introducción
• Propósito • Alcance • Definiciones •
Referencias
• Visión General

Descripción General
• Perspectiva y Funciones del producto
• Características del usuario
• Restricciones • Suposiciones


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








No ambigua
Completa
Correcta
Comprensible
Verificable
Internamente
Consistente
Externamente
Consistente
Realizable





Concisa
Modificable
Electrónicamente
almacenada
Organizada
Trazada


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.

•
•
•
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; Kof 2004; 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.


•
•
•
•
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
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.




Fecha de entrega: 18 de septiembre hasta las 11:59 pm
Enviar a: [email protected]
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).
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.
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!






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 Driven Object Modeling with UML,
Theory and Practice. Doug Rosenberg. 2007.
Material Gonzalo Méndez, Alexander Mädche







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.
Descargar

¿Requisitos? - Daniel Gara