Ing. Requisitos Actividad Juan David Ramirez

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 8

Actividades complementarias

Docente

Lina Saza Bustos

Ingeniería de requisitos

Juan David Ramirez Alvarez

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?

La elicitación de requisitos es el proceso de comprensión y descubrimiento de las necesidades,


expectativas, restricciones y deseos de los interesados en un sistema o aplicación. Según el Instituto
de Ingeniería Eléctrica y Electrónica (IEEE), la elicitación de requisitos se define como "el proceso
de descubrimiento, análisis, negociación, especificación y validación de los requisitos del sistema"
(IEEE 12207-2008).
La elicitación de requisitos es un paso crucial en el desarrollo de sistemas, ya que establece las
bases para el diseño y la implementación. Un proceso de elicitación de requisitos efectivo implica la
colaboración activa entre los interesados y los desarrolladores del sistema, lo que ayuda a garantizar
que el sistema final cumpla con las necesidades y expectativas de los usuarios.
En resumen, la elicitación de requisitos es un proceso iterativo y colaborativo que se centra en la
comprensión y la identificación de las necesidades de los interesados en un sistema o aplicación, y
es esencial para el éxito del desarrollo de cualquier proyecto de software.

2. Actividades principales de la elicitación de requisitos

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:

Identificar a los interesados relevantes del sistema.


Obtener información sobre el contexto y los objetivos del sistema.
Identificar y analizar las necesidades y expectativas de los interesados.
Identificar y analizar los requisitos funcionales y no funcionales del sistema.
Establecer prioridades entre los requisitos identificados.
Verificar y validar los requisitos identificados.
Estas actividades suelen realizarse en un proceso iterativo y colaborativo que involucra a los
interesados y al equipo de desarrollo del sistema. Además, la documentación de los requisitos se
realiza de acuerdo con los estándares y formatos establecidos en el proceso de desarrollo de
software.
En resumen, las actividades principales de la elicitación de requisitos incluyen la identificación de
interesados, la obtención de información, el análisis de necesidades y expectativas, la identificación
de requisitos funcionales y no funcionales, la priorización de requisitos y la verificación y
validación de requisitos.
3. ¿Cuáles son las técnicas o herramientas para la elicitación de requisitos?

Existen numerosas técnicas y herramientas para la elicitación de requisitos, y la elección de la


técnica o herramienta adecuada depende del contexto y de las características del proyecto en
cuestión. Algunas de las técnicas y herramientas más comunes son las siguientes:

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.

4. ¿Qué son los requisitos de la solución y los requisitos de la transició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.

En resumen, los requisitos de la solución describen las características y funcionalidades que el


sistema debe tener para satisfacer las necesidades y expectativas del usuario, mientras que los
requisitos de la transición describen las actividades necesarias para implementar y operar el sistema
en su entorno de operación. Ambos tipos de requisitos son importantes para el éxito del proyecto de
desarrollo de software.

5. ¿Qué son los requisitos funcionales y los no funcionales? y sus características

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:

Describen las funcionalidades del sistema.

Explican lo que el sistema debe hacer.

Especifican las entradas, salidas y comportamiento del sistema.

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.

Características de los requisitos no funcionales:

Describen las características que el sistema debe tener.


Especifican los criterios que se utilizarán para juzgar la operación del sistema.
Pueden incluir aspectos de calidad, rendimiento, seguridad, usabilidad, etc.
Son difíciles de verificar.
En resumen, los requisitos funcionales describen lo que el sistema debe hacer, mientras que los
requisitos no funcionales describen las características que el sistema debe tener. Ambos tipos de
requisitos son importantes para el éxito del proyecto de desarrollo de software.

6. ¿Cuál es la manera correcta de escribir requisitos?

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.

También podría gustarte