SIREN - Jornadas de Ingeniería de Requisitos Aplicada
1. SIREN: Un Proceso de Ingeniería
de Requisitos Basado en
Reutilización
Ambrosio Toval, Joaquín Nicolás y Begoña Moros
Departamento de Informática y Sistemas.
Facultad de Informática.
Universidad de Murcia
Jornadas de Ingeniería de Requisitos Aplicada
Sevilla, 11-12 de junio de 2001
2. Contenido
„ Introducción
„ IR + Reutilización
„ SIREN
ƒ Plantillas de documentos de requisitos
ƒ Repositorio de requisitos reutilizables
‚ Seguridad y Protección de Datos
ƒ Modelo de proceso
ƒ SIREN y Métrica
„ Conclusiones y trabajo futuro
2
3. Introducción
SIREN = “Método práctico de IR basado en reutilización
de requisitos, compatible con los principales estándares en
Ingeniería del Software”
Estándares y buenas
prácticas en IR
IEEE 830-1998 SEGURIDAD
IEEE 1233-1998
... Repositorio
con Requisitos
PROTECCIÓN
DE DATOS
Especificación SyRS SyTS
Ingeniero de Requisitos
de
Requisitos
IRS SRS STS
3
Usuarios
4. IR y Reutilización
„ Nuseibeh & Easterbrook (ICSE'00),
ƒ “Esperamos el desarrollo de modelos de
referencia para especificar requisitos en muchos
dominios de aplicación.”
„ A. van Lamsweerde (ICSE'00),
ƒ “Sorprendentemente, las técnicas para
recuperar, adaptar y consolidar requisitos
reutilizables han recibido relativamente poca
atención en relación con todo el trabajo en
reutilización del software.”
4
5. Enfoque SIREN de reutilización
de requisitos
„ Método de especificación de
requisitos:
ƒ modelo de proceso
ƒ guías (p.ej. la estructura de los documentos
de especificación de requisitos)
ƒ requisitos para dominios específicos
ƒ herramienta de soporte
5
6. Jerarquía de documentos de requisitos
SyRS
Especificación de Requisitos SyTS
del Sistema Especificación de pruebas
(IEEE Std. 1233; del Sistema
IEEE Std. 12207.1)
IRS SRS
Especificación de Requisitos Especificación de Requisitos STS
de Interfaz del Software Especificación de pruebas
(IEEE Std. 830) (IEEE Std. 830 + del Software
VOLERE)
„ Cada documento se debe corresponder con un nivel de
especificación diferente ⇒ diferentes objetivos y
usuarios
„ La jerarquía se decide en función de la complejidad y
el tamaño del proyecto 6
7. 1 Introducción
2 Descripción globalsistema
1.1 Propósito del del sistema
SyRS- System Requirements
1.2 Alcance del sistema
2.1 Contexto del sistema
3 Capacidades del sistema, abreviaturas y restricciones
1.3 Definiciones, acrónimos y condiciones
2.2 Modos y estados del sistema
1.4 Referencias capacidades del sistema
2.3 Físicas
Principales
3.1 Visión global del sistema
1.5 Principales condiciones del sistema
2.4 3.1.1 Construcción
2.5 Principales restricciones del sistema
3.1.2 Durabilidad
2.6 Características de usuarios
3.1.3 Adaptabilidad
2.7 Suposiciones y dependencias
3.1.4 Condiciones ambientales
2.8 Escenarios operacionales
3.2 Características de rendimiento del sistema
3.3 Seguridad del sistema
3.4 Gestión de la información
Specification
3.5 Operaciones del sistema
3.5.1 Factores humanos del sistema
3.5.2 Mantenimiento del sistema
3.5.3 Fiabilidad del sistema
3.6 Política y regulación
3.7 Apoyo al ciclo de vida del sistema
4 Interfaces del sistema
5 Anexos
7
8. SRS- Software Requirements 1 Introducción
1.1 Propósito
2 Descripción global
1.2 Alcance
2.1 Visión del producto
3 Requisitos específicos
2.2 Funciones delacrónimos y abreviaturas
1.3 Definiciones, producto
3.1 Requisitos de interfaces externas
1.4 Referencias
2.3 Características de usuario
3.2 Requisitos funcionales
1.5 Visión general del documento
2.4 Limitaciones generales
3.3 Requisitos de prestaciones
3.3.1 Requisitos de velocidad
2.5 Suposiciones y dependencias
3.3.2 Requisitos de seguridad críticos
3.3.3 Requisitos de precisión
3.3.4 Requisitos de capacidad
3.4 Restricciones de diseño
3.4.1 Entorno físico esperado
3.4.2 Entorno tecnológico esperado
3.4.3 Aplicaciones asociadas
3.4.4 Cumplimiento de estándares
Specification
3.5 Atributos del sistema software
3.5.1 Fiabilidad
3.5.2 Disponibilidad
3.5.3 Seguridad
3.5.4 Mantenimiento
3.5.5 Portabilidad
3.6 Otros requisitos
3.6.1 Requisitos de apariencia
3.6.2 Requisitos de utilización
3.6.3 Requisitos políticos y culturales
3.6.4 Requisitos legales
4 Anexos 8
9. Repositorio de requisitos
SRS
…
„ dominios 3. Requisitos específicos
…
3.5 Requisitos de Sistema Software
…
„ perfiles 3.5.3.Seguridad
…3.5.3.1 Confidencialidad
SRS3531S23 El usuario...
SRS3531L12 La auditoría...
…
Repositorio de Requisitos Reutilizables
SRS
SRS …
SRS 3. Requisitos específicos
…
… …
3. Requisitos específicos
3. Requisitos específicos 3.5 Atributos del sistema software
…
… …
3.5 Attributes del sistema software
3.5 Atributos del sistema software 3.5.3.Seguridad
…
… …3.5.3.1 Confidencialidad
3.5.3.Seguridad
3.5.3.Seguridad …
…3.5.3.1 Confidencialidad
…3.5.3.1 Confidencialidad
SRS3531L12 La auditoría ...
SRS3531S23 El usuario ... …
…
Perfil de Seguridad Perfil de la LOPD Perfil …
9
10. Clasificación de requisitos
„ parametrizados:
S R S .3 .5 .3 .1 .S .3 0 El administrador de seguridad
deberá realizar comprobaciones cada [Tiempo en
meses] para detectar identificadores de usuario
que no hayan sido utilizados en los últimos
[Tiempo en meses].
„ no-parametrizados:
S Y R S .3 .1 .1 .S .6 8 . Los documentos y disquetes
deberán guardarse perfil en armarios cuando no se usen
Ubicación
y especialmente fuera de la jornada laboral.
documento sección dentro del documento
10
11. Atributos de los requisitos
„ Obligatorios:
ƒ identificación (única) ƒ justificación
ƒ prioridad ƒ mantenimiento
ƒ criticidad ƒ prestaciones
ƒ viabilidad ƒ fiabilidad IEEE 1233
ƒ estado (pendiente de definición, pendiente de revisión,
definido, descartado, aprobado, implementado y
verificado)
„ Dependientes del dominio o perfil
(p.ej. Seguridad y Protección de datos):
ƒ Fuente
ƒ Cumplimiento 11
12. Relaciones de traza
„ Representan dependencias entre requisitos
„ Tipos de dependencias:
ƒ inclusivas
ƒ exclusivas
entre requisitos
ƒ del mismo documento
ƒ de documentos diferentes
12
13. Ejemplo. Extracto del SyRS
( ...)
3. Capacidades del sistema. Condiciones y restricciones.
3.1. Físicas.
3.1.1. Construcción.
( ...)
( R 1) S Y R S 3 11S 6 8 . Los documentos y disquetes se guardarán bajo
llave cuando no se estén utilizando y fuera de la jornada laboral.
3.6. Política y Regulación.
( R 2 ) S Y R S 3 6 S 2 6 . Los usuarios autorizados del sistema de
información deberán conocer su responsabilidad en relación a los controles
de acceso y a la información que está bajo su disposición. Para ello se
establecerán tres condiciones:
a)Los usuarios autorizados tendrán que usar su clave de manera adecuada.
b)Los usuarios autorizados no pueden descuidar ni un momento la
información que manejan.
c)Los usuarios autorizados tienen que seguir las medidas de seguridad
impuestas para evitar accesos no autorizados a la información que
manejan. 13
Dependencias: R1, R3 (...)
14. Ejemplo. Extracto del SRS
...
3. Requisitos específicos.
R1
3.5. Atributos del software. R2
3.5.3. Seguridad. R3 R4
3.5.3.1. Confidencialidad.
( R 3 ) S R S 3 5 3 1S 1. El sistema operativo que se utilice proporcionará el
mecanismo de claves para controlar y/o limitar el acceso a los usuarios.
D e p e n d e n c ia s : R 4
( R 4 ) S R S 3 5 3 1S 14 . El sistema operativo que se utilice proporcionará
programas para verificar la calidad de las contraseñas en el Sistema de
Control de Accesos. Se dice que una clave es de calidad si cumple por lo
menos estas tres características:
a)El número mínimo de caracteres es [n, n >= 6].
b)Tiene al menos [n, n>=1] caracteres numéricos y [m, m>=1] caracteres
alfanuméricos.
c)Se cambia cada [tiempo en días] para usuarios generales y cada [tiempo
en días] para usuarios con privilegios. 14
15. Ejemplo de traza exclusiva
intradocumento
S R S .3 .4 .3 .S .5 . El firewall deberá ser establecido en una
configuración screened host.
Exclusiones: SRS.3.4.3.S.6
S R S .3 .4 .3 .S .6 . El firewall deberá ser establecido en una
configuración screened subnet.
Exclusiones: SRS.3.4.3.S.5.
15
16. Perfiles de Seguridad y Protección
de Datos
„ Seguridad
ƒ Fuente: MAGERIT
ƒ Estudiar los riesgos que afectan al SI
ƒ Especificar los requisitos que gestionan dichos
riesgos (medidas de salvaguarda)
„ Protección de Datos
ƒ Fuente: LOPD y RMS
ƒ Más práctico que consultar directamente la ley
16
17. Modelo de proceso de SIREN
Requisitos
Utilización
informales
del
Repositorio
Análisis y
Elicitación
Negociación
Documento de Requisitos
requisitos e aceptados
informe de
validación
Validación Documentación
Borrador de
documento de
requisitos 17
18. Repositorio
Reutilizable
Selección de
Requisitos
reutilización de requisitos SEGURIDAD Plantillas rellenas
con Requisitos
LOPD SyRS SyTS
DB reutilizados
...
Plantillas SyRS SyTS
vacías IRS SRS STS
Enfoque SIREN para
IRS SRS STS
Requisitos
Informales
Mejora del Elicitación de Análisis y
Repositorio Requisitos Negociación
Específicos
Requisitos Aceptados
SyRS SyTST
Documentos de
SyRSSyTS
Requisitos
Validados IRS SRS STS
IRS SRS STST
Validación Documentación
SyRSSyTS
Continuar: análisis,
diseño, IRS SRS STS
implementación, ... Stakeholders
Borrador de Documentos de
Requisitos
Analista
18
19. SIREN y Métrica v.3
„ Soporte a la actividad
ASI 2. “Establecimiento de Requisitos”:
ƒ estructura del catálogo de requisitos de Métrica
ƒ modelo de proceso para llevar a cabo las tareas de
obtención, análisis y validación de requisitos.
„ Además, soporte a:
ƒ tarea DSI 1.7. “Especificación de Requisitos de
Operación y Seguridad”
ƒ interfaz de Seguridad de Métrica v.3 con MAGERIT
(perfiles de seguridad y protección de datos)
19
20. Conclusiones
„ Método basado en la reutilización de
requisitos y en estándares de Ing. Sw.
ƒ Acelera el proceso de desarrollo
ƒ Plantea explícitamente los requisitos de
calidad del software
ƒ Compatible con Métrica v.3
20
21. Trabajo futuro
„ Refinar el modelo de referencia de requisitos
ƒ plantillas de requisitos, patrones lingüísticos,
relaciones de traza
„ Gestión de inconsistencias
„ Soporte al proceso
ƒ reutilización
ƒ relaciones exclusivas
ƒ requisitos parametrizados
ƒ estructura del repositorio
„ Nuevos dominios y perfiles
ƒ Tarjeta inteligente
„ Más casos de estudio reales 21
22. SIREN: Un Proceso de
Ingeniería de Requisitos
Basado en Reutilización
Gracias por su atención !
Editor's Notes
Uno de los principales desafios en IR = Reutilización de requisitos. 1) desarrollo de modelos de referencia de requisitos en muchos dominios de aplicación que: a) pasaremos de diseño creativo a diseño normal b) facilitará la elección de software COTS Como por ejemplo los trabajos de Lutz (safe reuse) y Jones et al. (trust requirements for e-commerce) 2) la investigación en reutilización de requisitos no ha progresado suficientemente para determinar si estas aproximaciones son prácticas
Sustituyo Source (fuente) en los atributos obligatorios por justificación , para no colisionar con los atributos dependientes del dominio o perfil.