QUESTIONAMIENTO REQUISITOS SOFTWFARE

1-¿Qué de describe un requisito?

Un requisito es una declaración clara y específica que describe una característica, funcionalidad o restricción que debe cumplir un sistema, producto o servicio. Aquí tienes un ejemplo de un requisito:

Nombre del Requisito: Autenticación de Usuario

Descripción: El sistema debe permitir a los usuarios autenticarse utilizando un nombre de usuario y una contraseña válidos.

Justificación: La autenticación de usuarios es esencial para garantizar la seguridad y la privacidad de la información almacenada en el sistema. Solo los usuarios autorizados deben poder acceder a las funcionalidades y los datos protegidos.

Criterios de Aceptación:

• El sistema debe proporcionar un formulario de inicio de sesión donde los usuarios puedan ingresar su nombre de usuario y contraseña.

• El sistema debe verificar las credenciales del usuario y permitir el acceso solo a aquellos que ingresen credenciales válidas.

• El sistema debe bloquear el acceso después de un número determinado de intentos fallidos de inicio de sesión para proteger contra ataques de fuerza bruta.

• El sistema debe proporcionar opciones para restablecer la contraseña en caso de olvido o pérdida.

Este requisito define una funcionalidad específica que el sistema debe tener (autenticación de usuario) y proporciona detalles sobre cómo debe funcionar esta funcionalidad, así como la justificación detrás de ella y los criterios que se utilizarán para verificar si se cumple adecuadamente.

2-¿Que es es un requisito funcional y no funcional?

2-Que es un requisito funcional y no funcional?

Los requisitos funcionales y no funcionales son dos categorías principales de requisitos que se utilizan para describir diferentes aspectos de un sistema, producto o servicio:

1. Requisitos Funcionales:

   • Los requisitos funcionales describen las funciones y las operaciones específicas que el sistema debe realizar.
   • Estos requisitos se centran en lo que el sistema debe hacer y cómo debe comportarse en términos de funcionalidad.
   • Suelen ser verbos o frases que indican acciones que el sistema debe permitir a los usuarios realizar.
   • Ejemplos de requisitos funcionales incluyen "El sistema debe permitir a los usuarios iniciar sesión", "El sistema debe permitir a los usuarios realizar búsquedas de productos" y "El sistema debe generar un informe mensual de ventas".

2. Requisitos No Funcionales:

   • Los requisitos no funcionales describen atributos de calidad del sistema, en lugar de funciones específicas.
   • Estos requisitos se centran en cómo debe ser el sistema en términos de características como el rendimiento, la seguridad, la usabilidad y la escalabilidad.
   • Suelen ser adjetivos o adverbios que indican cualidades o restricciones del sistema.
   • Ejemplos de requisitos no funcionales incluyen "El sistema debe ser capaz de manejar hasta 1000 usuarios concurrentes", "El sistema debe cumplir con los estándares de seguridad ISO 27001" y "El sistema debe tener un tiempo de respuesta promedio de menos de 2 segundos".

En resumen, los requisitos funcionales se centran en lo que el sistema debe hacer, mientras que los requisitos no funcionales se centran en cómo debe ser el sistema en términos de calidad y rendimiento. Ambos tipos de requisitos son igualmente importantes para definir y diseñar un sistema que cumpla con las necesidades y expectativas de los usuarios y otras partes interesadas.

3-¿Qué factores se deben tener en cuenta, en el momento de obtener requisitos?

Al obtener requisitos, hay varios factores clave a tener en cuenta para garantizar que el proceso sea efectivo y que se capturen de manera precisa las necesidades y expectativas de los interesados. Algunos de estos factores incluyen:

1. Claridad en los objetivos del proyecto: Es fundamental comprender completamente los objetivos y metas del proyecto para asegurarse de que los requisitos recopilados estén alineados con estos.

2. Identificación de interesados: Es importante identificar y consultar a todas las partes interesadas relevantes, incluidos los usuarios finales, los clientes, los patrocinadores del proyecto y otros grupos afectados.

3. Comunicación efectiva: Se debe establecer una comunicación clara y abierta con todas las partes interesadas para comprender sus necesidades y expectativas, así como para explicar el proceso de recopilación de requisitos y cómo se utilizarán los requisitos recopilados.

4. Priorización de requisitos: No todos los requisitos son iguales. Es importante priorizarlos según su importancia y su impacto en el proyecto y en los objetivos del cliente.

5. Validación de requisitos: Los requisitos deben ser validados por las partes interesadas para garantizar su precisión y completitud. Esto puede implicar revisión y aprobación formal.

6. Flexibilidad: Los requisitos pueden cambiar a lo largo del tiempo debido a cambios en el entorno empresarial, nuevas tecnologías o cambios en las necesidades de los usuarios. Por lo tanto, se debe tener en cuenta la necesidad de flexibilidad y adaptabilidad en el proceso de obtención de requisitos.

7. Documentación adecuada: Es importante documentar claramente todos los requisitos recopilados, junto con cualquier contexto o justificación relevante. Esto ayuda a garantizar que todos los interesados tengan una comprensión común de lo que se espera del proyecto.

8. Gestión del cambio: Se debe tener en cuenta la gestión del cambio desde el principio, ya que es probable que surjan cambios en los requisitos a lo largo del ciclo de vida del proyecto. Es importante tener un proceso claro para gestionar y aprobar estos cambios.

Al prestar atención a estos factores durante el proceso de obtención de requisitos, se puede aumentar la probabilidad de éxito del proyecto al garantizar que se satisfagan las necesidades y expectativas de las partes interesadas.

4-¿Cómo deben ser los requisitos?

Los requisitos deben ser claros, completos, consistentes, verificables y relevantes para el proyecto. Aquí hay una descripción más detallada de cómo deben ser los requisitos:

1. Claros: Los requisitos deben ser fáciles de entender para todas las partes interesadas. Deben ser expresados de manera clara y sin ambigüedades para evitar malentendidos.

2. Completos: Los requisitos deben capturar todas las necesidades y expectativas de las partes interesadas relevantes para el proyecto. No deben omitirse aspectos importantes que puedan afectar el éxito del proyecto.

3. Consistentes: Los requisitos deben ser coherentes entre sí y no deben entrar en conflicto. Deben estar alineados con los objetivos y restricciones del proyecto, así como con otros requisitos ya definidos.

4. Verificables: Los requisitos deben ser verificables, lo que significa que debe ser posible determinar si se han cumplido o no. Deben poder ser evaluados de manera objetiva para confirmar que se han satisfecho.

5. Relevantes: Los requisitos deben ser relevantes para el proyecto y contribuir al logro de sus objetivos. No deben incluirse requisitos que no aporten valor al proyecto o que estén fuera de su alcance.

6. Modificables: Los requisitos deben poder modificarse si es necesario para adaptarse a cambios en el entorno empresarial, en las necesidades de los usuarios o en otras circunstancias relevantes. Deben ser lo suficientemente flexibles como para permitir ajustes según sea necesario a lo largo del ciclo de vida del proyecto.

7. Rastreables: Deben poder rastrearse hasta su origen, es decir, hasta las necesidades o expectativas específicas de las partes interesadas que los generaron. Esto facilita la gestión de cambios y la resolución de problemas.

8. Priorizados: Es útil priorizar los requisitos según su importancia y su impacto en el proyecto y en los objetivos del cliente. Esto ayuda a enfocar los esfuerzos en los requisitos más críticos y a tomar decisiones informadas sobre el alcance del proyecto.

Al cumplir con estos criterios, los requisitos pueden servir como una base sólida para el diseño, desarrollo y evaluación exitosos de un proyecto.

5-¿Qué deben indicar los requisitos?

Los requisitos deben indicar de manera clara y específica qué se espera lograr o qué características debe tener el sistema, producto o servicio que se está desarrollando. Aquí hay algunos aspectos clave que los requisitos deben indicar:

1. Funcionalidad: Los requisitos deben describir las funciones o capacidades que el sistema debe tener. Esto incluye las tareas que el sistema debe realizar, los procesos que debe admitir y las operaciones que debe permitir a los usuarios realizar.

2. Rendimiento: Los requisitos deben especificar los criterios de rendimiento que el sistema debe cumplir. Esto puede incluir tiempos de respuesta, capacidad de procesamiento, capacidad de almacenamiento y cualquier otro aspecto relacionado con el rendimiento del sistema.

3. Fiabilidad: Los requisitos deben indicar los niveles de fiabilidad y disponibilidad que se esperan del sistema. Esto puede incluir la frecuencia y la gravedad de las fallas aceptables, así como los mecanismos de recuperación y respaldo que deben estar en su lugar.

4. Usabilidad: Los requisitos deben describir los criterios de usabilidad que el sistema debe cumplir. Esto puede incluir aspectos como la facilidad de aprendizaje, la eficiencia de uso, la satisfacción del usuario y la accesibilidad para usuarios con necesidades especiales.

5. Seguridad: Los requisitos deben especificar los controles de seguridad que deben implementarse en el sistema para proteger la información y prevenir accesos no autorizados. Esto puede incluir autenticación de usuarios, control de acceso, cifrado de datos y auditoría de seguridad.

6. Compatibilidad: Los requisitos deben indicar los estándares y protocolos que el sistema debe cumplir para garantizar su compatibilidad con otros sistemas y tecnologías existentes en el entorno empresarial.

7. Mantenimiento y soporte: Los requisitos deben especificar los criterios de mantenimiento y soporte que el sistema debe cumplir. Esto puede incluir la capacidad de actualización, la disponibilidad de documentación técnica y el acceso a servicios de soporte técnico.

8. Restricciones: Los requisitos deben identificar cualquier restricción o limitación que pueda afectar el diseño o la implementación del sistema. Esto puede incluir restricciones de presupuesto, plazos de entrega, requisitos de hardware o software, y consideraciones legales o regulatorias.

Al indicar estos aspectos en los requisitos, se proporciona una guía clara para el diseño, desarrollo y evaluación del sistema, asegurando que cumpla con las necesidades. 

6-¿Cómo se obtienen los requisitos?

Obtener requisitos es un proceso clave en el desarrollo de sistemas, productos o servicios, y generalmente implica varias etapas y técnicas. Aquí hay algunos métodos comunes para obtener requisitos:

1. Entrevistas: Realizar entrevistas con diferentes partes interesadas, incluidos usuarios finales, clientes, gerentes de proyecto y otros  relevantes. Las entrevistas permiten obtener información directa sobre las necesidades, expectativas y requisitos del sistema.

2. Grupos de enfoque: Organizar sesiones de grupo con representantes de diferentes partes interesadas para discutir y recopilar requisitos. Los grupos de enfoque pueden facilitar la identificación de diferentes perspectivas y la generación de ideas sobre las características y funcionalidades deseadas.

3. Observación directa: Observar a los usuarios mientras realizan sus tareas diarias puede proporcionar información valiosa sobre cómo interactúan con el sistema existente (si lo hay) y qué mejoras podrían ser necesarias.

4. Encuestas: Distribuir encuestas a una amplia audiencia de usuarios potenciales para recopilar información sobre sus necesidades, preferencias y expectativas. Las encuestas pueden ser útiles para obtener datos cuantitativos sobre las características y funcionalidades más importantes.

5. Prototipado: Desarrollar prototipos rápidos o maquetas del sistema para permitir que los usuarios experimenten y proporcionen retroalimentación sobre las características y funcionalidades propuestas. Esto puede ayudar a refinar y validar los requisitos antes de comenzar el desarrollo completo del sistema.

6. Análisis de documentos: Revisar documentos existentes, como especificaciones técnicas, informes de mercado, documentos de requisitos previos y otros artefactos relacionados con el proyecto para identificar requisitos implícitos o explícitos.

7. Reuniones de trabajo colaborativo: Organizar talleres o sesiones de trabajo colaborativo con diferentes partes interesadas para discutir y elaborar requisitos de manera conjunta. Esto puede fomentar la colaboración y el consenso.

8. Benchmarking: Investigar y comparar sistemas similares en el mercado para identificar características y funcionalidades que podrían ser relevantes para el sistema en desarrollo.

Al combinar diferentes métodos y técnicas de obtención de requisitos, se puede obtener una comprensión completa y precisa de las necesidades y expectativas de los usuarios y otras partes interesadas, lo que puede sentar las bases para el diseño y desarrollo exitosos del sistema.

  

7-¿Qué problemas pueden presentarse al obtener requisitos? 

Al obtener requisitos, es común enfrentarse a una serie de desafíos y problemas que pueden dificultar el proceso y afectar la calidad de los requisitos recopilados. Algunos de estos problemas incluyen:

1. Malentendidos y comunicación deficiente: La falta de comunicación clara entre los interesados puede llevar a malentendidos sobre las necesidades y expectativas del sistema. Esto puede resultar en requisitos ambiguos o mal interpretados.

2. Expectativas poco realistas: Los usuarios y otras partes interesadas pueden tener expectativas poco realistas sobre lo que el sistema puede lograr o el tiempo y recursos necesarios para desarrollarlo. Esto puede conducir a requisitos poco prácticos o poco viables.

3. Falta de participación de los interesados: Si no se involucra adecuadamente a todas las partes interesadas relevantes en el proceso de obtención de requisitos, es posible que se pierda información importante o se pasen por alto perspectivas clave.

4. Requisitos incompletos o inconsistentes: Puede ser difícil capturar todas las necesidades y expectativas de los usuarios en un primer intento, lo que puede resultar en requisitos incompletos o inconsistentes entre sí.

5. Cambios en los requisitos: A medida que avanza el proyecto, es posible que los requisitos cambien debido a cambios en las necesidades del negocio, nuevas tecnologías o la evolución de las expectativas de los usuarios. Gestionar estos cambios de manera efectiva puede ser un desafío.

6. Conflictos de intereses: Los diferentes grupos de interesados pueden tener objetivos y prioridades conflictivos, lo que puede dificultar la identificación y el consenso sobre los requisitos.

7. Falta de experiencia en el dominio: Si los analistas de requisitos no tienen experiencia en el dominio del problema o industria en la que están trabajando, puede ser difícil comprender completamente las necesidades y requerimientos del sistema.

8. Sesgos y presuposiciones: Los analistas de requisitos pueden tener sesgos o presuposiciones que influyan en la forma en que recopilan y documentan los requisitos, lo que puede llevar a una representación incompleta o distorsionada de las necesidades de los usuarios.

Abordar estos problemas requiere un enfoque cuidadoso y sistemático para la obtención de requisitos, que incluya la comunicación efectiva con las partes interesadas, la validación y verificación de los requisitos, y la gestión proactiva de cambios y conflictos.