SIREN: Un Proceso de Ingeniería de Requisitos Basado en
Reutilización
Ambrosio Toval, Joaquín Nicolás y Begoña MorosDepartamento 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
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”
Ingeniero de Requisitos
Usuarios
SyRS
SRS
SyTS
STSIRS
Especificación de
Requisitos
Estándares y buenas prácticas en IR
IEEE 830-1998IEEE 1233-1998
... Repositorio con Requisitos
SEGURIDAD
PROTECCIÓN DE DATOS
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.”
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
6
Jerarquía de documentos de requisitos
❚ 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
SyRSEspecificación de Requisitos
del Sistema(IEEE Std. 1233;
IEEE Std. 12207.1)
SRSEspecificación de Requisitos
del Software(IEEE Std. 830 +
VOLERE)
IRSEspecificación de Requisitos
de Interfaz(IEEE Std. 830)
STSEspecificación de pruebas
del Software
SyTSEspecificación de pruebas
del Sistema
7SyR
S- S
yste
m R
equi
rem
ents
S
peci
fica
tion
3 Capacidades del sistema, condiciones y restricciones
3.1 Físicas3.1.1 Construcción3.1.2 Durabilidad3.1.3 Adaptabilidad3.1.4 Condiciones ambientales
3.2 Características de rendimiento del sistema3.3 Seguridad del sistema3.4 Gestión de la información3.5 Operaciones del sistema
3.5.1 Factores humanos del sistema3.5.2 Mantenimiento del sistema3.5.3 Fiabilidad del sistema
3.6 Política y regulación 3.7 Apoyo al ciclo de vida del sistema
4 Interfaces del sistema5 Anexos
1.1 Propósito del sistema1.2 Alcance del sistema1.3 Definiciones, acrónimos y abreviaturas1.4 Referencias
1.5 Visión global del sistema
1 Introducción
2.1 Contexto del sistema2.2 Modos y estados del sistema2.3 Principales capacidades del sistema2.4 Principales condiciones del sistema2.5 Principales restricciones del sistema2.6 Características de usuarios2.7 Suposiciones y dependencias
2.8 Escenarios operacionales
2 Descripción global del sistema
8
3 Requisitos específicos3.1 Requisitos de interfaces externas3.2 Requisitos funcionales3.3 Requisitos de prestaciones
3.3.1 Requisitos de velocidad3.3.2 Requisitos de seguridad críticos3.3.3 Requisitos de precisión3.3.4 Requisitos de capacidad
3.4 Restricciones de diseño3.4.1 Entorno físico esperado3.4.2 Entorno tecnológico esperado3.4.3 Aplicaciones asociadas3.4.4 Cumplimiento de estándares
3.5 Atributos del sistema software3.5.1 Fiabilidad3.5.2 Disponibilidad3.5.3 Seguridad3.5.4 Mantenimiento3.5.5 Portabilidad
3.6 Otros requisitos3.6.1 Requisitos de apariencia3.6.2 Requisitos de utilización3.6.3 Requisitos políticos y culturales3.6.4 Requisitos legales
4 Anexos
1.1 Propósito1.2 Alcance1.3 Definiciones, acrónimos y abreviaturas1.4 Referencias
1.5 Visión general del documento
2.1 Visión del producto2.2 Funciones del producto2.3 Características de usuario2.4 Limitaciones generales
2.5 Suposiciones y dependencias
SR
S- S
oftw
are
Req
uire
men
ts
Spe
cifi
cati
on1 Introducción2 Descripción global
9
Repositorio de requisitos
❚ dominios ❚ perfiles
SRS…
3. Requisitos específicos…3.5 Requisitos de Sistema Software…3.5.3.Seguridad…3.5.3.1 Confidencialidad
SRS3531S23 El usuario...SRS3531L12 La auditoría...…
Repositorio de Requisitos Reutilizables
SRS…
3. Requisitos específicos…3.5 Attributes del sistema software…3.5.3.Seguridad…3.5.3.1 Confidencialidad
SRS3531L12 La auditoría ...…
Perfil de la LOPD
SRS…
3. Requisitos específicos…3.5 Atributos del sistema software…3.5.3.Seguridad…3.5.3.1 Confidencialidad…
Perfil …Perfil de Seguridad
SRS…
3. Requisitos específicos…3.5 Atributos del sistema software…3.5.3.Seguridad…3.5.3.1 Confidencialidad
SRS3531S23 El usuario ...…
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 en armarios cuando no se usen y especialmente fuera de la jornada laboral.Ubicacióndocumento
perfilsección dentro del documento
11
Atributos de los requisitos❚ Obligatorios:
❙ identificación (única)❙ prioridad❙ criticidad❙ viabilidad❙ 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
❙ justificación❙ mantenimiento❙ prestaciones❙ fiabilidad IEEE 1233
12
Relaciones de traza
❚ Representan dependencias entre requisitos
❚ Tipos de dependencias:❙ inclusivas❙ exclusivas
entre requisitos ❙ del mismo documento ❙ de documentos diferentes
13
Ejemplo. Extracto del SyRS( . . . )
3. Capacidades del sistema. Condiciones y restricciones. 3.1. Físicas. 3.1.1. Construcción.
( . . . )
( R 1) S YR 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 YR 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.
Dependencias: R1, R3 (...)
14
Ejemplo. Extracto del SRS. . .3. Requisitos específicos. 3.5. Atributos del software. 3.5.3. Seguridad. 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.
R2R4
R1
R3
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.
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
17
Modelo de proceso de SIRENRequisitosinformales
Análisis yNegociación
Requisitosaceptados
Documentación
Borrador dedocumento de
requisitos
Documento derequisitos einforme devalidación
Validación
Elicitación
Utilizacióndel
Repositorio
18Enf
oque
SIR
EN
par
a re
utili
zaci
ón d
e re
quis
itos
Stakeholders
Analista
SyRS
SRS
SyTS
STSTIRS
Documentos de Requisitos Validados
Continuar: análisis,diseño,implementación, ...
Mejora del Repositorio
Borrador de Documentos de Requisitos
SyRS
SRS
SyTS
STSIRS
Validación
Análisis y Negociación
SyRS
SRS
SyTS
STSIRS
Plantillas rellenascon Requisitos
reutilizados
Requisitos Informales
Documentación
Requisitos Aceptados
SyRS
SRS
SyTST
STSIRS
SyRS
SRS
SyTS
STSIRS
Plantillasvacías
Elicitación de Requisitos Específicos
Selección de Requisitos
LOPD
RepositorioReutilizable
SEGURIDAD
DB...
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)
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
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
SIREN: Un Proceso de Ingeniería de Requisitos Basado en Reutilización
Gracias por su atención !