Jfcastillo

Requerimientos No-Funcionales y
Arquitectura de Software
Jaime F. Castillo.
QuarkSoft, S.C.
CIMAT, A. C.

© QuarkSoft

Agenda
•
•
•
•
•
•
•
•
•

© QuarkSoft

Objetivo
Ingeniería de Requerimientos
Niveles de Requerimientos
Documentos de Requerimientos
Requerimientos No-Funcionales
Requerimientos Arquitecturales
Atributos de Calidad
Conclusiones
Comentarios y Preguntas

Objetivo
• Presentar los conceptos generales de la
Ingeniería de Requerimientos y el
impacto de los requerimientos no
funcionales en el desarrollo de la
arquitectura de software.

© QuarkSoft

Ingeniería de Requerimientos

© QuarkSoft

Niveles de requerimientos
• Los Requerimientos de Software
incluyen tres niveles:
– Requerimientos de Negocio (RN).
– Requerimientos de Usuario (RU).
– Requerimientos Funcionales / No
Funcionales (RF / RNF).

© QuarkSoft

Documentos Requerimientos
Template de RN n
Template de RN ...
Objetivos de
negocio que se
quieren alcanzar
con el Sistema

Template de RN 3
Template de RN 2
Template de RN 1

Template de RU n
Template de RU ...
Actividades que
el usuario realiza
con el sistema

Template de RU 3
Template de RU 2
Template de RU 1

Visión
y
Alcance
de Negocio
(VAN)

Documento
Integrador de
Requerimientos
de Usuario
(DIRU)

Template de RF n
Template de RF ...
Template de RF 3
Template de RF 2
Template de RF 1

Funcionalidad del
Sistema
Template de RNF n
Template de RNF ...
Template de RNF 3
Template de RNF 2
Template de RNF 1

© QuarkSoft

Especificación
de
Requerimientos
de Software
(Software
Requirement
Specification
- SRS)

Requerimientos No Funcionales
• Los requerimientos no funcionales incluyen:
– Restricciones
• Las restricciones son características que no pueden ser
negociadas y que son impuestas por el cliente como
guía o definición para el sistema

– Atributos de calidad.
• Son propiedades o características del sistema que
importan a los stakeholders y que por lo tanto afectarán
el grado de satisfacción del sistema.

• Este tipo de requerimientos pueden ser
evaluados con dos enfoques:
– Factores de Calidad (externo) – ejecución.
– Criterios de Calidad (interno) - desarrollo.

© QuarkSoft

Requerimientos Arquitecturales
• Los requerimientos que tienen una
mayor influencia sobre la arquitectura y
sus componentes son:
– Objetivos de Negocio
– Requerimientos Funcionales.
– Atributos de Calidad
– Restricciones

© QuarkSoft

Atributos de Calidad
• De acuerdo a los autores del libro “Software
Architecture in Practice” en alrededor del 90% de los
sistemas que se han evaluado, los atributos de
calidad se agrupan en seis categorías principales:
– De importancia para el cliente / usuario.
•
•
•
•
•

Desempeño (3).
Usabilidad (6).
Disponibilidad (1).
Seguridad (4).
Interoperabilidad, Confiabilidad, Escalabilidad, Precisión.

– De importancia para el desarrollador.
• Modificabilidad (2).
• Facilidad de Prueba (5).
• Reusabilidad, Extensibilidad, Portabilidad, Facilidad de
Instalación.

© QuarkSoft

Documentación de los RNF
• Dependiendo de los tipos de RNF solicitados por
cliente/usuario, se recomienda hacer un análisis para
identificar el costo/beneficio de cumplir unos u otros.
• La definición de los RNF debe realizarse
considerando las siguientes características (SMART
por sus siglas en inglés):
– Específico (Specific): sin ambigüedad, conciso, claro, simple
y con suficiente detalle.
– Medible (Measurable): debe poderse evaluar si se cubrió el
requerimiento o no. ¿Qué pruebas se deben realizar? O
¿Qué criterios se deben cumplir?
– Alcanzable (Attainable): técnicamente factible. Análisis
profesional de la posibilidad del requerimiento.

© QuarkSoft

– Realizable (Realizable): se puede llevar a cabo con los
recursos disponibles. ¿Se tiene a la gente, la habilidad, la
infraestructura, el tiempo…?
– Rastreable (Traceable): se le puede dar seguimiento desde
su concepción, a través de la especificación, diseño,
implementación y prueba.

© QuarkSoft

• Una técnica para validar la claridad y
definición de un RNF es la técnica de
escenarios.

© QuarkSoft

Documentación de RNF
• Entradas
– Fuente de Estímulo: es el actor que genera el estímulo
(usuario, sistema, etc…)
– Estímulo: es la condición que necesita ser considerada al
presentarse en el sistema.

• Condiciones
– Entorno: condiciones en las que se encuentra el sistema al
presentarse un estímulo.
– Artefacto: componente o destinatario que recibe el estimulo
(puede ser todo el sistema o una o más partes)

• Resultados Esperados
– Respuesta: es la actividad que se realiza una vez detectado
el estímulo.
– Medida de Respuesta: métrica definida para el tipo de
estímulo y poder determinar un valor cuantificable.

© QuarkSoft

Ejemplos de RNF
Número de requerimiento

SICOBIM-RE01

Descripción del requerimiento

Las consultas del sistema deberán responder de manera inmediata

Req. de usuario relacionado

N/A.

Razón por la que es requerido

Si una consulta tarda mucho, podría dejar esperando a otros procesos, afectar en el
servidor e interferir con el trabajo cotidiano del usuario.

Métrica con la que se determinará que el requerimiento esta cubierto

Segundos (máximo de tiempo por consulta, medido en segundos).

Dependencias con otros requerimientos en caso de existir]

SICOBIM-RE02

Conflictos con otros requerimientos en caso de existir

N/A.

© QuarkSoft

Ejemplos de RNF
Atributo

Despempeño

Fuente

Usuario

Estímulo
Consulta
Catálogo de
Productos

Artefacto

Sistema

Entorno

Operación
Normal

Respuesta

Resultado de la Consulta

Medida

T <= 3s

El usuario podrá consultar el catálogo de productos del sistema, en un horario de operación normal, obteniendo el resultado en un tiempo máximo de 3
segundos

Disponibilidad

Externa

Fallo en
dispositivo I/O

Controlador

Operación
Normal

-Mensaje de error en
pantalla
-Deshabilitar Dispositivo

Sin interrupción en
la operación

El sistema deberá mostrar un mensaje de error en pantalla y deshabilitar un dispositivo, cuando algún fallo en este último afecte al controlador del sistema,
sin ocasionar interrupción en la operación.

Modificabilidad

Desarrollador

Agregar Regla de
Negocio

Otorgamiento de
Crédito

Fase de
Desarrollo

El código es integrado

# clases modificadas
<= 2

Un desarrollador podrá agregar una nueva regla de negocio al módulo de otorgamiento de crédito modificando máximo 2 clases.

Seguridad

Usuario

Intentos erróneos
consecutivos de
acceso

Login de Sistema

Operación

-Registro de evento en
bitácora
-Bloqueo de cuenta

# intentos = 3

El sistema bloqueará la cuenta del usuario y registrará dicho evento en bitácora cuando el usuario tenga 3 intentos erróneos consecutivos de acceso.

© QuarkSoft

Problemática
• El desarrollo de la Arquitectura se convierte
en una preferencia tecnológica por parte del
Arquitecto de Software y no en el
cumplimiento de los RNF.
• No se evalúa la arquitectura de software.
• Dentro del desarrollo de requerimientos la
obtención de requerimientos no funcionales
representa un área de oportunidad.

© QuarkSoft

Retos
• Investigación sobre la obtención, análisis,
especificación y validación de
requerimientos no funcionales.
• Desarrollo de una estrategia para la mejora
de competencias de Ingenieros de
Requerimientos y Arquitectos de Software (y
su relación).
• Mejora de la calidad de los productos de
trabajo de la fase de requerimientos a través
de inspecciones (fondo).
© QuarkSoft

Referencias
•
•
•
•
•
•
•

•

© QuarkSoft

Use cases; Daryl Kulak, Eamonn Guiney
Verification and validation for quality of UML 2.0 models;
Bhuvan Unhelkar
Requirement Engineering, Karls E. Wiegers, Second Edition.
Use case modeling; Kurt Bittner, Ian Spence, Ivar Jacobson
More About Software Requirements: Thorny Issues and
Practical Advise; Karl E. Wiegers
Defining Non-Functional Requirements; Ruth Malan and
Dana Bredemeyer
Models for Evaluating and Improving Architecture
Competence, Len Bass, Paul Clements, Rick Kazman, Mark
Klein, March 2008, TECHNICAL REPORT, CMU/SEI-2008TR-006
Conceptos de Arquitectura de Software: Requerimientos
Arquitecturales; Humberto Cervantes Maceda

Jfcastillo

Más contenido relacionado

La actualidad más candente (20)

Similar a Jfcastillo (20)

Jfcastillo