Este documento presenta una guía de trabajo de clase sobre ingeniería de requerimientos. Incluye preguntas y ejercicios para analizar los requerimientos de un proyecto de software, como identificar los requerimientos del cliente, recopilar requerimientos a través de reuniones y talleres, y definir requerimientos comunes, estimados y no estimados. También cubre temas como excepciones en casos de uso, patrones de análisis y la corrección de errores en la validación de requerimientos trabajando con el cliente.
0 calificaciones0% encontró este documento útil (0 votos)
26 vistas4 páginas
Este documento presenta una guía de trabajo de clase sobre ingeniería de requerimientos. Incluye preguntas y ejercicios para analizar los requerimientos de un proyecto de software, como identificar los requerimientos del cliente, recopilar requerimientos a través de reuniones y talleres, y definir requerimientos comunes, estimados y no estimados. También cubre temas como excepciones en casos de uso, patrones de análisis y la corrección de errores en la validación de requerimientos trabajando con el cliente.
Este documento presenta una guía de trabajo de clase sobre ingeniería de requerimientos. Incluye preguntas y ejercicios para analizar los requerimientos de un proyecto de software, como identificar los requerimientos del cliente, recopilar requerimientos a través de reuniones y talleres, y definir requerimientos comunes, estimados y no estimados. También cubre temas como excepciones en casos de uso, patrones de análisis y la corrección de errores en la validación de requerimientos trabajando con el cliente.
Este documento presenta una guía de trabajo de clase sobre ingeniería de requerimientos. Incluye preguntas y ejercicios para analizar los requerimientos de un proyecto de software, como identificar los requerimientos del cliente, recopilar requerimientos a través de reuniones y talleres, y definir requerimientos comunes, estimados y no estimados. También cubre temas como excepciones en casos de uso, patrones de análisis y la corrección de errores en la validación de requerimientos trabajando con el cliente.
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
Descargar como docx, pdf o txt
Está en la página 1de 4
Ingeniería en Sistemas Informáticos.
Análisis y Diseño de Sistemas. Unidad II – Ingeniería de Requerimientos Guía de Trabajo de clase 1. ¿Por qué muchos desarrolladores de software no ponen atención suficiente a la ingeniería de requerimientos? ¿Existen algunas circunstancias que puedan ignorarse?
Algunos desarrolladores suelen decir que estos requerimientos se van
conociendo durante el proceso de desarrollo comenzando sin saber siquiera lo que en verdad necesita el proyecto para llevarse a cabo, en ninguna circunstancia se deberían ignorar dichos requerimientos ya que es una pérdida de tiempo y retraso para el proyecto.
2. El lector tiene la responsabilidad de indagar los requerimientos de un
cliente que dice estar demasiado ocupado para tener una reunión. ¿Qué debe hacer?
Se supone una acción en conjunto con los involucrados del proyecto
recabar los requerimientos para el desarrollo del proyecto y en caso de que uno de los mismos se le dificulte el tema de tiempo para el mismo se podrían llevar a cabo “talleres” de trabajo colaborativo.
3. Analice algunos de los problemas que ocurren cuando los
requerimientos deben indagarse para tres o cuatro clientes distintos.
Ya que es un trabajo en grupo es más que probable que los que
participan del desarrollo del mismo puedan definir ideas contrarias a otras opiniones de los integrantes o clientes y por ende nos toca solucionar dicha incongruencia de opiniones al desarrollar el software. 4. ¿Por qué se dice que el modelo de requerimientos representa una fotografía instantánea del sistema en el tiempo?
Porque va modificándose a medida de que se desarrolla el proyecto y
los participantes van fijándose en el desarrollo de sus requerimientos de lo que se quiere construir.
5. Suponga que ha convencido al cliente (es usted muy buen vendedor)
para que esté de acuerdo con todas las demandas que usted hace como desarrollador. ¿Eso lo convierte en un gran negociador? ¿Por qué?
Porque se supone que fui capaz de recabar y plasmar los
requerimientos necesarios para desarrollar y terminar con éxito el proyecto cumpliendo con las expectativas explayadas por el cliente y el grupo detrás de la distribución y soporte del proyecto.
6. Desarrolle al menos tres “preguntas libres de contexto” adicionales que
podría plantear a un participante durante la concepción.
¿Qué planeamientos propondría en caso de que parte del proceso no se
concretase con éxito? ¿Qué limitantes son obviables para desarrollar exitosamente el proyecto? ¿Qué alcance extra no planeado brindaría como beneficio este proyecto?
7. Desarrolle un “kit” para recabar requerimientos. Debe incluir un conjunto
de lineamientos a fin de llevar a cabo la reunión para recabar requerimientos y los materiales que pueden emplearse para facilitar la creación de listas y otros objetos que ayuden a definir los requerimientos.
El kit propuesto podría abarcar:
- Simpleza y puntualidad siempre brindando una buena imagen laboral. - Investigación del entorno de trabajo o negocio que se quiere abarcar. - Contar con facilitadores para talleres o trabajos en grupos de desarrollo del proyecto. Materiales para usar: - Útiles para tomar notas dentro del grupo de desarrollo. - Pizarra o tablero en caso de ser presencial, caso contrario plataforma de videoconferencias. - Enlaces para plataformas de interacción dentro de talleres digitales.
8. Según se llegue a un acuerdo en el grupo de trabajo. La mitad de los
participantes desempeñará el papel del departamento de mercadotecnia y la otra mitad adoptará el del equipo para la ingeniería de software. Su trabajo es definir los requerimientos para la función de seguridad de CasaSegura descrita en el capítulo 5. Efectúe una reunión para recabar los requerimientos con el uso de los lineamientos presentados en este capítulo.
Requerimientos comunes: Las metas y objetivos establecidos
para el producto o sistema durante la reunión con el cliente. Si existen estos requisitos, los clientes estarán satisfechos. Ejemplos de requisitos típicos son el tipo de gráficos que deben mostrarse en la pantalla, las capacidades específicas del sistema y los niveles de rendimiento definidos.
Requerimientos estimados: Están implícitos en el producto o
sistema y pueden ser tan importantes que el cliente no los menciona explícitamente. tu ausencia resultará en algunas expectativas insatisfactorias que incluyen: facilidad de interacción hombre-máquina, operación general correcta y confiable, y facilidad de instalación de software.
Requerimientos no estimados: Estas características superan las
expectativas del cliente y serían muy satisfactorias si existieran. Por ejemplo, el software de un teléfono nuevo viene con características estándar, pero si incluye características inesperadas (como una pantalla táctil, correo de voz visual, etc.), complacerá a todos los usuarios del producto.
9. ¿Qué representan las “excepciones” en un caso de uso?
Estas situaciones desencadenan un comportamiento fuera del flujo de
uso normal o "feliz" en el sistema. Aunque no se ajusten a los procesos normales, deben ser evaluados, analizados, verificados e implementados (controlados y satisfechos).
10. Describa con sus propias palabras lo que es un patrón de análisis.
Como su nombre lo indica, producen soluciones parciales o completas a
situaciones, problemas, dominios o modelos, y análisis de requerimientos que se manifiestan como patrones o que han sido previamente experimentados y parcial o totalmente resueltos.
11. ¿Qué significa ganar-ganar en el contexto de una negociación durante la
actividad de ingeniería de los requerimientos?
Tanto el cliente como el equipo se benefician de una serie de
negociaciones que mantienen contento al cliente y brindan buenas condiciones de trabajo al equipo.
12. ¿Qué piensa que pasa cuando la validación de los requerimientos
detecta un error? ¿Quién está involucrado en su corrección? Evidentemente, debería corregirse. Se puede realizar a través de la retroalimentación conjunta con el cliente, quien es quien realiza la aclaración y corrección indirecta de los requerimientos.