Análisis y modelado de sistemas de
software
Análisis de Requerimientos
Blanca A. Vargas Govea – [email protected] – Enero 29, 2013
Objetivos
2
• Conocer y aplicar las técnicas de análisis
de requerimientos
• Conocer y aplicar el estándar SRS830-
1998 IEEE
Ciclo de vida del desarrollo de sistemas
3
Fases
Análisis
Determinación de
requerimientos
Modelado funcional
Modelado estructural
Modelado de comportamiento
Diseño
Implementación
4
La fase de análisis contesta las preguntas de
¿quién usará el sistema?, ¿qué es lo que hará
el sistema? y ¿dónde? y ¿cuándo? será usado.
Análisis
5
Toma las ideas generales
en la solicitud del sistema
y se van refinando
En esta fase es muy fácil
que haya cambios pues
poco o ningún trabajo se
ha hecho aún
Determinación de requerimientos
6
Propósito: convertir la
explicación de alto nivel
de los requerimientos del
negocio en una lista
precisa de requerimientos
que puedan usarse como
entradas al resto del
análisis
Determinación de requerimientos
7
Paso crítico pues a partir
de aquí, los elementos del
sistema emergen
Más de la mitad de las
fallas son debidas a
problemas con los
requerimientos
Olvidé decir
que tenía que
ser posible
acceder vía
Web
Determinación de requerimientos
8
Requerimiento: es una
declaración de lo que el
sistema debe hacer o qué
características debe tener
Se enfocan en las
necesidades del usuario de
negocios
Se les conoce como
requerimientos de
negocios o requerimientos
de usuario
Definición de requerimientos
9
Reporte en texto que lista
los requerimientos
funcionales y no
funcionales en cierto
formato
Propósito: definir el
alcance del sistema
Técnicas de recolección de requerimientos
11
Analista → detective
Usuarios →
sospechosos elusivos
El analista debe
reconocer claves que
no siempre son obvias
Técnicas de recolección de requerimientos
12
Los mejores analistas usan varias técnicas
El objetivo es asegurarse de que los procesos y necesidades del nuevo sistema se entiendan bien antes de ir al diseño
Incluir a todas las partes interesadas:
Personas que pueden afectar al sistema
Personas que serán afectadas por el sistema
Si no, la persona puede sentirse relegada y puede
originar problemas durante la implementación
No me tomaron en
cuenta cuando dije que
los cacahuates eran
importantes
Técnicas de recolección de requerimientos
13
1. Entrevistas 2. Sesiones
JAD
3. Cuestionarios
4. Análisis de documentos
5. Observación
Join Application
Development
Cada técnica tiene
sus propias fuerzas
y debilidades
1. Entrevista
14
Técnica más común
Se hace generalmente 1-1
Selección de personas a entrevistar
Diseño de las preguntas
Preparación para la entrevista
Conducción de la entrevista
Seguimiento
Selección de personas a entrevistar
15
Calendario de entrevistas
Las personas se
seleccionan de acuerdo a
las necesidades del analista
Ordenar por prioridad y
elaborar la lista
Preguntas cerradas
17
Requieren una respuesta
específica
Ejemplo: ¿cuántas
solicitudes de tarjeta de
crédito reciben al día?
Incorrecta: ¿reciben
muchas solicitudes?
¿cuántas
órdenes
telefónicas se
reciben por
día?
¿cuántos
clientes hacen
pedidos en una
semana? ¿qué
información
falta en los
reportes
mensuales de
ventas?
Preguntas abiertas
18
Permiten que el
entrevistado explique
Dan a la persona mayor
control sobre la
información
¿qué piensa del
sistema actual?
¿qué
problemas
enfrenta
regularmente? ¿qué mejoras
le gustaría que
tuviera el
nuevo sistema?
Preguntas exploratorias
19
Dan seguimiento a lo que
se ha discutido para
aprender más
Alientan al entrevistado a
profundizar o confirmar la
información
¿por qué? ¿me puede dar
un ejemplo?
¿me podría
explicar con
mayor detalle?
Diseño de preguntas para entrevista
20
No se debería preguntar
información que está
disponible en otras
fuentes, por ejemplo, en
documentos
Ningún tipo de pregunta
es mejor que otra, se
recomienda combinarlas
Pero si eso
que quiere
saber viene en
los manuales…
Estrategias
21
Top-down: de lo general a lo específico
Bottom-up: de lo específico a lo general
Top-down es la apropiada para la mayoría de las entrevistas
Bottom-up es preferible cuando el analista ya tiene mucha información y solamente necesita llenar vacíos
Preparación para la entrevista
22
Preguntas, orden de los
entrevistados
Confirmar el área de
conocimiento del
entrevistado
Tomarse el tiempo para
preparar preguntas
cerradas
Riesgo de no hacerlo:
requerir una nueva
entrevista
Creo que ya
tengo todo
listo
Conducción de la entrevista
23
Inspirar confianza en el
entrevistado
Iniciar con una explicación
del por qué se realiza
Escribir todo
Grabar o filmar: depende
de las políticas. Puede ser
intimidante
Explicar que seguirá
No hacer promesas sobre
el nuevo sistema
2. JAD (Joint Application Development)
25
Técnica que permite a los grupos de desarrollo, administración y clientes trabajar juntos para identificar los requerimientos del sistema
Desarrollada por IBM a finales de los 70s
Proceso estructurado en el cual se reúnen de 10 a 20 personas bajo la dirección de un facilitador
Duración: horas, días o semanas
Problemas tradicionales asociados a los grupos
JAD electrónico
3. Cuestionarios
26
Conjuntos de preguntas
Se usan cuando hay un gran número de personas de las cuales se necesita su información y opiniones
Aplicados comúnmente para sistemas cuyo uso es externo a la organización (clientes y vendedores) o cuyos usuarios están en diversas ubicaciones geográficas
Impresos, correo electrónico, vía Web
1. Empezar con preguntas interesantes y
no amenazadoras
2. Agrupar las preguntas en secciones
3. No poner asuntos importantes al
inicio
4. No saturar una página con muchas
preguntas
5. Evitar las abreviaciones
6. Preguntas objetivas, sin sesgo o
sugestivas
7. Poner número a las preguntas para
evitar confusiones
8. Probar el cuestionario para
identificar preguntas confusas
9. Proporcionar anonimidad a los que
responden
Buen diseño de cuestionarios
4. Análisis de documentos
27
Revisión de documentos
existentes
Reportes
Memorándums
Manuales de políticas
Manuales de entrenamiento
Gráficas de la organización
Buscar indicadores de lo
que debería cambiarse
5. Observación
28
Ver el proceso en
ejecución
Es un complemento a las
entrevistas
Compórtate,
estás en
inspección
Tabla de técnicas de recolección de requerimientos
29
Entrevistas JAD Cuestiona
rios
Análisis de
documentos
Observación
Tipo de
información
Sistema-actual,
mejoras,
sistema-futuro
Sistema-actual,
mejoras,
sistema-futuro
Sistema-
actual,
mejoras
Sistema-
actual
Sistema-
actual
Profundidad de
la información
Alta Alta Media Baja Baja
Alcance de la
información
Baja Medio Alta Alta Baja
Integración de
la información
Baja Alta Baja Baja Baja
Involucramient
o del usuario
Medio Alto Bajo Baja Baja
Costo Medio Bajo-Medio Bajo Baja Bajo-Medio
Beneficios de usar estándares
31
Habilidad de aplicar
metodologías de
mantenimiento y
desarrollo de software y
procedimientos de alto
nivel profesional
Mejorar el entendimiento
mutuo y coordinación
entre equipos de
desarrollo
Mayor cooperación entre
el desarrollador de
software y participantes
externos
Mejor entendimiento y
cooperación entre
proveedores y usuarios
Estándar SRS830-1998 IEEE
32
SRS (Software Requirements Specification)
Descripción completa del comportamiento de un sistema
Puede incluir casos de uso que describan interacciones
del usuario con el software
SRS830-1998 IEEE captura correcta y completamente los
requerimientos y necesidades de un sistema de software y
las expectativas de los usuarios potenciales
Actividad 5: individual Tarea 5: equipo
33
Eres el analista encargado de
desarrollar un nuevo sistema
para una tienda de libros
(dentro de la institución) en la
cual los estudiantes puedan
ordenarlos online y les sean
entregados en su casa o salón
de clases. Diseña un plan de
recolección de información
para el sistema.
Revisar el documento correspondiente al estándar SRS830-1998 IEEE y preparar la forma con la información de su proyecto. Anexo un ejemplo. En la página están los siguientes documentos:
SRS830.pdf
SRSExample-webapp.doc
No es necesario incluir casos de uso(por ahora).
Fecha de entrega: Febrero 1, 2013
Avisos
34
Próximo Viernes 1 de
Febrero, me ausentaré.
Sí habrá actividades a
realizar para esa sesión.
Se pondrán las actividades
en la página y el trabajo se
enviará por correo en el
horario correspondiente a
la clase.
El primer examen es el
Viernes 8 de Febrero.
Referencias
35
Dennis, Alan., Systems analysis and design with UML version 2.0 : an object-
oriented approach / Alan Dennis, Barbara Haley Wixom, David Tegarden.,
2nd ed., Hoboken, NJ : J. Wiley, 2005
Schach Stephen R., Introduction to object-oriented analysis and design,
Boston, Mass. ; Mexico City : McGraw-Hill, 2004