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 !