Académique Documents
Professionnel Documents
Culture Documents
13 14
Documenta
„
Ingeniería de Requerimientos (IR) - es el Analizar el Describir el Prototipos
ción y
problema problema y pruebas
proceso de Validación
‰
encontrar, •Entrevistar •Documentar. ¿Responde a las
•¿Capturamos necesidades? ¿Hemos
‰
analizar, •Usar técnicas.
capturado todo
todo lo que el
documentar y usuario necesita?
•Verificar con lo que el usuario
‰ el usuario. espera?
‰
chequear los requerimientos ¿Hay
contradicciones?.
15 16
17 18
32
Estudiar el Estudiar el Problema
Problema
La extracción de requerimientos es crítica: se debe
„
„
Se trabaja con el cliente y los usuarios para
analizar el problema antes de considerar cualquier identificar los requerimientos del sistema:
solución posible.
Formulando preguntas: entrevistar a los distintos
„ Es importante desglosar el problema en piezas más ‰
usuarios del sistema.
pequeñas más fáciles de comprender, un principio
Estudiando el sistema actual: puntos fuertes y
fundamental para la resolución de problemas. ‰
puntos débiles.
„ En la etapa de análisis del problema se trabaja para:
‰
Estudiando el comportamiento de sistemas
‰ Identificar las personas, los procesos y recursos similares.
involucrados.
Desarrollando prototipos.
‰ Documentar las relaciones entre ellos. ‰
19 20
21 22
23 24
4
Consejos prácticos - Entrevistas Consejos Prácticos
Consejos para la de extracción y análisis de
„
Durante la entrevista: requerimientos:
‰
Mantener la entrevista en foco. „ Revisar la situación actual.
Solicitar ejemplos de documentos fuentes, salidas „ Trabajar en el ámbito del usuario para comprender el
‰
del sistema, pantallas. contexto, los problemas y las relaciones.
Definir compromisos. „ Entrevistar a los usuarios actuales y potenciales.
‰
25 26
Análisis de Documentos de
requerimientos
„ ¿Los requerimientos son correctos? Cliente y analista
requerimientos
„
deben revisarlos. a dos propósitos diferentes, pero
¿Los requerimientos son consistentes? No poseen La extracción y el análisis del problema sirveReq_del_usuario
„ relacionados:
inconsistencia ni ambigüedades.
‰ La extracción permite escribir un documento de
„ ¿Los requerimientos son completos? Se consideraron definición de requerimientos (términos que el
todos los estados, entradas, productos y restricciones. cliente entiende).
¿Los requerimientos son realistas? Es posible cumplir
„ La extracción y el análisis permiten escribir la
con los requerimientos. ‰
especificación de requerimientos (términos
„ ¿Describe cada requerimiento algo que es necesario? técnicos, que habilita el diseño del sistema).
Existen requerimientos que se puedan eliminar
¿Los requerimientos son verificables? Se necesitan Req_del_sistema
„
pruebas que los demuestren „
A veces un único documento sirve para
ambos propósitos.
27 28
Documentar Documentar
requerimientos Requerimientos
„ Deben describirdel
Requerimientos losUsuario
requerimientos funcionales y no Son más detallados que los requerimientos de
Requerimientos
„ del sistema:
funcionales de manera entendible para el usuario y usuario, por lo que la especificación en lenguaje
sin especificar conocimiento técnico. natural no se aconseja por los siguientes
„ Usar lenguaje claro y simple, acompañado de problemas:
tablas, formularios y diagramas intuitivos. Confía que lectores y escritores usan las mismas
‰
„ Problemas de los requerimientos de usuario: palabras para los mismos conceptos.
‰ Falta de claridad: el lenguaje natural no es preciso. Es demasiado flexible: existen muchas maneras
‰
‰ Confusión entre requerimientos funcionales y no
de decir lo mismo.
funcionales.
Requerimientos compuestos: varios requerimientos se ‰
Es difícil de modularizar y de mantener los
‰
29 30
5
Requerimientos del sistema - Lenguaje natural
Notación Estructurado
Patrón para documentar
„ „ Ventajas de usar Patrones:
„ Lenguaje natural estructurado: definir patrones requerimientos: los
Algunas variantes de notación: ‰ Aseguran la descripción
para expresar la especificación de requerimientos. requerimientos deben completa de los
contar con las siguientes requerimientos.
„ Usar notación gráfica: usar un lenguaje gráfico
secciones: Normalizan la forma de
acompañado con texto para definir los ‰
‰ Identificador. trabajo.
requerimientos del sistema. Categoría.
‰
‰ Es más simple de
‰ Ejemplos: diagramas de casos de uso, diagramas de mantener.
‰ Descripción corta.
secuencia. Vam os a
ar Descripción detallada.
tr ab aj ‰
31 32
33 34
Ejemplo: Requerimientos
R qu rimient de S stem
Funcionales
a
„
libros disponibles por distintos parámetros de búsqueda.
„ Registrar pedidos de compra: el usuario ingresará el o los
libros que desea adquirir. El sistema guarda el pedido e
informa al cliente el número de transacción.
„ Procesar pedidos del día: la base de pedidos del día se
envía al sistema de ventas.
35 36
6
Análisis de Requerimientos Requerimientos no
funcionales
„ El sistema VEMB vía Internet debe cumplir con las
¿Están todos los requerimientos funcionales siguientes restricciones:
„
definidos? ‰ Debe funcionar las 24 hs.
‰ Debe ser capaz de correr en las plataformas más comunes
„
¿Se le ocurre algún otro requerimiento disponibles en el mercado.
funcional? ‰ Debe ser capaz de atender 100 usuarios concurrentemente
consultando y/o cargando pedidos correctamente.
‰ En relación con el subsistema de pedidos por Internet, debe
definirse una interfaz capaz de comunicarse con el Sistema
de pedidos por gestión.
‰ Debe trabajar conectado al servidor de base de datos con el
que están conectadas el resto de las aplicaciones.
37 38
41 42
7
Funcionalidad y Datos
Documentación „ ¿Cuál será el formato de los datos tanto para entrada
„ Funcionalidad
como para salida?
‰ ¿Qué hará el sistema?
‰ ¿Cuándo lo hará? „ ¿Cuán a menudo serán recibidos o enviados?
‰ ¿Existen varios modos de operación? „ ¿Cuán exactos deben ser?
‰ ¿Cómo y cuándo se puede cambiar o mejorar un sistema? „ ¿Con qué grado de precisión deben hacerse los
‰ ¿Existen restricciones de la velocidad de ejecución, cálculos?
tiempo de respuesta o rendimiento? ¿Cuántos datos fluyen a través del sistema?
„
„ Documentación ¿Debe retenerse algún dato por algún período de
„
‰ ¿Cuánta documentación se requiere? tiempo?
‰ ¿Debe estar en línea, en papel, o en ambos?
‰ ¿A qué audiencia está orientado cada tipo de
información?
43 44
Recurso Segurida
s ¿Qué recursos materiales, personales o de otro tipo d
„ „ ¿Debe controlarse el acceso al sistema o a la
se requieren para construir, utilizar y mantener el información?
sistema? „ ¿Cómo se podrán aislar los datos de un usuario de los
„ ¿Qué habilidades deben tener los desarrolladores? de otros?
„ ¿Cuánto espacio físico será ocupado por el sistema? „ ¿Cómo podrán aislarse los programas de usuario de los
¿Cuáles son los requerimientos de energía, otros programas y del sistema operativo?
„
calefacción o acondicionamiento de aire? „ ¿Con qué frecuencia deben hacerse las copias de
¿Existe un cronograma prescripto para el desarrollo? respaldo?
„
„ ¿Dónde se almacenarán las copias de respaldo?
„ ¿Existe un límite sobre la cantidad de dinero a gastar
en el desarrollo o en hardware o en software? „ ¿Se deben tomar precauciones contra el fuego, el daño
provocado por agua, o el robo?
45 46
Aseguramiento de la Aseguramiento de la
calidad
„¿Cuáles son los requerimientos para la confiabilidad,
calidad
„
...
¿Existe un tiempo máximo permitido para la
disponibilidad, facilidad de mantenimiento, seguridad, y recuperación del sistema después de una falla?
los restantes atributos de calidad? „ ¿Qué medidas de eficiencia se aplicarán al uso de
„ ¿Cómo deben demostrarse las características del recursos y al tiempo de respuesta?
sistema a terceros? „ ¿Cuán fácil debe ser de mover el sistema de una
„ ¿Debe el sistema detectar y aislar defectos? ubicación a otra o de un tipo de computadora a otra?
„ ¿Cuál es el promedio de tiempo prescripto entre fallas?
„ ¿Cómo puede el sistema incorporar los cambios al
diseño?
„ ¿El mantenimiento sólo corregirá errores o incluirá
evolución?
47 48