PROGRAMACION DE SOFTWARE

 

1. Es una descripción sobre algo que el sistema debería ejecutar. Es decir, que sin ese requisito, el sistema no puede cumplir su tarea.

2. Un requisito funcional es una descripción de lo que un sistema debe hacer, como funciones específicas, tareas o comportamientos. Por otro lado, un requisito no funcional se refiere a las restricciones, calidad o características del sistema, como la seguridad, el rendimiento o la usabilidad. 

3. Claridad y precisión: Los requisitos deben ser claros, específicos y no ambiguos pa1. Involucración de los interesados: Es fundamental involucrar a todas las partes interesadas, como usuarios finales, clientes y equipos internos, para comprender plenamente sus necesidades y expectativas. Para evitar malentendidos durante el desarrollo del sistema o producto. 3. Viabilidad técnica: Es importante evaluar la viabilidad técnica de los requisitos para asegurarse de que puedan implementarse dentro de los límites tecnológicos y recursos disponibles. 4. Impacto en el negocio: Los requisitos deben alinearse con los objetivos y estrategias comerciales para garantizar que el sistema o producto contribuya al éxito general del negocio. 5. Cumplimiento normativo: En ciertos casos, es crucial considerar requisitos legales, regulatorios o de cumplimiento que deben ser incorporados en el sistema o producto.

4. Los requisitos deben ser claros, específicos, medibles, consistentes y completos. Deben describir de manera detallada qué es lo que se espe”a que el sistema o producto haga, sin dejar lugar a interpretaciones ambiguas. Además, es importante que los requisitos sean verificables, es decir, que sea posible comprobar si se han cumplido o no. Esto facilita el proceso de desarrollo y asegura que las expectativas de los interesados se cumplan de manera efectiva. La documentación de requisitos debe ser organizada y estar disponible para todas las partes involucradas en el proyecto.

5. Los requisitos deben indicar claramente qué funcionalidades, características o restricciones debe tener el sistema o producto. Deben responder a preguntas como: ¿Qué debe hacer el sistema? ¿Cómo debe comportarse en ciertas situaciones? ¿Qué limitaciones o restricciones debe respetar? Los requisitos también deben especificar quién es el responsable de su cumplimiento y cuál es el criterio de aceptación para cada uno. En resumen, los requisitos deben proporcionar una guía detallada sobre lo que se espera lograr con el sistema o producto y cómo debe comportarse en diferentes escenarios.

6. Algunas de las formas comunes de obtener requisitos incluyen: 1. Entrevistas con los interesados: Hablar directamente con usuarios finales, clientes y otros interesados clave para comprender sus necesidades y expectativas. 2. Observación: Observar cómo los usuarios interactúan con sistemas existentes o realizan sus tareas diarias para identificar oportunidades de mejora. 3. Cuestionarios: Utilizar cuestionarios estructurados para recopilar información específica sobre las necesidades y preferencias de los usuarios. 4. Grupos focales: Reunir a un grupo de usuarios para discutir y compartir sus experiencias, opiniones y requerimientos sobre el sistema o producto. 5. Prototipado: Crear prototipos o maquetas del sistema para que los usuarios puedan interactuar con ellos y proporcionar retroalimentación directa.

7. Al obtener requisitos, es común enfrentarse a una serie de desafíos y problemas que pueden dificultar el proceso. Algunos de estos problemas incluyen: 1) Falta de claridad: Los interesados a veces tienen dificultades para expresar claramente sus necesidades, lo que puede llevar a requisitos ambiguos o contradictorios. 2)Cambios constantes: Los requisitos pueden cambiar a medida que avanza el proyecto, lo que puede dificultar la estabilización de los mismos. 3)Diferentes opiniones: Los diferentes interesados pueden tener visiones y prioridades divergentes, lo que puede generar conflictos y dificultar la definición de requisitos consensuados. 4)Falta de participación: Si no se logra la participación activa de todos los interesados, es posible que se pasen por alto aspectos importantes o que los requisitos no reflejen las necesidades reales. 5) Requisitos incompletos: A veces, los interesados pueden no estar al tanto de todas las funcionalidades o restricciones necesarias, lo que podría resultar en requisitos incompletos.