Elicitación de requerimientos Obtención de requerimientos	Es el medio por el cual los analistas determinan los problemas y necesidades de los clientes.
La recolección de requerimientos debe cumplir	Con la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema.
¿A qué se denomina determinación de requerimientos?	❑ Es el estudio de un sistema para conocer cómo trabaja y dónde es necesario efectuar mejoras. ❑ Un requerimiento es una característica que debe incluirse en un nuevo sistema. ❑ Vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él
Tipos de requerimientos	- Requerimientos funcionales. - Requerimientos no funcionales. - Requerimientos de interface
Requerimientos funcionales	Las tareas que el sistema debe realizar - Comportamiento del sistema - Las tareas que debe de realizar - Detalles sin ambigüedad - Descripciones sin redundancia
Requerimientos no funcionales	No son funcionales pero resultan deseables para el usuario. - Tiempos de respuesta - Características de usabilidad - Facilidad de mantenimiento
Requerimientos de interface	Definen las interacciones del sistema con su entorno
Características de los requerimientos	- Necesario - Conciso - Completo - Consistente - No ambiguo - Verificable - Alcanzable - Trazable - Medible - Priorizado
Necesario - Característica de requerimientos	Es necesario si su omisión provoca una deficiencia en el sistema a construir.
Conciso - Característica de requerimientos	Un requerimiento es conciso si es fácil de leer y entender
Completo - Característica de requerimientos	Un requerimiento es completo si no se necesitan ampliar detalles para comprenderlo.
Consistente - Característica de requerimientos	Es consistente si no es contradictorio con otro requerimiento
No ambiguo - Característica de requerimientos	No es ambiguo cuando solo se tiene una sola interpretación.
Verificable - Característica de requerimientos	Un requerimiento es verificable cuando puede se cuantificado y se puede verificar por los siguientes métodos: - Inspección - Análisis - Demostración de pruebas
Trazable - Característica de requerimientos	Se puede trazar el origen de cada requerimiento
Medible - Característica de requerimientos	Debe de poder medirse objetivamente mediante indicadores
Priorizado - Característica de requerimientos	Ordenado por importancia que tenga para el cliente y escalabilidad
Clases de fuentes	- Entrevistas - Formularios - Desarrollos previos - Productos del mundo real
Entrevistas	Individual - grupal Productos: - Anotaciones propias o de terceros - Minutas propias o de terceros - Respuestas de cuestionarios.
Desarrollo previo	- Requerimientos - Modelo de datos - Diseño - Software - Manuales
Desarrollo previo - Requerimientos	- Documento de especificación de requerimiento. - Diagramas de casos de uso
Desarrollo previo - Modelo de datos	Diagramas de entidad relación ER
Desarrollo previo - Software	- Prototipos - Aplicaciones
Desarrollo previo - Manuales	- Manuales de usuarios - Manuales de operador
Diseño	- DFD A data-flow diagram - Carta de estructura - Diagrama de clases - Diagramas de interacción - Diagramas de estados - Diagramas de actividades
Stakeholders	Son los llamados participantes o interesados
Defecto Implicación insuficiente del cliente	Consecuencia Problemas en la validación del producto obtenido
Defecto Requisitos crecientes y cambiantes	Consecuencia Degradación de la estructura y arquitectura del producto
Defecto Requisitos ambiguos	Consecuencia Pérdida de tiempo en re-codificación
Defecto Requisitos innecesarios	Consecuencia Trabajo innecesario
Defecto Requisitos insuficientes	Consecuencia Problemas en la validación del producto obtenido. Error en la estimación y planificación
Defecto Omisión de las necesidades de grupos de usuarios	Consecuencia Usuarios insatisfechos
Zowghi y Coulin	Entrevista: Stakeholders y expertos del área Desarrollo previo: Procesos y sistemas existentes, documentación de sistemas y procesos de negocio
Alexander y Stevens	Entrevistas: Entrevistas; workshops; mesa de ayuda y equipo de soporte; entrenadores y consultores Desarrollo previo: Prototipos; usos no intencionales de productos; diseños y especificaciones existentes; informes de problemas; sugerencias y quejas de consumidores; observar al usuario; representar lo que debe suceder; mejoras hechas por usuarios; productos rivales Productos del mundo real: Contratos mal escritos
Wiegers	Entrevistas: Entrevistas con potenciales usuarios; encuestas de marketing y cuestionarios de usuarios. Desarrollo previo: Informes de problemas y pedidos de mejora al sistema actual; especificaciones de requerimientos; observación del usuario; análisis de escenarios de tareas del usuario; productos competitivos actuales.
Loucopoulos y Karakotas	Entrevistas: Expertos del dominio; stakeholders del sistema mayor que aloja el sistema software Desarrollo previo: Software disponible en el dominio; software similar en otros dominios Productos del mundo real: Estándares nacionales e internacionales; literatura acerca del dominio.
Usuario final	Están relacionados con la usabilidad. Serán quienes utilicen las interfaces y los manuales de usuario
Usuario Líder	Son los que comprenden el ambiente del sistema o dominio del problema. Proporcionan al equipo técnico los detalles y requerimientos de las interfaces.
Personal de mantenimiento	Son los responsables de la administración de cambios de la implementación y resolución de anomalías. Su trabajo es revisar y mejorar los procesos del producto ya finalizado.
Analistas y programadores	Responsables del desarrollo del producto en sí; interactúan directamente con el cliente.
Personal de pruebas	Encargados de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Validan si los requerimientos satisfacen las necesidades del cliente.
Otras personas	Pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.
Stakeholders	Este término se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requisitos del sistema. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización se que verán afectados por dicho sistema. Los stakeholders también son los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los administradores del negocio, los expertos en el dominio del sistema, los representantes de los trabajadores, etc.
Preparación de la Entrevista	❑ Determinar la posición en la organización del futuro entrevistado, responsabilidades, actividades, etc. ❑ Preparar las preguntas que van a plantearse, y los documentos necesarios. ❑ Fijar un límite de tiempo y preparar la agenda para la entrevista. ❑ Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad ❑ Hacer la cita con la debida anticipación.
Conducción de la Entrevista	❑ Explicar con toda amplitud el propósito y alcance del estudio. ❑ Explicar la función propietaria cómo analista y la función que se espera conferir al entrevistado. ❑ Hacer preguntas específicas para obtener respuestas cuantitativas. ❑ Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares. ❑ Evitar el cuchicheo y las frases carentes de sentido. ❑ Ser cortés, absteniéndose de emitir juicios de valores. ❑ Conservar el control de la entrevista, evitando divagaciones y los comentarios al margen de la cuestión. ❑ Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas.
Secuela de la Entrevista	❑ Escribir los resultados ❑ Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. ❑ Archivar los resultados de la entrevista para referencia y análisis posteriores.
Del usuario Entrevista Preguntas abiertas	¿Quién es el cliente? ¿Quién es el usuario? ¿Son sus necesidades diferentes? ¿Cuáles son sus habilidades, capacidades, ambiente?
Del proceso Entrevista Preguntas abiertas	¿Cuál es la razón por la que se quiere resolver este problema? ¿Cuál es el valor de una solución exitosa? ¿Cómo usted resuelve el problema actualmente? ¿Qué retrasos ocurren o pueden ocurrir?
Del proceso Entrevista Preguntas abiertas	¿Qué problemas podría causar este producto en el negocio? ¿En qué ambiente se usará el producto? ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento? ¿Qué obstá***** afectan la eficiencia del sistema?
Forma de pregunta abierta	Ejemplo: obtener la información sobre las características de diseño críticas para los empleados. "Algunos empleados han sugerido que la mejor forma para hacer eficiente el procesamiento de pedidos es instalar un sistema de computadora que maneje todos los cálculos..." Bajo estas circunstancias ¿apoyaría usted el desarrollo de un sistema de este tipo?
Forma de pregunta cerrada	Ejemplo: obtener la información sobre las características de diseño críticas para los empleados. "La experiencia le ha proporcionado una amplia visión en cuanto a la forma en la que la empresa maneja los pedidos...“ Me gustaría que usted contestara algunas preguntas específicas en relación en lo anterior: -¿Qué etapas trabajan bien? ¿Cuáles no? -¿En donde se presenta la mayor parte del problema? - ¿Cuándo ocurre un atraso, cómo se maneja?
Entrevista estructurada - PROS	❑ Asegura la elaboración uniforme de las preguntas para todos los que van a responder. ❑ Fácil de administrar y evaluar. ❑ Evaluación más objetiva tanto de quienes responden como de las respuestas a las preguntas. ❑ Se necesita un limitado entrenamiento del entrevistador. ❑ Resulta en entrevistas más pequeñas.
Entrevista no estructurada - PROS	❑ El entrevistador tiene mayor flexibilidad al realizar las preguntas adecuadas a quien responde. ❑ El entrevistador puede explotar áreas que surgen espontáneamente durante la entrevista. ❑ Puede producir información sobre área que se minimizaron o en las que no se pensó que fueran importantes.
Entrevista estructurada - CONTRAS	❑ Alto costo de preparación. ❑ Los que responden pueden no aceptar un alto nivel en la estructura y carácter mecánico de las preguntas. ❑ Un alto nivel en la estructura puede no ser adecuado para todas las situaciones. ❑ El alto nivel en las estructuras reduce responder en forma espontánea, así como la habilidad del entrevistador para continuar con comentarios hacia el entrevistado.
Entrevista no estructurada - CONTRAS	❑ Puede utilizarse negativamente el tiempo, tanto de quien responde como del entrevistador. ❑ Los entrevistadores pueden introducir sus sesgos en las preguntas o al informar de los resultados. ❑ Puede recopilarse información extraña ❑ El análisis y la interpretación de los resultados pueden ser largos. ❑ Toma tiempo extra recolectar los hechos esenciales.
Análisis de tareas ¿Cómo lo llevo a cabo?	❑ Descomposición de tareas a alto nivel, donde las tareas mayores se dividen en subtareas. Este paso proporciona una buena perspectiva de las tareas que están siendo analizadas. ❑ Diagrama del flujo de tareas, donde las tareas específicas se dividen en pasos básicos de tarea. No hay que descuidar la utilidad de una descripción textual de los diagramas.
Etapas de la descomposición de tareas	❑ Se identifica la tarea a analizar a partir de la lista de tareas. ❑ Se descompone entre 4 y 8 subtareas. Estas subtareas deberían estar especificadas en términos de objetivos y, entre ellas, deberían cubrir el área de interés. ❑ Se dibujan las subtareas como un diagrama asegurando que está completo. ❑ Hay que decidir sobre el nivel de detalle de la descomposición, lo que asegurará un tratamiento consistente de la situación (será de gran ayuda un registro escrito). Podría decidirse que la descomposición de tareas continuara hasta que los flujos fueran representados con mayor facilidad en un diagrama de flujo de tareas.
Observación	Técnica - observación Instrumento - Diario o bitácora de campo Herramienta de registro - Cuaderno / libreta / audio
Planificación del proceso de observación	- ¿Qué voy a observar? ¿Por qué? \| La definición del problema - ¿Cómo observar? \| Modalidad de observación - ¿Dónde observar? \| El escenario - ¿Qué observar? \| El enfoque - ¿Cuándo observar? \| La temporalización - ¿Cómo registrar? ¿Con qué medios? \| Técnicas de registro - ¿Cómo analizar? \| Técnicas de análisis
Prototipos	- Prototipo rápido - Prototipo evolutivo
Prototipo rápido	Es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En este sentido, el prototipo puede ser visto como una aceptación tácita de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a "controlar" su constante evolución.
Prototipo evolutivo	Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida está dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre después de que el producto se ha entregado.
Convenciones para diagramas utilizados en escenarios	❑ Los datos proporcionados desde un punto de vista o proporcionados a éste se representan como elipses. ❑ Las entradas y salidas de la información de control se ubican en la parte superior de cada recuadro. ❑ Las salidas de datos se ubican a la derecha de cada recuadro. Si no están encerradas, significa que pertenecen al sistema. ❑ Las excepciones se muestran en la parte inferior del recuadro. Si existen varias excepciones posibles, éstas se encierran en un recuadro. ❑ El nombre del siguiente evento esperado después de completar el escenario se muestra en un recuadro sombreado.

Descubre

Crear Tarjetas

Acerca de Nosotros

Explore Tarjetas

Comparta este Set de Tarjetas de Aprendizaje

Tarjetas de Aprendizaje relacionadas

Ingeniería De Requerimientos

Cómo estudiar sus tarjetas

Rango de Cartas a estudiar

63 Cartas en este set