Planificacin y Modelado

Ingeniera en
Sistemas
Computacionales
Semestre Agosto- Diciembre 2010
Instituto Tecnolgico de Culiacn
Norma Rebeca Godoy Castro
Materia:
Datos de la asignatura
Nombre de la asignatura:
Planificacin y Modelado

Carrera:
Ingeniera en Sistemas Computacionales

Clave de la asignatura:
SCM-0424

Horas teora- horas prctica crditos :
3-2-8

Relacin con otras asignaturas del
plan de estudio
Anteriores

Fundamentos de desarrollo de software

Posteriores

Desarrollo de proyectos de software

Objetivo General del Curso:
El estudiante planificara, analizara y
diseara un proyecto de software o
sistema de informacin conforme a los
requerimientos establecidos al inicio del
mismo y aplicando tcnicas modernas y
de acorde a las caractersticas
intrnsecas del mismo
Temario
Unidad I. Procesos de la ingeniera de requerimientos.
1.1. Requerimientos de proceso
1.2. Requerimientos de los usuarios (actores involucrados)
1.3. Requerimientos para el anlisis y negociacin.
1.4. Requerimientos para la gestin.
Unidad II. Planificacin del sistema.
2.1. Planificacin del tiempo
2.2. Evaluacin del costo beneficio
2.3. Estudio de viabilidad
2.4. Planificacin de la documentacin
2.5. Gestin de la configuracin del software

Temario
Unidad III. Anlisis del proyecto
3.1. Anlisis de riesgos
3.2. Control de calidad
Unidad IV. Anlisis de los requerimientos
4.1. Requerimientos funcionales y no funcionales
4.2. Casos de Uso
4.3. Diseo de interfaz de usuario
4.3.1. Reglas en el diseo de interfaz de usuario
4.3.2. Integracin de la interfaz al caso de uso
Evaluacin
Exmenes (4) 80 %
Trabajo Final 20 %



En las evaluaciones por unidad se tomara en cuenta lo siguiente:

Calificacion examen 70%
Trabajos parciales 10%
Asistencia 10%
Avance 10%



100 %
Bibliografa
Titulo del Libro Autor
Ingeniera de Software
Ian Sommerville
UML y Patrones
Craig Larman
Medicin y Estimacin
del Software
Mario G. Piattini, Felix O.
Garcia Rubio, Javier Garza
P.
Software Engineering
Roger S. Preesman
Ingeniera de Software
Introduccin
FAQs: Preguntas frecuentes
sobre Ingeniera del Software
Qu es el Software?
Cul es la importancia y coste del Software?
Qu es la Ingeniera del Software?
Cul es la diferencia entre Ingeniera del Software e Ingeniera de
Sistemas?
Qu es un sistema y un sistema de informacin?
Qu es un proceso software y un mtodo de desarrollo?
Cmo se gestiona el proceso?
Qu es CASE (Computer-Aided Software Engineering)?
Cules son las responsabilidades de un Ingeniero Software?
Qu es el Lenguaje Unificado de Modelado (UML)?
Qu es la Ingeniera del software?
Disciplina que se ocupa del desarrollo del software.
Se enfrenta al software como un producto de
ingeniera que requiere: planificacin, anlisis,
diseo, implementacin, pruebas y mantenimiento.
Trata de las teoras, mtodos y herramientas que los
profesionales del desarrollo del software deben
utilizar
Ingeniera del Software
No slo comprende los procesos tcnicos del
desarrollo.
Tambin, los principios ms relevantes de
direccin y control de este proceso.
Tambin, el desarrollo de nuevas teoras,
mtodos y herramientas de apoyo a la
produccin del software.
Objetivos de la
Ingeniera del software
Mejorar la calidad del software
Acortar los tiempos de desarrollo
Aumentar la productividad
Necesidad:
Incrementar la reutilizacin del software
Cul es la diferencia entre Ingeniera del
Software e Ingeniera de Sistemas?
La Ingeniera de Sistemas tiene que ver con
todos los aspectos del desarrollo de sistemas
basados en computadoras:
Hardware, Software e Ingeniera de procesos.
Ingeniera del Software es una parte de este
proceso
Disciplinas integradas en la
Ingeniera del Software
Tarea:
Leer sobre los siguientes artculos:
No Silver Bullet
Death by UML Fever
How to Fail with the RUP




El Proceso Unificado
Un proceso de desarrollo de software describe
un enfoque para la construccin, desarrollo y
posiblemente el mantenimiento del software.
El Proceso Unificado (UP) se ha convertido en
un proceso de desarrollo de software de gran
xito para la construccin de sistemas
orientados a objetos.
El UP combina las practicas comnmente
aceptadas como buenas practicas.


Desarrollo iterativo
El UP fomenta el uso del desarrollo a travs de
iteraciones.
El desarrollo de un proyecto de software se organiza en
una serie de mini proyectos cortos, de duracin fija
llamados iteraciones.
Cada iteracin incluye sus propias actividades de anlisis
de requisitos, diseo, implementacin y pruebas.
El sistema crece incrementalmente a lo largo del tiempo,
iteracin tras iteracin, es por esto que a este enfoque se
le conoce como desarrollo iterativo e incremental.

Beneficios del desarrollo iterativo
Mitigacin tan pronto como sea posible de riesgos
altos.
Progreso visible en las primeras etapas.
Una temprana retroalimentacin, compromiso de
los usuarios y adaptacin.
Gestin de la complejidad.
El conocimiento adquirido en una iteracin se
puede utilizar metdicamente para mejorar el
propio proceso de desarrollo.

Fases del UP
1. Inicio: visin aproximada, anlisis del negocio,
alcance.
2. Elaboracin: visin refinada, identificacin de mas
requisitos y alcance, estimaciones mas realistas.
3. Construccin: implementacin iterativa del resto de
los requisitos de menor riesgo y elementos mas
fciles, preparacin para el despliegue.
4. Transicin: pruebas beta, despliegue.
Inception Elaboration Construction Transition
time
Iteraciones entre las fases
Preliminary
Iteration
Iter. #1 Iter. #2
Inception Elaboration Construction Transition
Hito Liberacin Liberacin del
Producto final
Punto de terminacin
de la iteracin
cuando se toma
alguna decisin o
evaluacin
importante
Un subconjunto
estable y
ejecutable del
producto final. El
final en cada
iteracin es una
pequea versin
En este punto
el sistema se
lanza para su
puesta en
produccin
Requisitos evolutivos VS cascada
De acuerdo a investigaciones, en promedio, un
25% de los requisitos cambian en los proyectos
de software.
Cualquier mtodo que intente congelar o definir
completamente los requisitos al inicio est
condenado al fracaso, puesto que se
fundamente en una suposicin falsa y pelea o
niega el cambio inevitable.
De acuerdo a un estudio de Thomas 2001 sobre
1027 proyectos de software se encontr que el
factor que contribua de forma mayor al fracaso,
en el 82% de los casos es el supuesto de que
los requisitos no cambiarn.
Comprensin de los requisitos
Los requisitos son capacidades y condiciones con las cuales
debe ser conforme el sistema, en si el proyecto.
El primer reto del trabajo de los requisitos es encontrar,
comunicar y recordar (registrar) lo que se necesita realmente,
de manera que tenga un significado para el cliente y los
miembros del equipo de desarrollo.
El UP acepta el cambio de los requisitos como un motor
fundamental del proyecto.
Otro termino importante es encontrar es decir es buscar
cuidadosamente mediante tcnicas tales como la escritura de
los Casos de Uso y talleres de requisitos.

Unidad I
Procesos de la ingeniera
de requerimientos
Qu es la Ingenieria de
Requerimientos?
Ingenieria de Requerimientos ayuda a los ingenieros de
software a entender mejor el problema en cuya solucion
trabajaran. Incluye el conjunto de tareas que conducen a
comprender cual sera el impacto del software sobre el
negocio, que es lo que el cliente quiere y como interactuaran
los usuarios finales con el software.(Pressman)

La Ingenieria de Requerimientos es el proceso de desarrollar
una especificacin de software.Las especificaciones
pretenden comunicar las necesidades del sistema, del cliente
a los desarrolladores del sistema. (Sommerville)
Nuestra labor es algo asi..
Analicen la siguiente imagen.
Qu es la Ingenieria de
Requerimientos?
La parte ms difcil de construir un sistema es precisamente
saber qu construir. Ninguna otra parte del trabajo
conceptual es tan difcil como establecer los requerimientos
tcnicos detallados, incluyendo todas las interfaces con
gente, mquinas y otros sistemas. Ninguna otra parte del
trabajo afecta tanto el sistema si es hecha mal. Ninguna es
tan difcil de corregir ms adelante Entonces, la tarea ms
importante que el ingeniero de software hace para el cliente
es la extraccin iterativa y el refinamiento de los
requerimientos del producto. [Frederick P. Brooks, 1987]
Para maana..
Traer el libro de Pressman o sacar copia desde la pagina 155 a la
162 y tambien

1 hoja de rotafolio.
3 plumones de diferentes colores.
1 cinta.

POR EQUIPO.
El equipo que no llegue preparado no entrara a la clase.


Trabajar con lo siguiente:
1.-Cada equipo trabajara con la definicin de Ingenieria de
Requerimientos o de Requisitos.

2.-Tambien identificara y definira las diferentes fases de la
Ingenieria de Requerimientos.

3.-Los resultados de su investigacin lo plasmaran en su hoja de
rotafolio.

4.-Al final se sortearan los equipos y el ganador sera el
responsable de exponer lo realizado en la clase.

Fases de la Ingenieria de
Requerimientos
Inicio
La mayoria de los proyectos comienza cuando se identifica una
necesidad de negocios o se descubre un nuevo mercado o
servicio potencial.
Al inicio del proyecto los ingenieros de software hacen una
serie de preguntas libres de contexto . El objetivo es
establecer una comprension basica del problema , las
personas que quieren una solucion, la naturaleza de la
solucion que se desea, y la efectividad de la comunicacion
preliminar entre el cliente y el desarrollador.
Fases de la Ingenieria de
Requerimientos
Obtencion
Parece simple preguntarle al usuario que es lo que se desea
lograr con el sistema y de que forma este satisface las
necesidades del negocio y como se utilizara el sistema o
producto dia a dia, pero esto no es simple, es un poco dificil.

Problemas de ambito
Problemas de comprension
Problemas de volatilidad
Fases de la Ingenieria de
Requerimientos
Elaboracion
La informacion conseguida con el cliente durante el inicio y la
obtencion se refina.

La elaboracion es una accion del modelado del analisis y se
compone de una serie de tareas de modelado y
refinamiento.

El resultado final de la elaboracion es un modelo de analisis que
define el dominio de la informacion, las funciones y el
comportamiento del problema.
Fases de la Ingenieria de
Requerimientos
Negociacion
No resulta inusual que los clientes y usarios pidan mas de lo
que se puede lograr. Tambien es comun que diferentes
clientes y usuarios propongan requisitos que entran en
conflicto entre si al argumentar que su version es esencial
para nuestras necesidades especiales.

El ingeniero de requisitos debe conciliar estos conflictos por
medio de un proceso de negociacion. Se pide a los clientes,
usuarios y otros interesados que ordenen sus requisitos y
despues discutan los conflictos relacionados con la prioridad.
Fases de la Ingenieria de
Requerimientos
Especificacin
Una especificacion puede ser un documento escrito, un
conjunto de modelos graficos, un modelo matematico
formal, una coleccion de escenarios de uso, un prototipo o
cualquier combinacion de estos.
Validacion
La validacion de requisitos examina la especificacion para
asegurar que todos los requisitos de software se han
establecido de manera precisa , que se han detectado las
inconsistencias, omisiones y errores y que estos han sido
corregidos y que los productos de trabajo cumplen con los
estandares establecidos para el proceso, proyecto y
producto.
Cules son?
Procesos de la Ingeniera de Requerimientos
Requerimientos
de
Proceso
Requerimientos
de
Usuarios
Requerimientos
de
Anlisis y
Negociacin
Requerimientos
para la
Gestin
Requerimientos de Proceso
Estos requerimientos existen porque los
procesos los usan durante el desarrollo del
software.
Requerimientos de usuario
Describen los requerimientos funcionales y no
funcionales de tal forma que sean
comprensibles por los usuarios del sistema que
no posean un conocimiento tcnico detallado.
nicamente especifican el comportamiento
externo del sistema y evitan, tanto como sea
posible, las caractersticas de diseo del
sistema.
Deben redactarse utilizando el lenguaje natural,
representaciones y diagramas intuitivos
sencillos.
Ejemplos de Requerimientos del sistema electoral
Req1- El sistema debe verificar que la instalacin del
sistema ha sido correcta y que los dispositivos funcionan
correctamente
Req 2- El sistema debe permitirle al presidente iniciar la
eleccin lo cual permitir que se puedan registrar los
votos de los electores
Req 3- El sistema deber almacenar el voto una vez que
ste fue confirmado.
Req 4- El sistema permitir que el presidente de una
unidad de reporte (o mesa) realice un cierre de eleccin,
la cual solo podr realizarse si se produce en un horario
posterior al establecido (en la configuracin del sistema)
y si la eleccin se encuentra iniciada
Caracteristicas de los Requerimientos
Necesario: Un requerimiento es necesario si su omisin
provoca una deficiencia en el sistema a construir, y
adems su capacidad, caractersticas fsicas o factor de
calidad no pueden ser reemplazados por otras
capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fcil de leer
y entender. Su redaccin debe ser simple y clara para
aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento est completo si no
necesita ampliar detalles en su redaccin, es decir, si se
proporciona la informacin suficiente para su
comprensin.
Caracteristicas de los Requerimientos

Consistente: Un requerimiento es consistente si no
es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo
cuando tiene una sola interpretacin. El lenguaje
usado en su definicin, no debe causar confusiones
al lector.

Verificable: Un requerimiento es verificable cuando
puede ser cuantificado de manera que permita
hacer uso de los siguientes mtodos de verificacin:
inspeccin, anlisis, demostracin o pruebas.
Dificultad para definir los
Requerimientos?
Los requerimientos no son obvios y vienen de
muchas fuentes.
Son difciles de expresar en palabras (el lenguaje es
ambiguo).
Existen muchos tipos de requerimientos y diferentes
niveles de detalle.
La cantidad de requerimientos en un proyecto puede
ser difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms
riesgosos, ms importantes o ms estables que
otros.
Dificultad para definir los
Requerimientos?
Cada requerimiento tiene propiedades nicas y
abarcan reas funcionales especficas.
Un requerimiento puede cambiar a lo largo del ciclo
de desarrollo.
Son difciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.
Cada requerimiento debe
Expresarse de modo adecuado
Ser de acceso sencillo
Numerarse
Acompaarse con pruebas que lo verifiquen
Tomarse en cuenta en el diseo
Tomarse en cuenta en el cdigo
Probarse aislado
Probarse junto con otros requerimientos
Validarse con las pruebas despus de construir la
aplicacin

Los requisitos se agrupan en categoras y se
organizan en subconjuntos, se analiza cada requisito
en relacin con el resto, se examina los requisitos en
su consistencia, completitud y ambigedad, y se
clasifican en base a las necesidades de los
clientes/usuario.

Requerimientos para el Analisis y
Negociacin

Para hacer el Anlisis de requisitos se plantean las siguientes
cuestiones:
1. Cada requisito es consistente con los objetivos generales del
sistema/producto?
2. Tienen todos los requisitos especificados el nivel adecuado
de abstraccin? Algunos requisitos tienen un nivel de detalle
tcnico inapropiado en esta etapa?
3. El requisito es necesario o representa una caracterstica
aadida que puede no ser esencial a la finalidad del sistema?
4. Cada requisito est delimitado y sin ambigedad?
Requerimientos para el Analisis y
Negociacin

5. Cada requisito tiene procedencia? Es decir, Existe un origen
(general o especfico) conocido para cada requisito?
6. Existen requisitos incompatibles con otros requisitos?
7. Es posible lograr cada requisito en el entorno tcnico donde se
integrar el sistema o producto?
8. Se puede probar el requisito una vez implementado?
Requerimientos para el Analisis y
Negociacin
Proceso de Negociacin
Los clientes debern clasificar sus requisitos y discutir los
posibles conflictos segn su prioridad.
Los riesgos asociados con cada requisito sern identificados y
analizados.
Se efectan estimaciones del esfuerzo de desarrollo que se
utilizan para valorar el impacto de cada requisito en el coste
del proyecto y en el plazo de entrega.
Utilizando un procedimiento iterativo, se irn eliminando
requisitos, se irn combinando y/o modificando para
conseguir satisfacer los objetivos planteados.
Requerimientos para el Analisis y
Negociacin
Es un conjunto de actividades que ayudan al equipo de
trabajo a identificar, controlar y seguir los requisitos y los
cambios en cualquier momento.
Como en la Gestin de Configuracin del Software (GCS), la
gestin de requisitos comienza con la actividad de
identificacin. A cada requisito se le asigna un nico
identificador, que puede tomar la forma:

<tipo de requisito><requisito no.>

Requerimientos para la Gestion
Identificadores, segn el tipo de requisito:
F Funcional
D Datos
C Comportamiento
I Interfaz
S Salida
Requerimientos para la Gestion
Matrices que se deben realizar para la Gestin de Requisitos:


Matriz de seguimiento de caractersticas: muestra los requisitos
identificados en relacin a las caractersticas definidas por el cliente del
sistema/producto.
Matriz de seguimiento de orgenes: identifica el origen de cada requisito.
Matriz de seguimiento de dependencias: indica cmo se relacionan los
requisitos entre s.
Matriz de seguimiento de subsistema: vincula los requisitos a los
subsistemas que lo manejan.
Matriz de seguimiento de interfaces: muestra cmo los requisitos estn
vinculados a las interfaces externas o internas del sistema.
Requerimientos para la Gestion


Matriz de seguimiento de caractersticas: muestra los requisitos
identificados en relacin a las caractersticas definidas por el cliente del
sistema/producto.
Ejemplo:
El problema de
Afecta a
Cuyo impacto
ocasiona
Una solucin
exitosa debera
Requerimientos para la Gestion

Matriz de seguimiento de orgenes: identifica el origen de cada requisito.

Ejemplo:
Requerimiento Tipo Usuario Origen
Requerimientos para la Gestion

Matriz de seguimiento de interfaces: muestra cmo los requisitos estn
vinculados a las interfaces externas o internas del sistema.

Ejemplo:
Requerimiento Interfaz Tipo Usuario Mdulo
Requerimientos para la Gestion
Anlisis y Descripcin
Durante el anlisis del problema, los analistas
dedican una cantidad considerable de tiempo
haciendo lo siguiente:
Tormenta de ideas
Dirigir entrevistas con los involucrados con el
sistema
Obtener informacin de las personas mas
familiarizadas con ese dominio.
El anlisis del problema debe de llevarse a
cabo hasta que se alcance una comprensin
completa del problema.
Importancia de la fase de requerimientos
Pueden existir errores que si se detectan en esta fase
puede ser que no se propaguen a fases posteriores.
Esta fase involucra mucha comunicacin entre los
involucrados (actores, stakeholders) con el sistema y
los desarrolladores.
Se debe de tener precaucin para asegurar que las
especificaciones estn libres de hechos
(aseveraciones) incorrectos, omisin de detalles,
inconsistencias y ambigedades.

Despus del proceso de levantamiento de
requerimientos, se obtiene la siguiente
informacin:
Un documento especificando la necesidad y factibilidad del
sistema a construirse.
Alcance del sistema o producto a desarrollarse.
Lista de todos los involucrados que participaron en el
levantamiento de requerimientos.
Un documento describiendo el entorno tecnolgico.
Lista de todos los requerimientos organizados por funcin.
Especificacin de los casos de uso o escenarios de uso.
Anlisis de Requerimientos
Preguntas que contribuyen al anlisis de
requerimientos:
Es cada requerimiento consistente con los objetivos
globales para los cuales el software esta
desarrollndose?
Proporcionan cada uno de los requerimientos
suficientes detalles, para que se pueda pasar a la
prxima fase?
Cules de los requerimientos especificados son
absolutamente necesarios y cuales son estticos?
Es posible identificar la fuente (la persona en la
organizacin) de cada requerimiento?

Conducir el estudio de requerimientos
Las siguientes son algunas actividades principales que deben
ser parte del estudio de requerimientos:
Arreglar la primera reunin con los clientes.
Procurar entender la misin de la organizacin.
Familiarizarse con la estructura de la organizacin e identificar a los
diversos involucrados con el sistema.
Utilizar la reunin para establecer credibilidad con los clientes y para
ganar su confianza.
Conducir las entrevistas con profundidad con los diferentes
involucrados para los aspectos especficos.
Desarrollar una clara comprensin del flujo de datos y lgica
operacional del sistema.
Conocer y resguardar documentos que se utilicen para la entrada de
datos, as como para salidas del sistema.
Tipos de requisitos
En UP (Proceso Unificado), los requisitos se
clasifican de acuerdo con el modelo FURPS+,
para nuestro estudio nos basaremos en dos
tipos de requisitos:
Funcionales
No Funcionales
Requisitos Funcionales
Son declaraciones de los servicios que proveer el sistema,
de la manera en que ste reaccionara a entradas
particulares y de cmo se comportar en situaciones
particulares. En algunos casos, los requerimientos
funcionales de los sistemas tambin declaran
explcitamente lo que el sistema no debe hacer.
Los requisitos funcionales para un sistema se expresan de
diferentes formas.
Ejemplo de requisitos funcionales
A continuacin se describe parte los requisitos que un sistema
para administrar condominios requiere.

El sistema debe poder registrar los pagos de mantenimiento que se
reciben por parte de los condminos.
Las cuotas de mantenimiento se establecen de acuerdo al tamao del
terreno que ocupe la propiedad, por lo tanto debe de haber forma de
calcular dichas cuotas por medio del sistema.
Los condminos deben de poder realizar los pagos personalmente o de
forma electrnica.
Se deben de enviar recordatorios mensuales a los condminos que no
realicen los pagos de forma puntual.

Requisitos no funcionales
Son aquellos requisitos que no se refieren directamente a las
funciones especificas que entrega el sistema, si no a las
propiedades emergentes de ste como la fiabilidad, la
respuesta en el tiempo y la capacidad de almacenamiento.
De forma alternativa definen restricciones del sistema como
la capacidad de los dispositivos de entrada/salida y la
presentacin de los datos que se utiliza en las interfases del
sistema.
Algunos ejemplos de requisitos no funcionales son: rapidez,
facilidad de uso, fiabilidad, robustez.
Requisitos Funcionales (RF)
Describen el funcionamiento del sistema.
Los RF del usuario pueden ser frases muy generales
sobre lo que el sistema debera hacer.
Se suelen expresar como objetivos del sistema.
Los RF del sistema deben describir los servicios que
hay que proporcionar con todo detalle: los casos de
uso.
Ejemplos de RF
Requisitos No Funcionales (RNF)
Defines propiedades que el sistema debe de
tener.
Pueden ser ms crticos que los funcionales.
Si un R. funcional no se cumple, el sistema se
degrada
Si un R. no funcional no se cumple, el sistema
puede inutilizarse
Una gua bsica de RNF:
[F]URPS (Larman)
Administracin de Requerimientos
Los requerimientos de sistemas grandes son siempre
cambiantes.
Surgirn nuevos requerimientos debido a:
Comunidad de usuarios diversa. Los requerimientos
finales son comnmente un trmino medio.
Quien paga es raramente quien usa el sistema.
Entorno de negocios y tcnico cambiante.
SRS (Especificacin de Requisitos de
Software)
SRS es una especificacin de requerimientos
de software, en donde se registra la
descripcin completa de todos los
requerimientos.
Describe lo que el software har, pero sin
describir como.
El documento de requisitos
Es la declaracin oficial de que requieren los
desarrolladores del sistema. Este documento
tiene un conjunto diverso de usuarios que va
desde los administradores principales de la
organizacin, quienes pagan por el sistema, hasta
los ingenieros responsables del software.
Existen varias especificaciones para crear este
documento, a continuacin se presenta la que
sugiere la IEEE.
Documento de requisitos (contenido)
1. Introduccin
2. Descripcin general
3. Requerimientos especficos
4. Apndices
5. ndice

Guas para escribir requisitos
Adaptar un formato estndar y utilizarlo para
todos los requisitos
Utilizar el lenguaje de forma consistente.
Distinguir entre los requisitos obligatorios y los
deseables.
Resaltar el texto para identificar las partes claves del
requisito.
Evitar el uso de lenguaje tcnico.
Usuarios (Actores Involucrados)
Anlisis de requisitos
Elicitacin (o extraccin o captura o determinacin) de
requisitos:
El proceso mediante el cual los usuarios descubren, revelan, organizan
y comprenden los requisitos que desean.
Tcnicas: observacin, entrevistas, herramientas CASE.

Anlisis de requisitos:
El proceso de razonamiento sobre los requisitos obtenidos en la etapa
anterior, detectando y resolviendo posibles inconsistencias o
conflictos, coordinando los requisitos relacionados entre s, etc.
Tcnicas: diferentes representaciones grficas (UML) y tcnicas de
revisin
Entrevista
Los objetivos de la etapa de elicitacin son dos:
Conocer a fondo el departamento donde la empresa necesita mejorar.
Realizar un censo exhaustivo de las necesidades del sistema que se quiere
informatizar

Cada persona del departamento tiene su propia visin del sistema.
La direccin, global pero difusa; los trabajadores, parcial pero concreta
Las tcnicas de la obtencin inicial de informacin son:
Observacin directa
Estudio de los documentos y diversa informacin que se maneje actualmente
Sobre todo, las entrevistas.
Entrevista a la direccin
Objetivos:
Primer conocimiento
Censo de objetivos deseados
Organigrama de puestos de trabajo
Relaciones con otros proyectos
Delimitar en lo posible el campo de estudio

Entrevistados: jefe de rea, de servicio, de negociado,...
Tcnica: informal, periodstica
Resultados:
Visin del proyecto objetivos principales
Lista de puestos de trabajo
Campo de estudio
Restricciones: medios, calendario, legislacin, etc.
Entrevista a puestos de trabajo
Objetivos:
Operaciones efectuadas (Lista de Tareas)
Eventos peridicos
Datos y documentos/informaciones manipuladas
Qu puestos intervienen
Tambin mensajes electrnicos, telefnicos, fax,...
Reglas del negocio
Lenguaje de la empresa
Entrevistados: contable, administrativo, agente de ventas, etc.
Tcnica: Se debe intentar estructurar la informacin recibida,
mediante fichas, representacin grfica, etc.
Fichas de entrevistas
El contenido de una ficha de entrevista a un puesto de trabajo ser:
Identificacin
Persona
Departamento
Empleo
Operaciones que realiza y descripcin
Documentos enviados y recibidos desde el puesto (incluidos los
documentos orales) y descripcin:
Nombre
Origen y destino
Periodicidad
Volumen
Conservacin/destruccin