4. refuerzo de requerimientos.

 

1. ¿Qué es un requerimiento funcional? *

 

 

Requisito funcional:

Se puede pensar en un requisito funcional como una característica del producto que el usuario detecta.

Es una declaración de cómo debe comportarse un sistema. Define lo que el sistema debe hacer para satisfacer las necesidades o expectativas del usuario.

Los requisitos funcionales se pueden considerar como características que el usuario detecta, puede ser una característica obvia, como un gran botón Agregar al carrito. Pero también puede ser una característica menos obvia, como calcular correctamente el impuesto sobre las ventas para la compra en línea del usuario.

 

 

2. ¿Qué es un requerimiento NO funcional? *

 

 

Requisito no funcional:

Los requisitos no funcionales (NFR) son las restricciones impuestas a un sistema que definen sus atributos de calidad. Por lo general, se denotan con adjetivos como seguridad, rendimiento y escalabilidad. Los requisitos no funcionales son importantes porque ayudan a garantizar que el sistema satisfaga las necesidades del usuario.

categorias de requisitos no funcionales

Los requisitos no funcionales se pueden dividir en dos categorías:

1.atributos de calidad: Estas son las características del sistema que determinan su calidad general. Los ejemplos de atributos de calidad incluyen seguridad, rendimiento y facilidad de uso.

2.restricciones: Estas son las limitaciones impuestas al sistema. Los ejemplos de restricciones incluyen el tiempo, los recursos y el entorno.

 

 

3. ¿Qué describe un requerimiento?

 

 

“Una capacidad necesitada por un usuario para resolver un problema o llevar a cabo un objetivo”

que es un requisito?:

Los requisitos de un proyecto de software son las funciones, características y restricciones que debe cumplir el producto final. En otras palabras, los requisitos definen qué debe hacer el software, cómo debe verse y las condiciones que deben cumplirse para que se considere exitoso.

Recopilación de requisitos es fundamental para poder crear un producto que satisfaga las necesidades del consumidor o clienta. Es importante tener en cuenta que los requisitos pueden cambiar a lo largo del curso de un proyecto, por lo que es importante contar con un mecanismo para rastrear y administrar estos cambios.

//visuresolutions.com//

//www.northware.mx//

 

 

4. ¿Cuál es el máximo de horas para aplicar la técnica de observación?

 

 una sesión de observación efectiva suele durar entre 1 y 4 horas. Sin embargo, para estudios más exhaustivos, las observaciones pueden ser fragmentadas en sesiones múltiples a lo largo del tiempo, permitiendo una recolección de datos más completa y menos agotadora.

 

 

 

 

5. El análisis de documentos permite tener información sin interactuar con el usuario 

 

 Sí, el análisis de documentos permite obtener información sin la necesidad de interactuar directamente con los usuarios. Esta técnica es una forma de investigación cualitativa que implica examinar y analizar documentos existentes para extraer datos relevantes.

 

 

 

 

6. ¿Cómo deben ser los requerimientos?

 

 Los requerimientos en el contexto de un proyecto, especialmente en el ámbito de desarrollo de software o de sistemas, deben ser claros, completos y bien estructurados para asegurar que todos los involucrados comprendan lo que se espera y para guiar el trabajo de desarrollo y verificación.

 

 

 

 

 

7. El diagrama de causa/efecto se parece a un:

 

 El diagrama de causa y efecto, también conocido como diagrama de Ishikawa o diagrama de espina de pescado, se parece a un esqueleto de pescado. Este nombre alternativo proviene de su apariencia visual, donde la "cabeza" del pescado representa el problema principal y las "espinas" o ramas que se extienden desde la columna vertebral representan las posibles causas del problema.

 

 

 

 

8. ¿Qué tipo de preguntas llevan las entrevistas y las encuestas? 

 

 

Preguntas Abiertas:

• Descripción: Permiten respuestas detalladas y amplias, dando al entrevistado la libertad de expresar sus pensamientos y experiencias.
• Ejemplo: "¿Cómo describirías tu experiencia trabajando en este proyecto?"

Preguntas Cerradas:

• Descripción: Limitan las respuestas a opciones específicas, como "sí" o "no", o una selección de opciones predefinidas.
• Ejemplo: "¿Estás satisfecho con tu trabajo actual? (Sí/No)"

Preguntas Semiestructuradas:

• Descripción: Combinan elementos de preguntas abiertas y cerradas, proporcionando una estructura básica mientras permiten cierta flexibilidad en las respuestas.
• Ejemplo: "¿Qué aspectos de tu trabajo disfrutas más y por qué?"

Preguntas de Seguimiento o Probing:

• Descripción: Se utilizan para profundizar en una respuesta inicial y obtener más detalles.
• Ejemplo: "¿Puedes darme un ejemplo de lo que mencionaste?"

Preguntas Hipotéticas:

• Descripción: Plantean escenarios hipotéticos para comprender cómo actuaría o reaccionaría el entrevistado.
• Ejemplo: "¿Qué harías si te ofrecieran una posición similar en otra empresa?"

Preguntas Conductuales:

• Descripción: Se centran en comportamientos pasados para predecir comportamientos futuros.
• Ejemplo: "¿Puedes contarme sobre una vez en que tuviste que lidiar con un conflicto en el equipo?"

 

 

9.¿Por qué es importante que un requerimiento sea consistente?

 

La consistencia en los requerimientos es fundamental para asegurar el éxito de un proyecto, ya que evita conflictos, confusiones y malentendidos que pueden afectar la calidad del producto.

 

 

10. Clasifica las ventajas y desventajas de realizar correctamente el análisis de los requisitos del software

 

Ventajas

1. Mejor Comprensión del Proyecto:

   • Ventaja: Proporciona una comprensión clara y compartida de los objetivos del proyecto y las expectativas del cliente, asegurando que todas las partes interesadas estén alineadas.

2. Reducción de Errores y Retrabajos:

   • Ventaja: Identificar y resolver problemas potenciales y ambigüedades desde el principio reduce la probabilidad de errores costosos y retrabajos durante las fases posteriores del proyecto.

3. Mejora de la Planificación y Estimación:

   • Ventaja: Con requisitos claros y bien definidos, es más fácil planificar y estimar con precisión el tiempo, el costo y los recursos necesarios para completar el proyecto.

4. Facilita la Comunicación:

   • Ventaja: Proporciona una base sólida para la comunicación entre el equipo de desarrollo, los clientes y otras partes interesadas, lo que ayuda a evitar malentendidos y asegura que todos estén en la misma página.

5. Aumenta la Satisfacción del Cliente:

   • Ventaja: Al asegurar que el producto final cumpla con las expectativas y necesidades del cliente, se mejora la satisfacción del cliente y se construye una relación de confianza a largo plazo.

6. Mejora la Calidad del Producto Final:

   • Ventaja: Un análisis de requisitos bien realizado contribuye a la creación de un producto de alta calidad que cumple con todas las especificaciones y requisitos funcionales y no funcionales.

7. Facilita el Mantenimiento y Evolución del Sistema:

   • Ventaja: Documentación clara y detallada de los requisitos facilita el mantenimiento y la evolución del sistema, permitiendo que futuros cambios o mejoras se realicen de manera más eficiente.

Desventajas

1. Tiempo y Costo Inicial Elevados:

   • Desventaja: Realizar un análisis exhaustivo de los requisitos puede requerir una inversión significativa de tiempo y recursos al inicio del proyecto.

2. Riesgo de Sobrecarga de Información:

   • Desventaja: La recopilación de demasiada información o detalles irrelevantes puede complicar el proceso y distraer al equipo de los objetivos principales.

3. Dificultades en la Recolección de Requisitos:

   • Desventaja: Puede ser difícil obtener requisitos precisos y completos de todas las partes interesadas, especialmente si hay falta de cooperación o claridad en sus necesidades y expectativas.

4. Cambios en los Requisitos:

   • Desventaja: Los requisitos pueden cambiar durante el proyecto debido a nuevas necesidades del cliente, cambios en el mercado o tecnologías emergentes, lo que puede afectar la planificación y la ejecución.

5. Dependencia de la Calidad del Análisis:

   • Desventaja: La calidad del producto final depende en gran medida de la calidad del análisis de requisitos. Un análisis deficiente puede llevar a problemas significativos más adelante en el proyecto.

6. Posible Complejidad en la Gestión de Requerimientos:

   • Desventaja: La gestión de cambios y la trazabilidad de los requisitos pueden ser complejas y requieren herramientas y procesos adecuados para manejar de manera efectiva.

 

11. Seleccione las técnicas de recolección de información:

 

Entrevistas:

• Descripción: Conversaciones estructuradas o semiestructuradas con las partes interesadas para obtener información detallada sobre sus necesidades y expectativas.
• Ventajas: Permite obtener información profunda y clarificar dudas en tiempo real.
• Desventajas: Puede ser tiempo consumido y depende de la disponibilidad de los entrevistados.

Cuestionarios y Encuestas:

• Descripción: Conjuntos de preguntas enviadas a las partes interesadas para obtener sus respuestas de manera estructurada.
• Ventajas: Puede llegar a un gran número de personas rápidamente y es eficiente para recopilar datos cuantitativos.
• Desventajas: La calidad de las respuestas puede variar y no permite profundizar en temas complejos.

Revisión de Documentos:

• Descripción: Análisis de documentos existentes como manuales, informes, especificaciones, contratos, etc., para extraer información relevante.
• Ventajas: Proporciona información histórica y contextual, y no requiere la presencia de las partes interesadas.
• Desventajas: Puede ser difícil de interpretar y puede no estar actualizado.

Observación:

• Descripción: Observación directa de cómo las personas interactúan con el sistema o realizan sus tareas diarias para entender mejor sus necesidades.
• Ventajas: Proporciona información real sobre el comportamiento y el entorno de trabajo.
• Desventajas: Puede ser intrusivo y el comportamiento observado puede no ser representativo (efecto Hawthorne).

Talleres de Trabajo (Workshops):

• Descripción: Reuniones colaborativas donde varias partes interesadas trabajan juntas para definir requisitos y resolver problemas.
• Ventajas: Fomenta la colaboración y el consenso entre las partes interesadas.
• Desventajas: Requiere una planificación cuidadosa y la disponibilidad de todos los participantes.

Brainstorming (Lluvia de Ideas):

• Descripción: Sesiones donde los participantes generan ideas libremente para identificar necesidades y posibles soluciones.
• Ventajas: Fomenta la creatividad y la generación de ideas.
• Desventajas: Puede generar muchas ideas no estructuradas y requiere filtrarlas y organizarlas posteriormente.

Prototipos:

• Descripción: Creación de modelos preliminares del sistema para visualizar y evaluar los requisitos.
• Ventajas: Ayuda a las partes interesadas a visualizar el sistema y proporciona feedback temprano.
• Desventajas: Puede ser costoso y requerir mucho tiempo, y los prototipos pueden ser malinterpretados como productos finales.

 

12. En qué consiste la técnica heurística? 

 La técnica heurística consiste en utilizar métodos prácticos y no garantizados para encontrar soluciones a problemas de manera eficiente. Estas técnicas se basan en la experiencia y el juicio intuitivo para llegar a una solución que, aunque no siempre óptima o perfecta, es suficiente para alcanzar el objetivo de manera razonable en un tiempo y con un esfuerzo aceptable.

 

13. ¿Qué pasa si un requerimiento es ambiguo? 

 

Malentendidos y Confusión:

• Descripción: Las diferentes partes interesadas pueden interpretar el mismo requerimiento de maneras distintas.
• Ejemplo: Si un requerimiento dice "El sistema debe ser rápido", una parte interesada podría interpretarlo como tiempo de respuesta menor a un segundo, mientras que otra podría pensar que es menos de cinco segundos.

Implementación Incorrecta:

• Descripción: Los desarrolladores pueden implementar el sistema de manera que no cumpla con las expectativas reales del cliente.
• Ejemplo: Un requerimiento ambiguo podría llevar a los desarrolladores a crear una funcionalidad que no resuelve el problema del usuario final o no aporta el valor esperado.

Retrasos en el Proyecto:

• Descripción: Se requiere tiempo adicional para aclarar y resolver las ambigüedades, lo que puede retrasar el cronograma del proyecto.
• Ejemplo: Reuniones adicionales para discutir y clarificar los requerimientos ambiguos pueden consumir tiempo valioso que podría haberse utilizado para avanzar en el desarrollo.

Costos Adicionales:

• Descripción: La necesidad de retrabajar partes del sistema debido a malentendidos puede incrementar los costos del proyecto.
• Ejemplo: Reescribir y retestar componentes del sistema para corregir las implementaciones incorrectas originadas por ambigüedades en los requerimientos.

Calidad Inferior del Producto:

• Descripción: Un sistema basado en requerimientos ambiguos puede no cumplir con las necesidades y expectativas del usuario final, resultando en un producto de menor calidad.
• Ejemplo: Un sistema que no cumple adecuadamente con las especificaciones debido a la ambigüedad puede tener problemas de usabilidad, funcionalidad y rendimiento.

 

 

14. Seleccione las herramientas para analizar los procesos a mejorar:

 

Diagramas de Flujo (Flowcharts):

• Descripción: Representación gráfica de los pasos secuenciales de un proceso, mostrando las actividades, decisiones y relaciones entre ellas.
• Uso: Identificar cuellos de botella, redundancias, y áreas de mejora en la secuencia operativa del proceso.

Diagramas de Ishikawa (Espina de Pescado o Diagrama de Causa y Efecto):

• Descripción: Herramienta que visualiza las posibles causas de un problema, organizando las causas en categorías como personal, métodos, máquinas, materiales, etc.
• Uso: Identificar las causas raíz de los problemas o ineficiencias en un proceso para abordarlos de manera efectiva.

Diagramas de Pareto:

• Descripción: Gráfico de barras que ordena problemas o causas de acuerdo a su frecuencia de ocurrencia, enfatizando las causas más significativas (principio del 80/20).
• Uso: Priorizar áreas de mejora según su impacto en el proceso y enfocar los esfuerzos de mejora en las causas más importantes.

Análisis FODA (SWOT Analysis):

• Descripción: Método que evalúa las Fortalezas, Oportunidades, Debilidades y Amenazas relacionadas con un proceso o situación.
• Uso: Identificar áreas de mejora internas (fortalezas y debilidades) y externas (oportunidades y amenazas) que pueden influir en el proceso.

Análisis de Valor Agregado (Value Stream Mapping):

• Descripción: Técnica para visualizar y analizar el flujo de valor a lo largo de un proceso, desde el inicio hasta el final, identificando actividades que agregan valor y las que no.
• Uso: Identificar y eliminar desperdicios (actividades que no agregan valor) para mejorar la eficiencia y calidad del proceso.

Benchmarking:

• Descripción: Comparación sistemática de procesos, productos o servicios con los líderes de la industria o con competidores directos para identificar las mejores prácticas.
• Uso: Identificar oportunidades de mejora al adoptar métodos y prácticas exitosas de otras organizaciones.

Análisis de Riesgos (Risk Analysis):

• Descripción: Evaluación de posibles eventos que puedan afectar negativamente el proceso y su impacto potencial.
• Uso: Identificar y mitigar riesgos que podrían obstaculizar la mejora del proceso o la implementación de cambios.

Diagramas de Gantt:

• Descripción: Representación visual del cronograma del proyecto, mostrando las fechas de inicio y finalización de las diferentes etapas y actividades.
• Uso: Planificar y gestionar el tiempo y los recursos necesarios para implementar mejoras en el proceso de manera eficiente.

Mapas Mentales (Mind Maps):

• Descripción: Diagrama que representa ideas y conceptos de manera gráfica, utilizando ramificaciones desde un concepto central.
• Uso: Explorar y organizar ideas para identificar áreas clave de mejora en un proceso de manera visual y estructurada.

15. Cómo se le llama a los interesados en el proyecto? 

 A los interesados en el proyecto se les llama "partes interesadas" o "stakeholders" en inglés. Este término se refiere a cualquier persona, grupo u organización que pueda afectar o ser afectado por las actividades del proyecto, sus resultados o sus decisiones.

 

 

16. ¿Al aplicar la técnica de la observación se puede interactuar con la persona a la que se observa? 

 

Sí, al aplicar la técnica de observación en el contexto del análisis de requisitos o de cualquier otro estudio, es posible interactuar con la persona que está siendo observada. Esta interacción puede variar según el propósito y el enfoque de la observación:

1. Observación Pasiva: En algunos casos, la observación puede realizarse de manera pasiva, donde el observador no interactúa directamente con la persona observada. Esto se hace para capturar el comportamiento natural y sin interferencias del individuo en su entorno habitual.

2. Observación Activa: En otros casos, puede ser necesario o beneficioso interactuar con la persona observada. Esto puede incluir hacer preguntas para aclarar lo que está sucediendo, entender el contexto de ciertas acciones o solicitar explicaciones sobre ciertos procedimientos o decisiones.

 

17. Las acciones que surgen de los requisitos funcionales, se realizan en:

 Las acciones que surgen de los requisitos funcionales se realizan típicamente en el contexto del desarrollo de software o de sistemas. Cuando se identifican y especifican los requisitos funcionales de un sistema, estos describen las funciones o las acciones específicas que el sistema debe ser capaz de realizar para satisfacer las necesidades de los usuarios finales o las partes interesadas.

 

 

18. ¿En qué consiste la técnica del focus group? 

 La técnica del focus group o grupo focal es una metodología cualitativa de investigación que se utiliza para recopilar datos sobre las actitudes, opiniones, percepciones y experiencias de un grupo específico de personas acerca de un tema particular. Esta técnica se basa en la interacción grupal dirigida por un moderador, con el propósito de obtener información detallada y perspectivas diversas sobre un tema de interés.

 

 

19. ¿Para qué sirve el análisis de requisitos de software?

 El análisis de requisitos de software es un proceso fundamental en el desarrollo de sistemas y aplicaciones informáticas. Su propósito principal es capturar, definir y documentar las necesidades y expectativas de los usuarios, clientes y otras partes interesadas respecto a lo que el software debe hacer y cómo debe comportarse.

 

 

20. Qué es un requerimiento consistente?     

      Un requerimiento consistente en el contexto de la ingeniería de requisitos y el desarrollo de software se refiere a una característica fundamental de los requisitos que implica coherencia y ausencia de contradicciones internas. En otras palabras, un requerimiento consistente es aquel que es claro, preciso y no presenta ambigüedades ni conflictos con otros requisitos o con el propósito general del sistema o producto de software.