Ing. Requisitos Actividad Juan David Ramirez
Ing. Requisitos Actividad Juan David Ramirez
Ing. Requisitos Actividad Juan David Ramirez
Docente
Ingeniería de requisitos
Universidad De La Amazonia
Florencia- Caquetá
2023
Contenido
1. ¿Qué es la elicitación de requisitos/requerimiento?....................................................................3
2. Actividades principales de la elicitación de requisitos...............................................................3
3. ¿Cuáles son las técnicas o herramientas para la elicitación de requisitos?..................................4
4. ¿Qué son los requisitos de la solución y los requisitos de la transición?....................................5
5. ¿Qué son los requisitos funcionales y los no funcionales? y sus características.........................6
6. ¿Cuál es la manera correcta de escribir requisitos?....................................................................7
Referencias.........................................................................................................................................8
1. ¿Qué es la elicitación de requisitos/requerimiento?
Las actividades principales de la elicitación de requisitos son variadas y pueden variar según el
proceso de desarrollo de software y la metodología utilizada. Sin embargo, el Instituto de Ingeniería
Eléctrica y Electrónica (IEEE) ha definido un conjunto de actividades básicas para el proceso de
elicitación de requisitos en su estándar 830-1998:
Entrevistas: Una de las técnicas más comunes para la elicitación de requisitos es la entrevista con
los interesados en el sistema. Esto puede ser realizado individualmente o en grupo, y puede ser
estructurado o no estructurado.
Cuestionarios: Los cuestionarios son herramientas que se utilizan para recopilar información de los
interesados en el sistema, a menudo a través de preguntas abiertas o cerradas.
Observación: La observación se utiliza para obtener información sobre el uso actual del sistema o
para identificar problemas y oportunidades de mejora.
Prototipado: Los prototipos son modelos del sistema que se utilizan para obtener comentarios de los
interesados y para validar requisitos.
Brainstorming: El brainstorming es una técnica que se utiliza para generar ideas y soluciones
creativas en un grupo de discusión.
Análisis de casos de uso: El análisis de casos de uso se utiliza para identificar las funciones y el
comportamiento del sistema a través de la identificación de los casos de uso.
Talleres: Los talleres son sesiones de trabajo en grupo en las que se discuten y se definen los
requisitos del sistema.
En resumen, existen numerosas técnicas y herramientas para la elicitación de requisitos, y la
elección de la técnica adecuada dependerá del contexto y de las necesidades específicas del
proyecto en cuestión.
Los requisitos de la solución y los requisitos de la transición son dos tipos de requisitos que se
deben tener en cuenta durante el proceso de desarrollo de software. El Instituto de Ingeniería
Eléctrica y Electrónica (IEEE) los define de la siguiente manera en su estándar 12207-2008:
Los requisitos de la solución son "los requisitos que describen las características del sistema o de la
solución propuesta que cumplirán las necesidades y expectativas del usuario" (IEEE 12207-2008).
Esto incluye requisitos funcionales y no funcionales, así como requisitos de calidad y de
rendimiento.
Los requisitos de la transición son "los requisitos que describen las actividades necesarias para
implementar el sistema en su entorno de operación, y para transferir el conocimiento y la
responsabilidad de la operación del sistema a los usuarios y operadores" (IEEE 12207-2008). Esto
puede incluir requisitos relacionados con la instalación, la configuración, la capacitación y la
documentación.
Los requisitos funcionales y los no funcionales son dos tipos de requisitos que se deben tener en
cuenta durante el proceso de desarrollo de software. A continuación, se describen sus características
principales:
Los requisitos funcionales son "los requisitos que especifican una función que el sistema o solución
propuesta debe ser capaz de realizar" (IEEE 830-1998). Estos requisitos describen las
funcionalidades del sistema, lo que éste debe hacer, cómo debe hacerlo y en qué condiciones. Por lo
general, se expresan en términos de entradas, salidas y comportamiento del sistema.
Características de los requisitos funcionales:
Son verificables.
Los requisitos no funcionales son "los requisitos que especifican criterios que pueden ser usados
para juzgar la operación del sistema o solución propuesta, en lugar de las especificaciones de
comportamiento" (IEEE 830-1998). Estos requisitos describen las características que el sistema
debe tener en términos de calidad, rendimiento, seguridad, usabilidad, etc.
La manera correcta de escribir requisitos es fundamental para asegurar que sean claros, precisos,
consistentes, verificables y comprensibles por todas las partes interesadas. A continuación, se
presentan algunas recomendaciones para escribir requisitos, según el estándar IEEE 830-1998:
Utilizar un lenguaje claro y preciso: los requisitos deben ser escritos en un lenguaje claro, conciso y
preciso, evitando ambigüedades y redundancias.
Especificar el nivel de detalle: los requisitos deben ser escritos en un nivel de detalle suficiente para
ser comprendidos y verificados, pero sin excesivo detalle que dificulte su comprensión.
Utilizar un formato estandarizado: los requisitos deben seguir un formato estandarizado, que
incluya un identificador único, una descripción clara del requisito, su justificación y cualquier otra
información relevante.
Evitar requisitos implícitos: todos los requisitos deben ser explícitos y no se deben dejar requisitos
implícitos.
Utilizar términos comunes: los términos utilizados en los requisitos deben ser comunes y entendidos
por todas las partes interesadas.
Ser coherente y consistente: los requisitos deben ser coherentes y consistentes con otros requisitos y
con los objetivos del proyecto.
Verificar y validar los requisitos: los requisitos deben ser verificados y validados para asegurarse de
que cumplen con los objetivos del proyecto y son comprensibles y verificables.
En resumen, la escritura de requisitos debe ser clara, precisa, consistente y verificable, utilizando un
formato estandarizado y un lenguaje común y evitando requisitos implícitos.
Referencias
IEEE. (2008). IEEE Std 12207-2008, Standard for Systems and Software Engineering - Software
Life Cycle Processes.
IEEE. (1998). IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications.
IEEE. (2008). IEEE Std 12207-2008, Standard for Systems and Software Engineering - Software
Life Cycle Processes.
IEEE. (1998). IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications.
IEEE. (1998). IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements
Specifications.