Este documento presenta información sobre ingeniería de requisitos. Define requisitos funcionales y no funcionales, y clasifica los requisitos no funcionales. Explica que la ingeniería de requisitos implica actividades como extracción, análisis y especificación de requisitos, e involucra a la empresa, usuarios y clientes. También describe la importancia de gestionar los requisitos y menciona herramientas para la gestión de requisitos como el control de versiones y la trazabilidad.

1. Taller EN CLASES
1. ¿Qué es un requerimiento/requisito?
2. En una tabla favor decir los tipos de requisitos
3. Hacer un diagrama con la clasificación de los requisitos no
funcionales.
4. ¿Qué se entiende por Ingeniería de Requisitos (IR)?
5. Mencione las actividades de la Ingeniería de Requerimientos.
6. Cuáles son las personas involucradas en la Ingeniería de
Requerimientos.
7. Análisis comparativo de las técnicas de Ingeniería
de Requerimientos
8. Importancia de la Ingeniería de Requerimientos
9. Gestión de Requisitos. Principales características
10. Mencionar y explicar con sus propias palabras
las Herramientas de Gestión de Requisitos

2. ¿Qué es un requerimiento/requisito de software?
Un requisito funcional define una función del sistema de
software o sus componentes. Una función es descrita como un
conjunto de entradas, comportamientos y salidas. Los
requisitos pueden ser: cálculos, detalles técnicos, manipulación
de datos entre otras .El desarrollo de software puede ser un
proceso repetitivo Un requisito funcional típico contiene un
nombre, un número de serie único y un resumen. Esta
información ayuda a entender al usuario a entender el por qué
el requisito es necesario, para seguir al mismo durante el
desarrollo del producto.

3. Tipos de requisitos
Completa
Todos los requerimientos deben estar reflejados en ella y
todas las referencias deben estar definidas.
Consistente Debe ser coherente con los propios requerimientos y
también con otros documentos de especificación.
Inequívoca La redacción debe ser clara de modo que no se pueda
mal interpretar.
Correcta El software debe cumplir con los requisitos de la
especificación.
Trazable Se refiere a la posibilidad de verificar la historia,
ubicación o aplicación de un ítem a través de su
identificación almacenada y documentada.
Priorizable Los requisitos deben poder organizarse
jerárquicamente según su relevancia para el negocio y
clasificándolos en esenciales, condicionales y
opcionales.
Modificable Aunque todo requerimiento es modificable, se refiere a
que debe ser fácilmente modificable.
Verificable Debe existir un método finito sin costo para poder
probarlo.

4. Clasificación de los requisitos no funcionales.
Ingeniería de Requisitos (IR)
Se basa en un diverso número de técnicas de
Requerimientos, que pueden o no acoplarse con el proceso
de desarrollo.
La técnica más común de obtención de requerimientos es la
basada en casos de uso. Ésta se suele usar en procesos de
desarrollo estático y formal como Cascada, RUP, o SPL
(Software Producto Line). Consiste en crear un requerimiento
para cada funcionalidad específica del sistema; ejm: entra un
nuevo disfraz al almacén. Tal requerimiento va directamente
a un documento que especifica tanto detalles de negocio
como detalles técnicos.
Otro approach es el de Historias de Usuario. Historias de
usuario se usan más en procesos Ágiles de desarrollo:
REQUISITO
NO-FUNCIONAL
ATRIBUTO DE
CALIDAD
REQUISITO DE
INTERFACE
RESTRISCION

5. Scrum, Extreme Programming, Discourse Programming, etc
(de hecho, el concepto de historias de usuario surgió en
Extreme Programming). Historias de usuario son, en terminos
vulgares, malviajes que se avienta tu cliente en como desea
que se utilice el sistema a nivel usuario; es decir: "me meto a
la opción nuevo disfraz y ahí que le pueda picar aqui y aqui
para crear un nuevo disfraz en almacén". Estas historias de
usuario, se trabajan directamente hacia planes de pruebas,
en vez de pasar a documento de requerimientos. Tu
requerimiento es la prueba que valide tal historia de usuario
(particularmente útil para desarrollos orientados a pruebas y/o
características).
Actividades de la Ingeniería de Requerimientos
Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el
nombre comúnmente dado a las actividades involucradas en el descubrimiento
preliminar de los requisitos de usuario.
Estudio de viabilidad: Enesta fase se estima si el problema del usuario se
podrá resolver con la tecnología disponible y si el sistema será rentable según el
presupuesto del que se dispone.
Análisis: Sobre la base de la extracción realizada previamente, comienza esta
fase en la cual se interactúa con clientes o usuarios para determinar los requisitos
funcionales y no funcionales del sistema, además del dominio de la aplicación.

6. Especificación: Enesta fase se documentan los requisitos con mayor detalle y
precisión, de manera que sirva de base para un contrato entre el desarrollador y el
cliente.
Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos,
es decir, verificar todos los requisitos que aparecen en el documento especificado para
asegurarse de que son aceptados por el cliente. Esto implica verificar que los requisitos sean
consistentes, que estén completos, que sean realistas y que puedan ser verificables.
Personas involucradas en la Ingeniería de
Requerimientos
- Empresa
- Usuario
- Cliente
Importancia de la Ingeniería de Requerimientos
La ingeniería de requerimientos es una de las disciplinas fundamentales de la ingeniería
de software y proporciona información para la mayoría de las demás disciplinas. Este
artículo presenta resultados de investigaciones que fundamentan de manera cuantitativa
esta cuestión. El propósito es demostrar las consecuencias del descuido de la disciplina
de requerimientos: retrasos en el cronograma y costo adicional, nivel alto de defectos en
el software y principalmente la entrega de un software que no satisface las necesidades
del cliente.

7. Gestión de Requisitos
La gestión de los requisitos es un aspecto fundamental dentro de la ingeniería
de requisitos. Los objetivos que se busca con una gestión del cambio al nivel
de requisitos. Es especialmente importante remarcar que esta gestión de
cambio está dirigida exclusivamente para los proyectos cerrados. Vamos a
identificar que conseguimos con la gestión del cambio:
 Controlar el cambio. Con frecuencia se producen cambios dentro de una
organización. El cambio debe de estar estandarizado y controlado. Un control
deficiente puede hacer que la organización se convierta en menos productiva y
los errores e incidencias aumenten de manera considerable en frecuencia e
impacto. Los cambios son los que provocan un avance en la misión de
alinearse con el negocio, nacen por cuestiones de negocio y buscan una
estructura estable cercana a la visión real de negocio
 Todo es un cambio. Pasar de un estado definido de la infraestructura a uno
nuevo siempre supone un cambio y debe de ser gestionado. Habrá que
estudiar el impacto, el coste, etc pero deben de ser tratados como “cambios”.
El objetivo no es burocratizar el proceso los procedimientos, sino la de
controlar el mismo, lo que se aprueba y lo que se lleva finalmente a
construcción e implementación
 Normalizar y estandarizar el cambio. El cambio está íntimamente
relacionado con la gestión de proyectos. Debe de desarrollarse una
metodología estándar para la gestión del cambio que se apoye en la gestión de
proyectos, para manejar con rapidez y minimizando, en lo posible, el impacto
de los cambios. Se procedimiento a la organización ante cualquier evento que
impida la prestación adecuada de un servicio. Una vez establecida la
metodología se comunica, se enseña e implemente y, muy importante, se hace
respetar. Todo cambio se somete a lo que indique la metodología.
 Visión del coste. Normalmente, a la hora de realizar un cambio no tenemos
mucha información acerca del coste que supone el mismo. El identificar a un
responsable de su estudio, análisis y planificación, permite ajustar mejor el
impacto y la viabilidad del cambio. Es importante que el gestor del cambio se
vea suficientemente respaldado por la organización, para el éxito de sus
actividades.
 Planificación del cambio. Es muy importante pensar que el cambio se
adapta a la agenda del negocio, no a la de TI. Es interesante mantener un
calendario de cambios con las fechas propuestas para la implementación de los
mismos. No debe de perderse la perspectiva, que el cambio por insignificante
que parezca está orientado a apoyar al negocio.

8. CARACTERISTICAS
1) Características operativas
2) Características de transición
3) Características de revisión
Mencionar las Herramientas de Gestión de Requisitos
 Gestión de requisitos y atributos basados en los modelos de información
 Organización de requisitos
 Configuración y gestión de versión en los requisitos
 Definición de línea base de los requisitos
 Acceso y gestión multiusuario
 Gestión de la trazabilidad
 Consolidación de los requisitos obtenidos
 Gestión de cambios
 Análisis de impacto
Integrantes
Robin Castellanos
Andrés David C.
Vladimir García B.
No Ficha: 1753138
ADSI Jornada Tarde