Elicitacin de requerimientos:

Proceso de adquirir todo el conocimiento relevante necesario para producir un

modelo de requerimiento.
Entender el dominio del problema en particular

Stakeholders:

Clientes: Pagan por el software

Usuarios: Utilizan el sistema
Expertos del dominio: Se familiarizan con el problema que se debe automatizar
Investigadores de mercado: Encuesta para determinar las tendencias futuras
Abogados o auditores: Familiarizados con los requisitos del gobierno
Ingenieros de software: Futuro utilizador
Tcnicas:

Tcnicas Tradicionales
o Lectura de documentos existentes
o Anlisis de data
o Entrevistas: Abiertas, cerradas
o Encuesta (cuestionario)
o Reuniones
Tcnicas Colaborativas
o Tcnicas de grupo: Focus groups, Brainstroming
o Talleres JAD/RAD
o Prototipos
o Diseo participativo
Tcnicas Cognitivas
o Anlisis de tareas
o Anlisis de protocolos
o Tcnicas de adquisicin de conocimiento
Tcnicas Contextual
o Tcnicas Etnogrficas: Observacin de participantes
o Anlisis de discursos: Anlisis de conversacin, anlisis de los actos de habla
Mtodos sociotcnicos
o Soft System Analysis

Tcnicas tradicionales:
 Lectura de documentos existentes
Anlisis de data
o Fuente
o Muestreo
o Tamao de la data
o Proceso
Entrevistas: Abiertas, cerradas
o Comienzo
o Recoleccin de informacin
o Cierre
o Agradecer el tiempo y voluntad
Encuesta (cuestionario)
Reuniones
o Son una herramienta de gestin importante
o Siempre deben tener objetivo
o Se planifican detalladamente

Tcnicas Colaborativas:
o Tcnicas de grupo:
Brainstroming: Reuniones ente 4 a 10 personas, primeramente, se
sugieren toda clase de ideas despus de eso se realiza un anlisis
detallado de cada propuesta.
o Talleres JAD/RAD
Promueve la cooperacin y el trabajo en equipo entre usuarios y
analistas de software.
Dinmica de grupo, utilizan talleres NO entrevistas
Mucho apoyo visual
Proceso organizado
Cada sesin tiene un documento fcil de entender
o Prototipos
Construccin de versiones reducidas, demos o conjuntos de
pantallas
o Diseo participativo
Enfoque para disear tratando activamente a todas las partes
involucradas para as asegurar sus necesidades
Estrategia para la obtencin de requerimientos
Los pasos son:
1. Aprender todo lo que se pueda de documentos, formularios, informes y archivos
ya existentes. Se puede aprender de un sistema sin quitarle tiempo a la gente
2. De ser posible, observar sistema en accin de eso tomar notas o dibujos.
3. Disear y distribuir cuestionarios (encuestas) para aclarar lo que no se comprenda
bien
4. Realizar entrevistas o sesiones de trabajo JAD. Como ya se tiene una base de
requerimientos iniciales (recopilados en pasos anteriores) con la entrevista se
verifican o aclaran los problemas de mayor dificultad
5. Se verifican los requerimientos a travs del uso de tcnicas como entrevista,
observacin y orientados a punto de vista

Anlisis de requerimientos
Qu es el anlisis de requisitos?

Conjunto de tcnicas y procedimientos que permiten conocer los elementos

necesarios para definir un proyecto de software
Especificar caractersticas operacionales de un software
Establece restricciones del software
Es un proceso de DESCUBRIMIENTO y REFINAMIENTO
Consiste en aplicar una serie de tcnicas para DESGLOSAR y ANALIZAR los
requisitos y sus partes
Alguna de las tcnicas son: MODELADO DE PROCESO, MODELADO DE DOMINIO,
CASOS DE USO, INSPECCIONES, LISTAS DE CHAQUEO, PROTOTIPOS
Objetivo DESCUBRIR PROBLEMAS como requisitos incompletos e inconsistentes
de estos
o Descubrir las interacciones entre los requisitos y destacar conflictos
Los conflictos lo resuelven las partes interesadas a travs del proceso de
NEGOCIACIN
La fase de anlisis de requisitos segn IEEE 1074 se desglosa en 3 actividades.
1. Definir los requisitos de software
2. Definir los requisitos de las interfaces del software con el resto del sistema y con el
exterior
3. Integrar los requisitos en un documento de especificacin y asignarle prioridades
Para comprobar problemas en los requisitos se puede utilizar la LISTA DE VERIFICACIN
(checklist) para cada requerimiento, Se intercala el proceso de elicitacin con el proceso
de anlisis

Lista de verificacin: CKECKLIST

Consiste en una serie de preguntas o revisiones que se analizan sobre cada requerimiento
de software.

Interaccin de requisitos:
Una matriz de interaccin de requisitos muestra como los requisitos interactan unos con
otros.
Matriz de interaccin:

Requisitos que presentan conflicto la matriz se completa con 1

Requisitos que se superponen la matriz se completa con 1000
Requisitos que son independientes la matriz se completa con 0

Requisito 1 Requisito 2 Requisito 3

Requisito 1 - 0 1000
Requisito 2 0 - 1
Requisito 3 1000 1 -
Negociacin de requisitos:
Proceso de discusin de los requisitos de los conflictos y llegar a un compromiso donde
todos los interesados se pongan de acuerdo
Los conflictos no son rechazables, son fuentes de nuevos requisitos
La reunin es la tcnica ms utilizada en esta etapa del proceso
Tareas que realizar:

Discutir los requisitos conflictivos

Priorizar los requisitos
Alcanzar un compromiso final sobre los requisitos a implementar
Mtodo de negociacin

La negociacin inmediata: Llegar rpido al cliente.

La negociacin progresiva: Establecer ambiente idneo.
Negociacin colaborativa - Harvard

Tarea principal de ANLISIS DE REQUISITOS es descubrir conflictos de los requisitos

elicitados, profundizando en el conocimiento del problema mediante la construccin de
modelos conceptuales que sean fcilmente entendibles por desarrolladores y que sirva de
base para el diseo.
La tcnica de modelado conceptual es la PRINICPAL herramienta de anlisis de requisitos.
Tradicionalmente existen 2:

Tcnicas estructuradas
Tcnicas orientadas a objetos

Tcnica de anlisis de requisitos: ESTRUCTURADA

Caractersticas de anlisis estructurado
Especificacin formal de datos
o Diagrama de flujos y control de datos
o Diccionario de datos
Especificacin de procesos
o Lenguaje natural
o Lenguaje estructurado
o Tablas de decisin
o Arboles de decisin
Qu es el anlisis estructurado?
Tcnica del modelado del flujo, contenido y transformacin de la informacin que fluye
por un sistema
Herramientas que se usan para el anlisis estructurado

Diagrama de entidad relacin (BD) Tcnica mas habitual para el modelado

esttico
Diagrama de flujo de datos (DFD) Representa un modelo de flujo de datos
dentro del sistema
Diccionario de datos
Especificaciones de proceso (mini especificaciones)
Diagrama de transicin de estados Visualizar los cambios que sufren las
entidades en el tiempo evolutivo Se relacionan con los casos de uso

Tcnica de anlisis de requisitos: ORIENTADAS A OBJETOS

Caracterstica del anlisis orientado a objeto
Especificacin formal de objetos
o Casos de uso
o Modelado de clases, responsabilidades y colaboraciones
o Definicin de atributos
o Definicin de servicios
Prototipos rpidos para la determinacin de los requerimientos

Para modelar los sistemas de informacin es necesario representar 3 aspectos

Aspecto Esttico - datos

Aspectos Funcionales funciones
Aspectos Dinmicos eventos

Modelo Esttico - datos

Tcnica mas utilizada Diagrama de clases
Permiten representar generalizacin / especializacin
Modelos Funcionales funciones
Diagrama de secuencia y diagrama de colaboracin
La funcionalidad del sistema se logra mediante secuencias de envo de mensajes entre los
distintos objetos

Modelo Dinmico eventos

Corresponde a eventos o estmulos que provocan que el sistema realice funciones
Tcnicas ms utilizadas son:
-Diagrama de estados (statechart)
-En fusin
-Catalysis
Especificacin de requerimientos (ERS)
Es un proceso de representacin de la informacin
Es el medio de comunicacin entre clientes, usuarios, ingenieros en requisitos y
desarrolladores
La ERS abarca requisitos:
-Cliente
-Usuario
-Negocio
-Producto
-Sistema/software
Le ERS es de carcter contractual Cualquier cambio en el ERS despus de la lnea base
acordada se debe aplicar el plan de control de cambios establecido en el proyecto
Objetivos de la ERS

Ayudar al cliente a describir claramente lo que se desea obtener mediante un

software
Ayudar al desarrollador a entender claramente lo que quiere exactamente el
cliente
Si no es buena la ERS los costos del desarrollo pueden incrementarse ya que
tendrn que aplicarse futuros cambios
Sirve de desarrollo para los estndares de la ERS particulares para cada
organizacin

IEEE 830
Estndar que tiene como propsito ayudar con la elaboracin del documento de
especificacin de requerimientos
Es una GUA para la redaccin de requerimientos
Quin puede utilizar la ERS?
-Cliente/usuarios que definan requerimientos o las caractersticas de un software
-Desarrollador (Externo/Interno) que crea un software a medida
Para qu sirve la ERS?
-Cliente/proveedor entiendan claramente lo que quieren
-Se reduzca el esfuerzo de anlisis, diseo y programacin evitando trabajar el doble
-Tener una base de referencia para validar el software
-Se facilite el traspaso del software a otros clientes/usuarios
Caractersticas de la ERS
-Correcta Cada requisito declarado se encuentra en el software
-Inequvoca Solo una interpretacin
-Completa No debe tener frases TBD (to be defined).
-Consistente Ningn subconjunto de requisitos genera conflictos entre s.
-Delinear que es lo que tiene importancia y/o estabilidadEspecificar requisitos esenciales
y deseables. Utilizar grado de estabilidad (nmero de cambios) y grado de necesidad.

-ComprobableExiste un proceso finito con que una persona o mquina puede verificar el
producto de software rene el requisito.

-ModificableEs posible hacer cambios a los requisitos fcilmente.

-Identificableorigen claro, identificable hacia atrs y adelante
Generando el diseo en la ERS

Un requisito especifica una funcin externa visible o atributo de un sistema

Un diseo describe un subcomponente particular de un sistema y/o sus interfaces
con otros subcomponentes
Cada requisito de la ERS limita las alternativas de diseo
La ERS debe especificar que funciones sern realizadas, con que datos, para
producir que resultados, en qu situacin y para quien.

Necesidades para producir una buena ERS

1. Naturaleza del ERS: Especificar Funcionalidad, atributos, restricciones e interfaces externas.
2. Ambiente del ERS: Definir todos los requisitos del software y no describir planes.
 3. Caractersticas de una buena ERS: Correcta, inequvoca, completa, consistente, delinear
importancia, comprobable, identificable y modificable.
4. Preparacin de los joins del ERS: Proveedor-cliente deben estar de acuerdo en lo que el
software har.
5. Evolucin de ERS: Los cambios aprobados de requerimientos deben especificarse en la ERS.
6. Prototipos: Una ERS al estar basada en un prototipo, tiene a sufrir menos cambios durante el
desarrollo.
7. Generando el diseo en el ERS: El diseador de la ERS debe distinguir claramente entre
identificar las restricciones del diseo y proyectar un diseo especifico.
8. Generando los requisitos del proyecto en el ERS: ERS dirige el producto del software, No
el proceso.
Los requisitos del proyecto No van en la ERS. Se especifican en otro documento.
Costos, hardware, software son ejemplos.

Especificacin de Requerimientos
 En esta fase se documentan los requerimientos acordados con el cliente en un
nivel apropiado de detalle
Se documenta la descripcin completa de las necesidades y funcionalidades del
sistema que ser desarrollado
Describe el alcance del sistema y la forma como har sus funciones definiendo RF y
RNF
En la practica esta etapa se hace en paralelo con el anlisis
En pocas palabras la especificacin es PASAR EN LIMPIO el anlisis realizado
previamente aplicando tcnicas y/o estndares de comunicacin
Separar funcionalidad de implementacin
Una especificacin debe abarcar el entorno en el que el sistema opera
Debe ser modificable

Tipos de documentos de requerimiento

Definicin de requerimientos dirigido al cliente

Especificacin de requerimientos dirigidos al desarrollador

Contenidos de una ERS