Ingenieria de requerimientos

1. SISTEMAS DE INFORMACION
Ingeniería de
Requerimientos

2. INTRODUCCION
Trata de lo que el sistema debe hacer, sus
propiedades emergentes y esenciales, y las
restricciones en el funcionamiento del sistema
y los procesos de desarrollo de software. Es el
proceso de comunicación entre los clientes y
usuarios del software y los desarrolladores del
mismo.

3. ¿A qué se le llama Ingeniería
de Requerimientos?
Al proceso de descubrir, analizar,
documentar y verificar los servicios
proporcionados por el sistema y sus
restricciones operativas.

4. NIVELES DE REQUERIMIENTOS

5. • Son declaraciones, en • Establecen con detalle las
lenguaje natural y funciones, servicios y
diagramas, de los servicios restricciones operativas
que el sistema proporcione del sistema. El documento
y de las restricciones bajo de requerimientos del
las cuales debe funcionar. sistema debe ser
funcional. Debe definir
exactamente qué es lo que
se va a implementar.
Requerimientos Requerimientos
del Usuario del Sistema

6. Ejemplo:

7. CLASIFICACION DE LOS
REQUERIMIENTOS DEL SISTEMA
De Funcionales
Dominio
No
Funcionales

8. Definiciones:
Describen lo que
el sistema debe
hacer
Se refiere a las
propiedades
emergentes
Se derivan del
dominio de la
aplicación

9. Ejemplo de RF:
1. El usuario deberá tener la posibilidad de buscar
en el conjunto inicial de la base de datos o
seleccionar un subconjunto de ella.
2. El sistema deberá proporcionar visores
adecuados para que el usuario lea documentos
en el almacén de datos.
3. A cada pedido se le deberá asignar un
identificador único, que el usuario podrá copiar al
area de almacenamiento permanente de la
cuenta.

10. Tipos de Requerimientos No
Funcionales

11. Ejemplo de R. No Funcionales:
Nota: Siempre que sea posible, se deben redactar los requerimientos no funcionales
de manera cuantitativa para que se puedan probar de un modo objetivo.

12. Ejemplo de Metas del
sistema y
requerimientos
verificables:

13. Métricas para especificar
requerimientos no
funcionales:

14. Ejemplo de Requerimientos del
dominio:
 El sistema LIBSYS incluye varios requerimientos
del dominio:
1. Deberá existir una interfaz de usuario estándar
para todas las bases de datos que estará basada
en el estándar Z39.50.
2. Debido a las restricciones de derechos de autor,
algunos documentos deberán borrarse después
de su llegada, se imprimirán de forma local en el
servidor y serán distribuidos de forma manual.

15. REQUERIMIENTOS
DEL USUARIO

16. Los requerimientos del
usuario par un sistema deben
describir los requerimientos
funcionales y no funcionales
de tal forma que sean
comprensibles para los
usuarios del sistema sin
conocimiento técnico
detallado.
Únicamente deben especificar el comportamiento
externo del sistema y deben evitar, tanto como sea
posible, las características del diseño del sistema.

17. Ejemplo de cómo redactar un
requerimiento de usuario:

18. Recomendaciones para redactar los
requerimientos del usuario:
1. Inventar un formato estándar y asegurar
que todos los requerimientos se adhieran al
formato.
2. Utilizar el lenguaje de forma consistente.
Distinga entre requerimientos obligatorios y
requerimientos deseables.
3. Resalte el texto (con negrita, cursiva,
color) para distinguir las partes claves del
requerimiento.

19. Notaciones para la especificación
de requerimientos

20. Ejemplo: (Lenguaje Estructurado)

21. Ejemplo: (Lenguaje de descripción de diseño)

22. Ejemplo:
(Notaciones
Gráficas)

23. Ejemplo: (Especificaciones Matemáticas)

24. El documento de requerimientos del
software:
 Es la declaración oficial de qué deben
implementar los desarrolladores del
sistema. Debe incluir tanto los
requerimientos del usuario para el sistema
como una especificación detallada de los
requerimientos del sistema.

25. ¿Quiénes son los usuarios del
documento de requerimientos?

26. IEEE/ANSÍ 830-1998 (IEEE, 1998)
1. Introducción
1.1 Propósito del documento de requerimientos
1.2 Alcance del producto
1.3 Definiciones, acrónicos y abreviaturas
1.4 Referencias
1.5 Descripción del resto del documento
2. Descripción general
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias
3. Requerimientos específicos: incluyen los requerimientos funcionales, no funcionales y
de interfaz. Obviamente, ésta es la parte más sustancial del documento, pero debido a
la amplia variabilidad en la práctica organizacional, no es apropiado definir una
estructura estándar para esta sección. Los requerimientos pueden documentar las
interfaces externas, describir la funcionalidad y el rendimiento del sistema, especificar
los requerimientos lógicos de la base de datos, las restricciones de diseño, las
propiedades emergentes del sistema y las características de calidad.
4. Apéndices
5. índice

27. Estructura de un Documento de Requerimientos

28. EL PROCESO DE LA
INGENIERÍA DE
REQUERIMIENTOS

29. Meta:
Crear y mantener un
documento de requerimientos
del sistema.

30. Estudio
¿El sistema es útil para
de
el negocio?
Viabilidad
Validación
Proceso Obtención
de IR y Análisis
El
La verificación de que los descubrimiento
requerimientos de
realmente definen el requerimientos
sistema que quiere el
cliente
Especificación La transformación de
requerimientos en
formularios estándar

31. ESTUDIO DE VIABILIDAD

32. Concepto:
Es un conjunto de requerimientos de
negocio preliminares, una descripción
resumida del sistema y de cómo éste
pretende contribuir a los procesos del
negocio.
Nota: Su resultado debe ser un informe que
recomiende si merece o no seguir con la ingeniería de
requerimientos y el proceso de desarrollo del software.

33. ¿Qué se hace en el Estudio
de Viabilidad?

34. ¿Contribuye el sistema a los objetivos
generales de la Organización?
¿Se puede
implementar el
sistema utilizando la
tecnología actual y
dentro de las
restricciones de
costo y tiempo?

35. Obtención y Análisis de
Requerimientos:
 En esta actividad, los IS trabajan con los
clientes y los usuarios finales del sistema
para determinar el dominio de la
aplicación, qué servicios debe proporcionar
el sistema, el rendimiento requerido del
sistema, las restricciones hardware, etc.

37. Dificultades para obtener y comprender
los requerimientos de los stakeholders:
1. Los Stakeholders no conocen lo que desean
obtener.
2. Los Stakeholders expresan los requerimientos con
sus propios términos de forma natural.
3. Diferentes Stakeholders tienen diferentes
requerimientos.
4. Los factores políticos pueden influir en los
requerimientos del sistema.
5. El entorno económico y del negocio en el que se
lleva a cabo el análisis es dinámico.

38. LAS ACTIVIDADES DEL PROCESO SON:
Descubrimiento
de
Requerimientos
Clasificación y
Documentación
Organización
de
de
Requerimientos
Requerimientos
Ordenación por
prioridades y
negociación de
requerimientos

39. Herramientas para el descubrimiento de
Requerimientos:
Puntos de Vista
Etnografía
Entrevista
Escenarios
Exhibir el
interior
<<incluir>>
Reabastecer de <<extender>>
acuerdo a las Reabastecer
ventas
<<incluir>>
Representante Casos de Uso Cubrir el
del proveedor interior

40. Validación de Requerimientos
Trata de mostrar que los requerimientos realmente
definen el sistema que el cliente desea.
Su importancia radica a que encontrar errores en el
documento de requerimientos puede conducir una
reducción de costos, tiempo y desempeño que al
repetir el trabajo cuando son descubiertos durante
el desarrollo o después de que el sistema esté en
uso.

41. Tipos de Verificaciones
Completitud
Consistencia Realismo
Validez Verificación Verificabilidad

42. Técnicas de revisión de
requerimientos
Generación de
Casos de
Prueba
Construcción
de Prototipos
Revisiones de
Requerimientos

43. Tarea:
 Un sistema software se desarrolla para gestionar
los registros de los pacientes que ingresan en una
clínica para tratamiento. Los registros incluyen
anotaciones de todos los controles habituales a los
pacientes (temperatura, tensión arterial, etc.), los
tratamientos dados, las reacciones de los
pacientes, etc. Después del tratamiento, los
registros de su estancia se envían al doctor del
paciente, quien mantiene su historial clínico
completo. Identifique los puntos de vista
principales que se pueden tener en cuenta en la
especificación del sistema y organícelos utilizando
un diagrama de jerarquía de puntos de vista.