La ingeniería de requerimientos es fundamental para garantizar la calidad en los sistemas de información, asegurando que se satisfacen las expectativas y necesidades de los usuarios. Incluye actividades como extracción, análisis, especificación y validación de requerimientos, utilizando técnicas como entrevistas, análisis de sistemas existentes y creación de prototipos. Existen requisitos funcionales, que describen funciones específicas del sistema, y no funcionales, que abarcan características generales y restricciones del sistema.

1. Ingeniería de
Requerimientos
Mauricio Carrillo Coto
Daniel Víquez
Tatiana Herrera
Alejandro Fernández
Michael Porras

2. ¿Qué es ingeniería de requerimientos?
 Es una pieza clave para proporcionar un sistema
de información con calidad.

3.  Esta calidad debe entenderse como la satisfacción
del usuario ante el sistema de información
proporcionado, que cubre las expectativas, deseos y
necesidades que los usuarios manifestaron.

4. ¿Qué es ingeniería de requerimientos
según la IEEE?
 “La condición o capacidad
que debe poseer un
sistema o un componente
de un sistema para
satisfacer un contrato, un
estándar, una
especificación u otro
documento impuesto.”

5. ¿Qué es la definición de requerimientos?
 Es un conjunto
estructurado de
actividades, con las
cuales se obtiene, se
analiza, se negocia, se
valida y mantiene el
documento de
especificación de
requerimientos.

6. Características de los requerimientos
 Necesario: Si su omisión provoca una deficiencia en el
sistema a construir, y además su capacidad,
características físicas o factores de calidad no pueden ser
reemplazados por otras capacidades del producto o del
proceso.

7.  Conciso: Si es fácil de
leer y entender. Su
redacción debe ser simple
y clara para aquellos que
vayan a consultarlos en un
futuro.
 Completo: Si no necesita
ampliar detalles en su
redacción, es decir, si se
proporciona la
información suficiente
para su compresión.

8.  Consistente: Si no es
contradictorio con otro
requerimiento.
 No ambiguo: Cuando tiene
una sola interpretación. El
lenguaje usado en su
definición, no debe causar
confusiones al lector.

9. Actividades Dentro de la
Ingeniería de Requerimientos

10.  Extracción :Extracción es el nombre comúnmente dado
a las actividades involucradas en el descubrimiento de
los requerimientos del sistema.

11.  Análisis: Sobre la base de la extracción realizada
previamente, comienza esta fase en la cual se enfoca en
descubrir problemas con los requerimientos del sistema
identificados hasta el momento.

12.  Especificación: En esta fase se
documentan los requerimientos
acordados con el cliente, en un
nivel apropiado de detalle. Esta
etapa se va realizando
conjuntamente con el análisis, se
puede decir que la especificación
es realizar el análisis realizado
previamente, aplicando técnicas
y/o estándares de
documentación.

13.  Validación: La validación es la etapa final de la Ingeniería de
Requerimientos. Su objetivo es, ratificar los requerimientos, es decir,
verificar todos los requerimientos que aparecen en el documento
especificado para asegurarse que representan una descripción, por lo
menos, aceptable del sistema que se debe implementar.

14. Técnicas Utilizadas en la Ingeniería de
Requerimientos

15.  Entrevistas y Cuestionarios: Las entrevistas y cuestionarios se emplean
para reunir información proveniente de personas o de grupos. El éxito de
esta técnica, depende de la habilidad del entrevistador y de su
preparación para la misma.

16.  Sistemas existentes: Esta técnica consiste en
analizar distintos sistemas ya desarrollados que
estén relacionados con el sistema a ser construido.

17.  Lluvia de ideas (Brainstorm): Este es un modelo que se usa
para generar ideas. La intención en su aplicación es la de
generar la máxima cantidad posible de requerimientos para
el sistema. No hay que detenerse en pensar si la idea es o
no del todo utilizable.

18.  Prototipos: Durante la actividad de extracción de
requerimientos, puede ocurrir que algunos requerimientos
no estén demasiado claros o que no se esté muy seguro de
haber entendido correctamente, todo lo cual puede llevar
a un desarrollo no eficaz del sistema final. Entonces, para
validar los requerimientos hallados, se construyen
prototipos.

19.  Casos de uso: Describir la posible secuencia de interacciones entre el
sistema y uno o más actores, en respuesta a un estímulo inicial
proveniente de un actor, es una descripción de un conjunto de
escenarios, cada uno de ellos comenzado con un evento inicial desde
un actor hacia el sistema.

20. Herramientas CASE

21. CASE: Computer Aided Software Engineering /
Ingeniería de Software Asistida por Computadora
 Se le conoce a todo aquel software que es usado para
ayudar a las actividades del proceso de desarrollo del
software, en donde se ubica la ingeniería de
requerimientos, que se ha venido tratando en este
documento. Estas herramientas se concentran en
capturar requerimientos, administrarlos y producir una
especificación de requisitos.

22. RequisitePro
 Es la herramienta que ofrece
Rational Software para tener
un mayor control sobre los
requerimientos planteados por
el usuario y todos aquellos
requerimientos técnicos o
nuevos de usuario, que surjan
durante el ciclo de vida del
proyecto.

23.  Los esquemas de RequisitePro cumplen
completamente con los estándares requeridos
por algunas de las instituciones a nivel mundial
más reconocidas en el desarrollo de software,
tales como:

24. Ventajas del RequisitePro
 Un producto potente y fácil de
utilizar para la gestión de requisitos
y casos de uso que propicia una
mejor comunicación, mejoras en el
trabajo en equipo y reduce el riesgo
de los proyectos.
 Proporciona a los equipos la
posibilidad de comprender el
impacto de los cambios.

25.  Garantiza que todos los componentes del equipo estarán
informados de los requisitos más actuales para asegurar la
coherencia.
 Proporciona acceso basado en Web para los equipos
distribuidos.

26. Dificultades para definir los
requerimientos

27.  Los requerimientos no son obvios y vienen de
muchas fuentes.
 Son difíciles de expresar en palabras de lenguaje
ambiguo.
 Existen muchos tipos de requerimientos y
diferentes niveles de detalle.

28.  La cantidad de requerimientos en un
proyecto pueden ser difíciles de
manejar.
 Nunca son iguales, algunos son más
difíciles, más riesgosos, mas
importantes o más estables que
otros.
 Un requerimiento puede cambiar a lo
largo del ciclo de desarrollo.

29.  Los requerimientos están relacionados unos con otros, y a su vez
se relacionan con otras partes del proceso.
 Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
 Son difíciles de cuantificar, ya que cada conjunto de
requerimientos es particular para cada proyecto.

30. Requerimientos Funcionales
y no funcionales

31. Requerimientos Funcionales
 Los requerimientos
funcionales de un sistema,
son aquellos que describen
cualquier actividad que
este deba realizar, en otras
palabras, el
comportamiento o función
particular de un sistema o
software cuando se
cumplen ciertas
condiciones.

32.  Por lo general, estos deben incluir funciones desempeñadas
por pantallas específicas, descripciones de los flujos de
trabajo a ser desempeñados por el sistema y otros
requerimientos de negocio, cumplimiento, seguridad u otra
índole.

33. Ejemplos:
 El sistema controlará el acceso y lo permitirá solamente
a usuarios autorizados.
 La base de datos será implementada con trazas de
auditoría.
 Las hojas de cálculo aseguraran los datos usando firmas
electrónicas.

34. Requerimientos No Funcionales
 Los requerimientos no funcionales representan características generales y
restricciones de la aplicación o sistema que se esté desarrollando.
 Suelen presentar dificultades en su definición dado que su conformidad o
no conformidad podría ser sujeto de libre interpretación, por lo cual es
recomendable acompañar su definición con criterios de aceptación que se
puedan medir.

35. Ejemplos:
 Toda funcionalidad del sistema y transacción de negocio debe
responder al usuario en menos de 5 segundos.
 El sistema debe ser capaz de operar adecuadamente con hasta
100.000 usuarios con sesiones concurrentes.
 El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).