PlanificaciÓn y Modelado Procesos de La Ingeniería

UNIDAD I
PLANIFICACIÓN Y MODELADO
Procesos de la Ingeniería de
Requerimientos
USADO
DESPUÉS
DE
CAMBIOS
USADO PERO
2% USADO TAL
COMO SE
3%
ENTREGÓ
AMPLIAMENTE
REELABORADO O
ABANDONADO
DESPUÉS 19%
PAGADO
PERO NO
47%
ENTREGADO
29%
ENTREGADO PERO
NUNCA USADO
SATISFACTORIAMENTE
GAO 1979
CANCELADO
DURANTE EL TERMINADO Y
DESARROLLO OPERATIVO, PERO
FUERA DE PLAZO,
FUERA DE
PRESUPUESTO Y SIN
SATISFACER TODOS
31.10% LOS REQUISITOS
53%
TERMINADO
DENTRO DE
PLAZO Y
PRESUPUESTO
CUMPLIENDO
TODOS LOS
16.20%
REQUISITOS
GRUPO STANDISH
FACTORES DE ÉXITO Y DE
FRACASO
 Implicación de los  Falta de información
Usuarios por parte de los
 Apoyo de los directivos usuarios
 Enunciado claro de los  Especificaciones y
requisitos requisitos incompletos
 Especificaciones y
requisitos cambiantes
M.C. Miriam Zulma Sánchez Hernández

Brooks 1995, pág.199
“La parte más difícil de construir de un

sistema de software es precisamente saber
QUÉ construir. Ninguna otra parte del
trabajo conceptual es tan difícil como
establecer los requerimientos técnicos
detallados, incluyendo todas las interfaces
con gente, máquinas y otros sistemas.
Ninguna otra parte del trabajo afecta tanto
el sistema si es hecha mal. Ninguna otra
parte es más difícil de rectificar después”

¿REQUISITO? : Definición
 Según la IEEE
 Una condición o capacidad que un usuario
necesita para resolver un problema o lograr un
objetivo
 Una condición o capacidad que debe tener un
sistema o un componente de un sistema para
satisfacer un contrato, una norma, una
especificación u otro documento formal.

¿Qué son los
requerimientos?
 Los requerimientos son la pieza fundamental
en un proyecto de desarrollo de software, en
ellos se basan muchos participantes del
proyecto para:
 Planear el proyecto y los recursos que se usarán
en él.
 Especificar el tipo de verificaciones que se habrán
de realizar al sistema.
 Planear la estrategia de prueba a la que habrá de
ser sometido el sistema.
 Son el fundamento del ciclo de vida del proyecto.

¿QUÉ ES LA INGENIERÍA DE
REQUERIMIENTOS?
 SEGÚN ORTAS 1997:
 La Ingeniería de Requerimientos es
un conjunto de actividades en las
cuáles, utilizando técnicas y
herramientas, se analiza un
problema y se concluye con la
especificación de una solución.

De acuerdo con Bohem,
 Es la disciplina para desarrollar una especificación
completa, consistente y no ambigüa, la cual servirá
como base para acuerdos comunes entre todas las
partes involucradas y en dónde se describen las
funciones que realizará el sistema.
Según Rational Software Corporation

 La IR es un enfoque sistémico para recolectar,
organizar y documentar los requerimientos del
sistema; es también el proceso que establece y
mantiene acuerdos sobre los cambios de
requerimientos, entre los clientes y el equipo del
proyecto.
Desde otro enfoque… [Duran
2000]
 Es un proceso de
descubrimiento y
comunicación de las
necesidades de
clientes y usuarios y
la gestión de los
cambios de dichas
necesidades.

Especificación de
Requerimientos (ERS)
 Una especificación de
Requerimientos de Software es
un documento que contiene una
descripción completa de qué hará
el software sin describir cómo lo
hará.

¿Porqué son importantes los
Requerimientos?
¿Porqué perder mi tiempo

preocupándome por los
requerimientos?
¿Porqué no ahorro ese dinero eliminando
esa etapa innecesaria?
 “Si no se tienen los requerimientos
correctos, no se puede diseñar o
construir el producto correcto…”
COMPROBEMÓSLO!!
¿Porqué son importantes los
Requerimientos?
 HIPÓTESIS 1. Entre más tarde detecte un error en el ciclo
de vida del desarrollo de software, más caro costará
repararlo.
 HIPÓTESIS 2. Muchos errores permanecen latentes y no son

detectados hasta después de que la etapa ha sido terminada.
 HIPÓTESIS 3. Los errores hechos en la especificación de

requerimientos son típicamente hechos incorrectos,
omisiones, inconsistencias y ambigüedades.
 HIPÓTESIS 4. Los errores de requerimientos pueden ser

detectados

Hipótesis 1
Entre más tarde detecte un error
en el ciclo de vida del desarrollo
de software, más caro costará
repararlo.
HIPÓTESIS 1
ETAPA COSTO RELATIVO

DE REPARACIÓN
Requerimientos 0.1-0.2
Diseño 0.5
Codificación 1
Prueba 2
Pruebas de acept. 5
Mantenimiento 20
Hipótesis 2
Muchos errores permanecen latentes
y no son detectados hasta después de
que la etapa ha sido terminada
HIPÓTESIS 2
EL PROBLEMA
REAL
Especificación
Especificación Especificación de
correcta errónea Requerimient
os
Diseño Diseño Diseño basado en

Diseño
correcto erróneo Especific. errónea
Programas
Programas Errores de Programas basados
basados en diseño Implementación
correctos Programación erróneo en especific. errónea
Funciones Errores Errores Errores Pruebas

correctas corregibles incorregibles Ocultos
PROGRAMA IMPERFECTO
Hipótesis 3
Los errores hechos en la
especificación de requerimientos son
típicamente hechos incorrectos,
omisiones, inconsistencias y
ambigüedades
HIPÓTESIS 3
Tipos de Errores de Requerimientos confusos
50%
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
.
re ctos m isió
n
te ncia üed ad spe cif
r
s in
co O
co nsis Am
big e
. N oZulma Sánchez Hernández
M.C. Miriam
ho I n Re q
He c
Hipótesis 4
Los errores de requerimientos
pueden ser detectados
HIPÓTESIS 4
¿Podemos encontrar los errores?
10%
Otra
10%
Evaluación
5%
Integración
10%
Pruebas
65%
Inspección
0% 10% 20% 30% 40% 50% 60% 70%

% de errores
CONCLUSIONES
 Se cometen muchos errores de requerimientos al
hacerlos
 Muchos de estos errores no son detectados a
tiempo
 Muchos de estos errores pueden ser detectados a
tiempo
 No detectar estos errores puede contribuir a
elevar los costos del software

PROCESO DE LA INGENIERÍA DE
REQUERIMIENTOS

¿Para qué un Proceso de
Ingeniería de Requerimientos?
El proceso de Ingeniería de Requerimientos es
un conjunto estructurado de actividades,
mediante las cuáles obtenemos, validamos y
mantenemos el documento de especificación de
requerimientos (ERS).

Proceso de la Ingeniería de Requerimientos
Participación
del usuario
Retroalimentación
del usuario
Requerimientos
del usuario
Especificación Modelos a validar

por el usuario
Estudio de de requerimientos
factibilidad
Obtención y
Especificación Validación
análisis
Modelo de
Conocimiento requerimientos
Necesidad de más Resultado de

conocimiento validación

ESTUDIO DE FACTIBILIDAD
 Para todos los sistemas nuevos, el proceso de la
Ingeniería de Requerimientos empieza con el estudio
de Factibilidad.
 La entrada de este es una descripción resumida del
sistema y de cómo se utilizará dentro de la
organización. El resultado del estudio es un informe
que recomienda si es conveniente llevar a cabo la
Ingeniería de Requerimientos y el proceso del
desarrollo del sistema.
INGENIERIA
DE
ORGANIZACIÓN
SI REQUERIMIENTOS
¿SIRVE?
NO

ESTUDIO DE FACTIBILIDAD
 Un estudio de factibilidad es un estudio corto y orientado

a resolver varias preguntas.
 ¿El sistema contribuye a los objetivos generales del
sistema?
 ¿El sistema se puede implementar utilizando la
tecnología actual y con las restricciones de costo y
tiempo?
 ¿El sistema puede integrarse a otros que existen en la
organización?

OBTENCIÓN Y ANÁLISIS DE
REQUERIMIENTOS
 Es el proceso que sirve para determinar el dominio de la
aplicación, cuales servicios debe proporcionar el sistema, así
como su desempeño requerido, las restricciones de
hardware, etc. Se trabaja estrechamente con los usuarios a
fin de conocer la problemática en detalle.
 Las actividades que cubre son:

 Comprensión del dominio
 Recolección de requerimientos
 Clasificación de requerimientos
 Resolución de conflictos
 Priorización
 Verificación de requerimientos

Especificación de
Requerimientos
Verificación de
Requerimientos
DOCUMENTO DE
Comprensión REQUERIMIENTOS
Priorización
del dominio
Recolección de Resolución de
Requerimientos conflictos
PROCESO DE OBTENCION
Y ANÁLISIS DE
Clasificación REQUERIMIENTOS

HERRAMIENTAS DE EXTRACCIÓN Y
ANÁLISIS
 Herramientas para recolección de datos
 Capturan detalles que describen sistemas y
procedimientos en uso. Documentan procesos y
actividades de decisión.
 Herramientas para Diagramación
 Crean representaciones gráficas de sistemas y
actividades. Apoyan el dibujo y revisión de DFD
e íconos asociados con el análisis estructurado.
 Herramientas para el Diccionario
 Registran y mantienen descripciones de los
elementos del sistema, tales como grupos de
datos, procesos y almacenamiento de datos.
 Herramientas automatizadas
 Prototipos
 Hay de enfoque cerrado (desechable) y enfoque
abierto (evolutivo)

HERRAMIENTAS DE EXTRACCIÓN Y ANÁLISIS
Herramienta Extracción Análisis Especificación Validación
Entrevistas y Cuestionario X
Sistemas existentes X X
Grabaciones video/audio X X
Brainstorming X X
Arqueología de doctos. X X
Aprendiz X
Observación X
Prototipos X X
FODA X
Diagrama de pescado X X X
Glosario X X X X
Casos de uso X X X X
Casa de Calidad QFD X
Checklist X X
Diagramas FD X X
Modelos de clases X X
Diagramas de estado X X
(transición, actividades,
redes de petri)
ENTREVISTAS Y CUESTIONARIOS
 Las entrevistas y cuestionarios se emplean para reunir

información proveniente de personas o grupos,
información que se obtiene conversando con el
encuestado.
 Para realizar las entrevistas, conviene llevar preparado un

cuestionario. Un cuestionario consiste en un conjunto de
preguntas presentadas a una persona para su respuesta. La
forma de la pregunta influye en las respuestas, por lo que
hay que planearlas cuidadosamente.
 Las preguntas se dividen en dos categorías: Abiertas y
Cerradas.

SISTEMAS EXISTENTES
 Esta técnica consiste en analizar distintos sistemas ya

desarrollados que estén relacionados con el sistema a ser
construido.
 Por un lado, se pueden analizar las interfases de usuario,
observando el tipo de información que se maneja y cómo es
manejada. Esto puede ser útil para descubrir información
importante, que tal vez el cliente/usuario haya fallado en
comunicar.
 También es útil analizar las distintas salidas que los sistemas
producen (listados, consultas, etc), porque siempre pueden
surgir nuevas ideas sobre la base de éstas.

GRABACIONES DE VIDEO Y AUDIO
 Básicamente existen dos formas de utilizar las grabaciones:
como registro y apoyo de las entrevistas, y para analizar
algún proceso en particular.
 Como apoyo, permite centrar la atención en la entrevista en
vez de distraerse tomando notas de todo lo que se dice.
Permite analizar los temas con más detenimiento y con una
visión más global.
 Como análisis de Procesos, permite ver y analizar el proceso
la cantidad de veces que sea necesario, además de que al
filmar el lugar de trabajo estamos capturando el proceso de
trabajo, lo que evita que impongamos nuestras expectativas y
preferencias.

BRAINSTORMING (Tormenta de ideas)
 Este es un método que se usa para generar ideas.

La intención en su aplicación es la de generar la máxima
cantidad posible de requerimientos para el sistema.
 No se debe detener a pensar si la idea es o no del todo

utilizable. La intención de este ejercicio es generar, en una
primer instancia, muchas ideas. Luego se irán eliminando
en base a distintos criterios como, por ejemplo, “caro”,
“impracticable”, “imposible”, etc.

ARQUEOLOGÍA DE DOCUMENTOS
 Con la aplicación de esta herramienta se tratan de
determinar posibles requerimientos sobre la base de
inspeccionar la documentación utilizada por la
empresa; por ejemplo, boletas, facturas, remisiones, etc.
 Sirve como complemento de las demás técnicas y ayuda

a obtener información que de otra manera sería muy
difícil de conseguir.
 ¿Cuál es el propósito de este documento?
 ¿Quién lo usa? ¿Por qué? ¿Para qué?
 ¿Cuáles son las tareas que realizan con este documento?

APRENDIZ
 Se basa en la idea del maestro y el aprendiz. El

aprendiz es representado por el analista y el
usuario/cliente cumple con el rol de maestro.
 El aprendiz se sienta con el maestro a aprender por medio

de la observación, haciendo preguntas como ¿por qué hizo
eso? y ¿Qué significa eso?, y también realizando algún
trabajo bajo la supervisión del maestro.
 La aplicación de esta herramienta es muy útil, ya que a
veces es difícil para el cliente/usuario el explicar cómo
realiza su trabajo.

OBSERVACIÓN
 Es sumamente difícil describir cómo hacer el nudo de un

calzado deportivo, pero es sumamente fácil mostrar los
pasos para hacerlo.
 Observar como se hacen las cosas es una buena manera

de entender lo que estas requieren.
 Dentro de la estrategia de observar, se tienen que buscar

estructuras y patrones. La estructura del trabajo para los
usuarios suele ser invisible, por lo que será nuestro trabajo
realizar las abstracciones necesarias.

ESPECIFICACIÓN Y DOCUMENTACIÓN
DE LOS REQUERIMIENTOS
 Esta actividad se enfoca al proceso de documentación del

comportamiento deseado del sistema. La especificación
de requerimientos es un acuerdo aprobado entre usuarios
y desarrolladores del software y debe tener al menos las
siguientes características:
 Contener todos los requerimientos deseados
 Cada requerimiento solo tiene una interpretación posible
 El cumplimiento de cualquier requerimiento no debe
provocar conflictos con el cumplimiento de otro

requerimiento, es decir, que sea consistente.
 Prioridades definidas

Cómo expresar los
Requerimientos de Sistemas
 Los requerimientos deben de ser:
 Especificados por escrito

 Posibles de probar o verificar
 Descritos como una característica del
sistema a entregar.
 Lo más abstracto y conciso posible.

Como expresar los requerimientos
para una buena precisión y
entendimiento
Entendimiento
Lenguaje
natural
Lenguaje Metodologías
estructurado (CASE,etc.)
Especificaciones
Formales
Precisión

DOCUMENTACIÓN DE REQUERIMIENTOS DE
SOFTWARE
 Los requerimientos deben escribirse de modo que sean

significativos no sólo para los clientes, sino también
para los diseñadores que integran el equipo de
desarrollo.
Definición de Requerimientos
Clases de documentos
de Requerimientos
Especificación de Requerimientos

DOCUMENTO: DEFINICIÓN DE
REQUERIMIENTOS
 Está escrita en términos que el cliente puede

entender. Es un listado completo de todas las cosas
que el cliente espera que haga el sistema propuesto.
Es escrito en forma conjunta por el cliente y el
desarrollador.
1. Primero se perfila el propósito general del sistema.
2. Se describen los antecedentes y los objetivos del
desarrollo del sistema.

DOCUMENTO: DEFINICIÓN DE
REQUERIMIENTOS
3. Si el cliente tiene un nuevo enfoque propuesto para

resolver el problema, se perfila una descripción del
enfoque.
4. Una vez registrada esta vista global del problema, se
describen en detalle las características del sistema
propuesto. Se definen el límite del sistema y las
interfaces que lo vinculan con el entorno.
5. Por último, se discute el ambiente en el cuál operará el
sistema. Se incluyen requerimientos para el soporte, la
seguridad y la privacidad.

DOCUMENTO: ESPECIFICACIÓN DE
REQUERIMIENTOS
 Se escribe desde la perspectiva del desarrollador.

Reitera la definición de los términos técnicos
apropiados para el desarrollo del diseño de un sistema;
es la contrapartida técnica al documento de definición
de requerimientos, y es escrito por analistas de
requerimientos.
 Por ejemplo, el cliente no puede comprender la
definición de un requerimiento en términos de una
relación matemática compleja definida con una serie de
ecuaciones.

VALIDACIÓN DE LOS
REQUERIMIENTOS
 Esta actividad tiene mucho en común con el análisis, ya que
implica encontrar problemas con los requerimientos. Sin
embargo, son procesos distintos puesto que la validación
comprende un bosquejo completo del documento de
requerimientos, mientras que el análisis implica trabajar con
los requerimientos incompletos. Durante esta actividad se
deben llevar a cabo diferentes tipos de verificación en el
documento de requerimientos que incluyen verificaciones de:
 Validez
 Consistencia
 Integridad
 Realismo
 Verificabilidad

EJERCICIOS
 De acuerdo a los criterios que debe

cumplir la especificación de
requisitos de un sistema, comentar
los siguientes:
 “Todos los clientes tienen el mismo
identificador”
 “Identificador de los clientes. A
determinar”
 “El sistema tendrá una interfaz amistosa”
 “Se asocia la factura con el documento
de pago y se cambia su estado”

EJERCICIOS
 Representar una entrevista entre el dueño de un

videoclub y un analista, teniendo en cuenta que en
este caso el usuario desconoce por completo la
informática. Prestar atención al modo en que se
extrae información sobre el funcionamiento del
videoclub, así como de las expresiones y posturas
adoptadas por cada uno de los “actores”.
 Elaborar un cuestionario para el análisis de requisitos
de una red de concesionarios de venta de
automóviles. Téngase en cuenta los volúmenes de los
datos, y las operaciones, características de
seguridad, estándares, etc.

1.1. REQUERIMIENTOS DE PROCESO
1.2. REQUERIMIENTOS DE LOS
USUARIOS
1.3. REQUERIMIENTOS PARA EL ANÁLISIS
Y NEGOCIACIÓN
1.4. REQUERIMIENTOS PARA LA GESTIÓN

1.1. REQUERIMIENTOS DE PROCESO
 Los requerimientos del proceso son a nivel organizacional,
describen el “cómo”, es decir, describen los procedimientos y
políticas que las organizaciones deben seguir así como las
restricciones que deben obedecer, por ejemplo, estándares
usados en los procesos, los requerimientos de
implementación, etc.
 Los requerimientos de proceso se imponen a menudo como la

manera de alcanzar un cierto requerimiento de alto nivel del
producto. Por ejemplo, un requerimiento del costo máximo
del desarrollo (requerimiento de proceso) se puede imponer
para ayudar a alcanzar un requerimiento del precio máximo
de venta (requerimiento del producto).

1.2. REQUERIMIENTOS DE LOS
USUARIOS
 Los requerimientos de los usuarios son todas sus necesidades,
las cuales se traducen a los requerimientos de lo que esperan
que un nuevo sistema realice y de las restricciones que lleva
consigo. Un ejemplo de tales necesidades pueden ser las
siguientes:
 Obtener soluciones a problemas en su trabajo bajo
el sistema actual
 Una interfaz más amigable, rápida

de aprender, fácil de usar
 Un tiempo de respuesta más corto, etc.

Requerimientos de usuarios…
Requerimientos de usuario Requerimientos del sistema
LENGUAJE COTIDIANO LENGUAJE TÉCNICO

Los usuarios… ???
 Cuando se están investigando los requerimientos, el analista
se encuentra con el problema de la comunicación con el
usuario pues el lenguaje cotidiano de ambos no es igual. Por
ejemplo:
 Falta de claridad
 Conocen de manera muy general lo que desean obtener
 No saben expresar o explicar lo que quieren del sistema
 Usan terminologías distintas
 Confunde los requerimientos funcionales y los no funcionales
 Confusión de requerimientos, pues expresan de varias formas
un mismo requerimiento

PARTICIPANTES EN EL PROCESO DE
SOFTWARE (stakeholders)
 Los supervisores del contrato
 Los clientes y los usuarios
 Los gerentes del negocio
 Los diseñadores
 Los verificadores

1.3. REQUERIMIENTOS PARA EL
ANÁLISIS Y LA NEGOCIACIÓN
 Una vez identificados los requerimientos completos, consistentes y no
ambiguos, se procede a clasificarlo. El analista debe hacerse la siguiente
pregunta con cada uno de los requerimientos: ¿El requerimiento es
necesario o representa una característica añadida que puede no ser
esencial cuando se haya finalizado el sistema? La razón de esta pregunta se
debe a que es común en clientes y usuarios solicitar más de lo que puede
realizarse, consumiendo recursos de negocios limitados, cómo sería el
sobrepasar el presupuesto y el tiempo requerido para el desarrollo del
sistema.
La clasificación de estos requerimientos es la siguiente:
 requerimientos esenciales, aquellos que deben ser absolutamente
satisfechos.
 requerimientos deseables, que son importantes pero no indispensables.
 requerimientos opcionales, que son posibles pero que podrían eliminarse

Proceso de Negociación
 Después de hacerse la clasificación de requerimientos, el
analista de sistemas realiza un proceso de negociación
con clientes, usuarios y el resto de los involucrados para
resolver los conflictos relacionados con ciertos
requerimientos según su prioridad. Parte de la
negociación de los requerimientos incluye identificar y
analizar los riegos asociados a cada requerimiento
además de efectuar estimaciones de costo, tiempo y
esfuerzo. Estas estimaciones ayudarán a una mejor
elección de cuáles requerimientos tienen mayor
prioridad que otros.

1.3. REQUERIMIENTOS PARA EL
ANÁLISIS Y LA NEGOCIACIÓN
 En esta actividad se incrementa la comunicación entre el equipo
de desarrollo y los afectados. Para que los requerimientos
puedan ser comunicados de manera efectiva, hay una serie de
consideraciones que deben tenerse en cuenta; entre las
principales tenemos:
 Documentar todos los requerimientos a un nivel de detalle

apropiado.
 Mostrar todos los requerimientos a los involucrados en el sistema.
 Analizar el impacto que causen los cambios a requerimientos antes
de aceptarlos.
 Establecer las relaciones entre requerimientos que indiquen
dependencias.
 Negociar con flexibilidad para que exista un beneficio mutuo.
 Enfocarse en intereses y no en posiciones

1.4. REQUERIMIENTOS PARA LA
GESTIÓN
 La gestión de requerimientos es el proceso de
comprender y controlar los cambios en los
requerimientos del sistema y se lleva a cabo junto con el
proceso de ingeniería de requerimientos. La planeación
comienza al mismo tiempo que la obtención inicial de
requerimientos y la administración activa debe iniciar
tan pronto esté lista la primera versión del documento de
requerimientos.
[Checar documento para ampliar la información]

PlanificaciÓn y Modelado Procesos de La Ingeniería

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PlanificaciÓn y Modelado Procesos de La Ingeniería

Загружено:

Авторское право:

Доступные форматы

UNIDAD I

M.C. Miriam Zulma Sánchez Hernández

“La parte más difícil de construir de un

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

Según Rational Software Corporation

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

¿Porqué perder mi tiempo

 HIPÓTESIS 2. Muchos errores permanecen latentes y no son

 HIPÓTESIS 3. Los errores hechos en la especificación de

 HIPÓTESIS 4. Los errores de requerimientos pueden ser

M.C. Miriam Zulma Sánchez Hernández

ETAPA COSTO RELATIVO

Diseño Diseño Diseño basado en

Funciones Errores Errores Errores Pruebas

0% 10% 20% 30% 40% 50% 60% 70%

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

Especificación Modelos a validar

Necesidad de más Resultado de

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

 Un estudio de factibilidad es un estudio corto y orientado

M.C. Miriam Zulma Sánchez Hernández

 Las actividades que cubre son:

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

 Las entrevistas y cuestionarios se emplean para reunir

 Para realizar las entrevistas, conviene llevar preparado un

M.C. Miriam Zulma Sánchez Hernández

 Esta técnica consiste en analizar distintos sistemas ya

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

 Este es un método que se usa para generar ideas.

 No se debe detener a pensar si la idea es o no del todo

M.C. Miriam Zulma Sánchez Hernández

 Sirve como complemento de las demás técnicas y ayuda

M.C. Miriam Zulma Sánchez Hernández

 Se basa en la idea del maestro y el aprendiz. El

 El aprendiz se sienta con el maestro a aprender por medio

M.C. Miriam Zulma Sánchez Hernández

 Es sumamente difícil describir cómo hacer el nudo de un

 Observar como se hacen las cosas es una buena manera

 Dentro de la estrategia de observar, se tienen que buscar

M.C. Miriam Zulma Sánchez Hernández

 Esta actividad se enfoca al proceso de documentación del

 Cada requerimiento solo tiene una interpretación posible

 El cumplimiento de cualquier requerimiento no debe

provocar conflictos con el cumplimiento de otro

M.C. Miriam Zulma Sánchez Hernández

 Los requerimientos deben de ser:

 Especificados por escrito

M.C. Miriam Zulma Sánchez Hernández

M.C. Miriam Zulma Sánchez Hernández

 Los requerimientos deben escribirse de modo que sean

M.C. Miriam Zulma Sánchez Hernández

 Está escrita en términos que el cliente puede

M.C. Miriam Zulma Sánchez Hernández

3. Si el cliente tiene un nuevo enfoque propuesto para