Taller: Analisis de requisitos de software: Fundamentos y
Aplicaciones
Integrantes: Daniel Martínez Noriega, Diego Alexander Chavarro Sons, Laura Camila
Almendra.
• ¿Mencione los metodologías de desarrollo ágil más representativas y cuál de ellas
le intereso más y porque?
Las metodologías ágiles más representativas son Scrum, Kanban, Extreme Programming
(XP), Lean Development y Crystal. Cada una tiene su forma de organizar el trabajo, pero
todas tienen el mismo objetivo (hacer los software más rápido y mejor hechos). Nos llamo
la atención Scrum porque organiza el trabajo en pasos pequeños (sprints) y ayuda a que el
equipo siempre sepa qué está haciendo, y también porque es una de las mas utilizadas.
• ¿Qué es un requisito de software?
Requisito de software es fundamentalmente una guía para entender las necesidades de
los usuarios y, a partir de esa comprensión, especificar las funciones que un producto de
software debe tener
• ¿Para qué sirve el análisis de requisitos de software?
El análisis de requisitos de software sirve para saber exactamente qué necesita el usuario
y cómo debe funcionar el software antes de empezar a hacerlo. Ayuda a evitar errores,
organizar mejor el trabajo y asegurarse de que el resultado final sea lo que realmente se
espera. Para esto hay unos pasos: licitación, análisis, especificación y validación.
• ¿Qué tan importante es el análisis de requerimientos dentro del ciclo de vida de la
ingeniería de software?
el análisis de requerimientos es muy importante dentro de la creación del software
porque nos ayuda a entender bien desde el principio qué es lo que los usuarios realmente
necesitan. Esto es clave para no construir algo que no sirva y para asegurarnos de que el
software final sí solucione sus problemas.
• ¿Cuáles son las ventajas y desventajas de realizar correctamente el análisis de los
requisitos del software?
Ventajas de hacer bien el análisis de requisitos:
Hacemos el software correcto: Entendemos bien qué necesita la gente, así el programa sí
les sirve.
Evitamos errores caros: Pensar bien al principio evita tener que arreglar cosas grandes
después.
Ahorramos tiempo y esfuerzo: No construimos cosas que no se necesitan.
El software es mejor: Funciona bien y la gente está contenta con él.
Desventajas de no hacer bien el análisis de requisitos:
Hacemos un software que no sirve: No cumple con lo que la gente necesitaba.
Gastamos más plata y tiempo: Tenemos que arreglar errores grandes después.
La gente no está contenta: El software no soluciona sus problemas.
Podemos perder el proyecto: Si el software es un desastre, nadie lo querrá.
Si hablamos de las desventajas de hacer de realizar eso correctamente, no hay
desventajas.
• Mencione y describa la clasificación de los requisitos...
Requisitos Funcionales: Estos son los que dicen qué va a hacer el software. Son las
funciones específicas, las tareas que el programa debe poder realizar. Es como decir: "El
programa tiene que dejarme guardar archivos", "Debe calcular el total de la compra",
"Tiene que mostrarme una lista de productos". Son las cosas concretas que el software
puede hacer.
Requisitos No Funcionales: Estos hablan de cómo debe ser el software, no de lo que hace.
Son las cualidades que tiene que tener el programa, como por ejemplo:
Qué tan rápido tiene que ser: "La búsqueda de productos debe tardar menos de un
segundo." (Rendimiento)
Qué tan seguro debe ser: "Solo los usuarios con contraseña pueden entrar a su cuenta."
(Seguridad)
Qué tan fácil de usar tiene que ser: "Los botones deben ser grandes y fáciles de entender."
(Usabilidad)
Qué tan confiable tiene que ser: "El programa debe funcionar sin errores la mayor parte
del tiempo." (Confiabilidad)
• Defina las etapas de la ingeniería de requisitos…
Elicitación: Es donde se descubren y se recopilan las necesidades de los usuarios y otras
personas interesadas en el software. Es el momento de hablar con ellos, observar cómo
trabajan y entender qué problemas necesitan resolver con el software.
Análisis: Una vez que tenemos una lista de necesidades, en esta etapa las entendemos a
fondo. Buscamos si hay cosas que no cuadran, si faltan detalles y tratamos de organizar la
información para tener una idea clara de lo que se necesita construir.
Especificación: Aquí es donde ponemos por escrito, de forma clara y detallada, todo lo
que se ha entendido en las etapas anteriores. Creamos un documento que describe los
requisitos del software para que todos los que trabajen en el proyecto sepan exactamente
qué construir.
Validación: En esta última etapa, verificamos que los requisitos que hemos especificado
son correctos y que realmente cumplen con las necesidades de los usuarios. Nos
aseguramos de que lo que vamos a construir es lo que realmente se necesita.
