Capturar Requerimientos Arquitectnicos

ARSO
Instituto Tecnolgico de Culiacn
Antonio Acosta Murillo 11/06/2012

Contenido
Resumen ................................................................................................................... 2 Clasificacin de los requerimientos .............................................................................. 3 El sistema FURPS+ para clasificacin de requerimientos ......................................... 3 Requerimientos funcionales .................................................................................. 3 Usabilidad, fiabilidad, rendimiento y compatibilidad de los requisitos ........................ 3 Diseo, Implementacin, interfaz y los requerimientos fsicos .................................. 4 Cuestionario para obtener requerimientos .................................................................... 4 Un enfoque para recopilar los requisitos arquitectnicos ......................................... 4 Cuestionario de requerimientos de arquitectura ...................................................... 4 Conclusiones.............................................................................................................. 6 Bibliografa ................................................................................................................ 6

Csate con tu arquitectura de prisa, arrepintete en tu tiempo libre. Barry Boehm

1

Capturar Requerimientos Arquitectnicos

Resumen
El artculo Capturing Architectural Requirements1 se enfoca principalmente en la captura de requisitos arquitectnicos, para comenzar con el tema definamos lo que son los requisitos arquitectnicos. El RUP2 nos da la siguiente definicin para cualquier requisito:

Un requisito describe una condicin o capacidad que un sistema debe cumplir, ya sea derivado directamente de las necesidades del usuario, o dicho de un contrato, norma, especificacin u otro documento formalmente impuesto.
Un requisito arquitectnico, es a su vez, cualquier requisito que es arquitectnicamente significante. Los requisitos arquitectnicos implcitos son los requisitos que tienen atributos articulares. Por ejemplo, cualquier requerimiento de alto riesgo, de alta prioridad, o baja estabilidad, podra ser considerado como relevante para la arquitectura. El artculo se enfocar principalmente en criterios explcitos, que a menudo son de naturaleza tcnica. Los siguientes son ejemplos de explcitos los requisitos arquitectnicos: El producto se localizar (soporta mltiples lenguajes humanos). La persistencia ser manejada por una base de datos relacional. La base de datos ser Oracle 8i. El sistema funcionar los siete das a la semana, veinticuatro horas al da. Un sistema de ayuda en lnea se requiere. Toda la lgica de presentacin ser escrito en Visual Basic.

Estos requisitos son muy diferentes. Algunos son funcionales, algunos no funcional, y otros son independientes de los mecanismos tcnicos. Se necesita un enfoque sistemtico que proporciona un marco para la clasificacin de los requisitos arquitectnicos.

1 2

Articulo web escrito por Peter Eeles, Senior IT Architect, IBM. HTTP://GOO.GL/F5NNK Rational Unified Process.

Clasificacin de los requerimientos

El sistema FURPS+ para clasificacin de requerimientos (The FURPS+ System for Classifying Requirements) FURPS+ es sistema de clasificacin ideado por Robert Grady. Las siglas FURPS+ representan: Funcionalidad (Functionality) Usabilidad (Usability) Confiabilidad (Reliability) Rendimiento (Performance) Mantenimiento (Supportability)

El "+" en FURPS+ nos ayuda a recordar las responsabilidades (concerns) tales como: Requisitos Requisitos Requisitos Requisitos de diseo (Design requirements) para la implementacin (Implementation requirements) de interfaz (Interface requirements) fsicos (Physical requirements)

Requerimientos funcionales (Functional Requirements) Estos requisitos generalmente representan las caractersticas principales del producto. Por ejemplo, en una aplicacin de almacn, que podra haber condiciones que deban cumplirse para ordenar el procesamiento o el control de existencias. Sin embargo, los requisitos funcionales no son siempre de dominio especfico. Usabilidad, fiabilidad, rendimiento y compatibilidad de los requisitos (Usability, Reliability, Performance, and Supportability Requirements) La parte restante de URPS es la que describe los requisitos no funcionales que generalmente son relevantes para la arquitectura. La usabilidad se refiere a caractersticas como la esttica y la coherencia en la interfaz de usuario. La fiabilidad se refiere a caractersticas tales como la disponibilidad la exactitud de los clculos del sistema, y la capacidad del sistema para recuperarse de un fallo. El rendimiento se refiere a caractersticas tales como, tiempo de respuesta, el tiempo de recuperacin, el tiempo de puesta en marcha, y el tiempo de apagado. La compatibilidad se refiere a caractersticas como la capacidad de prueba, la adaptabilidad, facilidad de mantenimiento, la compatibilidad, facilidad de instalacin, escalabilidad y localizacin.

Diseo, Implementacin, interfaz y los requerimientos fsicos (Design, Implementation, Interface, and Physical Requirements) El "+" en la sigla FURPS + se utiliza para identificar categoras adicionales que generalmente representan limitaciones. Uno de los requisitos de diseo, a menudo llamado una restriccin de diseo, especifica o restringe las opciones para el diseo de un sistema. Un requisito implementacin especifica o restringe la codificacin o la construccin de un sistema. Un requisito de interfaz especifica un elemento externo con el que un sistema debe interactuar, o las limitaciones sobre los formatos u otros factores utilizados en dicha interaccin. Un requisito fsico especifica una limitacin fsica impuesta en el hardware utilizado para albergar el sistema.

Cuestionario para obtener requerimientos

Un enfoque para recopilar los requisitos arquitectnicos
(An Approach for Gathering Architectural Requirements )

El enfoque de la recopilacin de requisitos arquitectnicos es simple: 1. Mantener una lista completa de los requisitos arquitectnicos (independientemente de si todos los elementos son relevantes para un proyecto en particular). 2. Para cada requisito arquitectnico, formular una o varias preguntas que pueden ayudar en el proceso de especificacin. Asegrese de que todos los actores del sistema se puede entender estas preguntas. 3. Ayudar a las partes interesadas, mostrndoles el impacto potencial de responder a una pregunta de una manera u otra. 4. Capturar las respuestas de los interesados en cada una de las preguntas. 5. Asistir al arquitecto, vigilando que las partes interesadas asignen una prioridad a cada requerimiento de la arquitectura. Esta ponderacin permite al arquitecto realizar compensaciones entre los requisitos. Vale la pena sealar que este enfoque es posible porque, en un nivel alto, el conjunto de requisitos arquitectnicos que deben ser considerados es finito. Cuestionario de requerimientos de arquitectura

(The Architectural Requirements Questionnaire)

Este enfoque se representa mejor en forma de tabla, y para las partes interesadas como un cuestionario de necesidades arquitectnicas. La Tabla 1.1 muestra una porcin de dicho cuestionario e incluye respuestas ejemplo. 4

Requerimientos Licencia

Preguntas

Impacto

Respuestas El mdulo de control de existencias se comercializar como un componente separado del sistema y requerirn de concesin de licencias.

Prioridad Media

El sistema o Cuanto mayor sea la una parte del complejidad del sistema, mecanismo de contar con licencias, mayor ser alguna licencia? el tiempo de comercializacin, y Existen mayor a largo plazo limitaciones en el costo de el mecanismo mantenimiento. que se utilizar para proporcionar la capacidad de concesin de licencias? Existe algn Cuanto mayor sea la requisito sobre disponibilidad, mayor el sistema "up ser el tiempo de time"? Esto comercializacin. puede ser especificada en trminos de tiempo medio entre fallos. Para qu plataformas es necesario que el sistema de soporte? Desarrollo de una plataforma nica acorta el tiempo de comercializacin.

Disponibilidad

La disponibilidad es una caracterstica clave del producto. El producto debe tener un MTBF3 de 60 das.

Alta

Soporte para plataformas

El producto ser lanzado en las siguientes plataformas: Sun Solaris, IBM, AIXHPUX.

Alta

Tabla 1.1: parte de un cuestionario de los requisitos de la arquitectura.

Mean time between failures (MTBF) is the predicted elapsed time between inherent failures of a system during operation.

Rational RequisitePro4 puede ser de gran ayuda en relacin con el cuestionario: Te permite crear mltiples "vistas" del cuestionario. Le da la trazabilidad entre las peticiones de los interesados los requisitos arquitectnicos y ambos casos de uso y requisitos adicionales.

Conclusiones
A lo largo del trabajo aprendimos como captura requerimientos arquitectnicos, para esto definimos lo que son los requerimientos, para entender mejor el mtodo o el enfoque de captura de stos. Dividimos los requerimientos por el sistema de clasificacin FURPS+ ideado por Robert Grady: funcionalidad, usabilidad, confiabilidad, rendimiento, mantenimiento. Sin olvidar el + que nos ayuda a recordar las responsabilidades tales como: rendimiento de diseo, implementacin, interfaz y fsico. Definimos cada uno de stos para tener un panorama ms amplio del tema y as poder entenderlo mejor. Y por ltimo llegamos a la parte medular de este ensayo, me refiero, a el cuestionario para obtener requerimientos, que ms que nada, es un enfoque o una gua para la obtencin de los requerimientos que se basa en cinco puntos principales, el primero de stos puntos sera tener un lista completa de los requisitos arquitectnicos, que nos llevar al segundo paso, tener una o ms preguntas por cada requisito. El tercer punto nos habla sobre la importancia de hacer entender a los involucrados del proyecto la importancia que tienen sus repuestas, el cuarto paso sera apuntar dichas respuestas para tener un control o un orden. Y por ltimo, y no menos importante, asistir al arquitecto, revisando que los involucrados asignen prioridades a cada requisito, esto permitir al arquitecto realizar compensaciones entre los requisitos. Para terminar esta conclusin, hago hincapi al cuestionario ejemplo de la tabla 1.1 donde se puede ilustrar ms a fondo todo lo que se aprendi en la seccin del enfoque de la recopilacin de requisitos arquitectnicos.

Bibliografa
1. PETER EELES, 15 NOVIEMBRE 2005, CAPTURING ARCHITECTURAL REQUIREMENTS. DISPONIBLE EN: http://www.ibm.com/developerworks/rational/library/4706.html

Es una herramienta para la gestin de requisitos y casos de uso, ayuda a mejorar la comunicacin y la trazabilidad, promover el desarrollo colaborativo, e integrar los requisitos de todo el ciclo de vida.