Crear modelos de los requisitos de los usuarios

Artículo
08/10/2011

Con Microsoft Visual Studio Ultimate, resulta más fácil entender, analizar y transmitir las necesidades de los usuarios, ya que permite dibujar diagramas sobre sus actividades, y el papel que juega el sistema a la hora de ayudar a estos usuarios a conseguir sus objetivos. Un modelo de requisitos es un conjunto de estos diagramas, cada uno de los cuales se centra en un aspecto diferente de las necesidades de los usuarios.

Si desea una demostración en vídeo, vea: Modeling the Business Domain.

Un modelo de requisitos le ayuda a:

Centrarse en el comportamiento externo del sistema, con independencia de su diseño interno.
Describir las necesidades de los usuarios y las partes interesadas con mucha menos ambigüedad que con el lenguaje natural.
Definir un glosario de términos coherente que los usuarios, desarrolladores y evaluadores puedan utilizar.
Reducir las desviaciones e inconsistencias de los requisitos.
Reducir el trabajo necesario para dar respuesta a los cambios que se producen en los requisitos.
Planear el orden en el que se desarrollarán las características.
Usar los modelos como base de las pruebas del sistema, estableciendo una relación inequívoca entre las pruebas y los requisitos. Cuando se modifican los requisitos, esta relación le ayuda a actualizar las pruebas correctamente. De este modo, tiene la seguridad de que el sistema satisface los nuevos requisitos.

Un modelo de requisitos brinda su máximo partido si se utiliza para centrar las conversaciones con los usuarios o sus representantes y si se consulta de nuevo al comienzo de cada iteración. No es necesario que lo complete exhaustivamente antes de escribir el código. Una aplicación parcialmente operativa, aunque esté muy simplificada, normalmente constituye el punto de partida más estimulante para debatir los requisitos con los usuarios. El modelo resulta un mecanismo eficaz para resumir los resultados de estas conversaciones. Para obtener más información, vea Uso de modelos dentro del proceso de desarrollo.

Nota

A lo largo de estos temas, el término "sistema" hace referencia al sistema o aplicación que se está desarrollando. Puede tratarse de una gran colección de componentes de hardware y software, de una única aplicación o de un componente de software que forma parte de un sistema mayor. En cualquier caso, en el modelo de requisitos se describe el comportamiento que puede verse desde el exterior del sistema, ya sea a través de una interfaz de usuario o una API.

Tareas comunes

Puede crear varias vistas diferentes de los requisitos de los usuarios. Cada vista proporciona un tipo determinado de información. Cuando cree estas vistas, lo más conveniente es pasar con frecuencia de una a otra. Puede comenzar en cualquier vista.

Diagrama o documento	Qué describe en un modelo de requisitos	Sección
Diagrama de casos de uso	Quién utiliza el sistema y qué hace con él.	Describir el uso del sistema
Diagrama de clases conceptuales	El glosario de los tipos que se utilizan para describir los requisitos; son los tipos que pueden verse en la interfaz del sistema.	Definir los términos que se usan para describir los requisitos
Diagrama de actividades	El flujo de trabajo y la información entre las actividades que realizan los usuarios y el sistema o sus componentes.	Mostrar el flujo de trabajo entre los usuarios y el sistema
Diagrama de secuencia	La secuencia de interacciones entre los usuarios y el sistema o sus componentes. Una vista alternativa del diagrama de actividades.	Mostrar las interacciones entre los usuarios y el sistema
Documentos o elementos de trabajo adicionales	Los criterios de rendimiento, seguridad, facilidad de uso y confiabilidad.	Describir los requisitos de calidad del servicio
Documentos o elementos de trabajo adicionales	Las restricciones y reglas que no son específicas de un caso de uso determinado	Mostrar reglas de negocios

Observe que la mayor parte de los tipos de diagramas se pueden utilizar para otros propósitos. Para obtener información general sobre los tipos de diagramas, vea Desarrollar modelos para el diseño de software. Para obtener información básica acerca de cómo se dibujan los diagramas, vea Cómo: Modificar un modelo UML y los diagramas.

Describir el uso del sistema

Cree diagramas de casos de uso para describir quién utiliza el sistema y para qué lo utiliza. Un caso de uso representa un objetivo de un usuario del sistema y el procedimiento que realiza para lograr dicho objetivo.

Por ejemplo, un sistema de venta de comida en línea debe permitir que los clientes elijan elementos de un menú y que los restaurantes que prestan sus servicios actualicen el menú. Puede resumir esto en un diagrama de casos de uso:

Casos de uso para cliente y restaurante

También puede mostrar cómo un caso de uso se compone de casos más pequeños. Por ejemplo, pedir un menú forma parte de la compra de comida, que también incluye el pago y el envío:

El sistema participa en el pago pero no en la entrega.

También puede mostrar qué casos de uso están incluidos en el ámbito del sistema que se está desarrollando. Por ejemplo, el sistema de la ilustración no se ocupa del caso de uso Enviar menú. De este modo, resulta más fácil establecer el contexto del trabajo de desarrollo. (En un diagrama de casos de uso, se pueden utilizar los contenedores del subsistema para representar al sistema o sus componentes).

También ayuda al equipo a deliberar lo que se incluirá en versiones posteriores. Por ejemplo, puede discutir si, en la versión inicial del sistema, Pagar menú se situará directamente entre el restaurante y el cliente en lugar de a través del sistema. En ese caso, en la versión inicial, podría sacar Pagar menú del rectángulo del sistema Cenar ahora.

Un diagrama de casos de uso solo contiene un resumen de los casos de uso. Para proporcionar descripciones más detalladas, puede vincular los casos de uso del diagrama a otros documentos y otros diagramas. Para obtener información acerca de cómo hacerlo, vea Cómo: Vincular un caso de uso a documentos y diagramas.

La creación de un diagrama de casos de uso ayuda al equipo a:

Concentrarse en lo que los usuarios esperan hacer con el sistema sin necesidad de detenerse en los detalles de la implementación.
Analizar el ámbito del sistema o de versiones específicas del sistema.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Información más detallada acerca de cómo se crean casos de uso	Diagramas de casos de uso de UML: Instrucciones
Elementos de un diagrama de casos de uso	Diagramas de casos de uso de UML: Referencia
Cómo se desarrolla el código de los casos de uso	Modelar la arquitectura de un sistema de Software

Definir los términos que se usan para describir los requisitos

Los diagramas de clases de UML pueden ayudarle a desarrollar un vocabulario coherente de los conceptos del negocio que se utilizan para los siguientes propósitos:

Que utilizan los propios usuarios para analizar el negocio en que el sistema trabaja.
Para describir las necesidades de los usuarios, por ejemplo en las descripciones de los casos de uso, las reglas de negocio y los casos de usuario.
Los tipos de información que se intercambian en la API del sistema o a través de la interfaz de usuario.
Las descripciones del sistema o pruebas de aceptación.

Cuando se utilizan con este propósito, el contenido de un diagrama de clases de UML se denomina diagrama de clases conceptuales. (También se conoce como modelo de dominio o modelo de clases de análisis).

En un diagrama de clases conceptuales, solamente se muestran las clases que son necesarias para las descripciones de los requisitos, pero no se muestra ningún detalle del diseño interno del sistema. En el diagrama, no aparecen los detalles del diseño interno del sistema. Por lo general, tampoco se mostrarán las operaciones o interfaces de las clases conceptuales.

Podría dibujar, por ejemplo, estas clases conceptuales para el sistema Cenar ahora:

Clases de menú, pedido, elemento de menú, elemento de pedido.

Un diagrama de clases conceptuales proporciona el vocabulario de términos que se utilizan a lo largo del modelo de requisitos. Por ejemplo, en la descripción detallada del caso de uso Pedir menú, podría escribir:

El cliente elige un Menú a partir del cual crea un Pedido y, a continuación, crea Elementos del pedido en el Pedido seleccionando Elementos del menú en el Menú.

Observe que los términos que se utilizan en esta descripción son los nombres de las clases del modelo. En el diagrama, desaparecen las ambigüedades de las relaciones entre esas clases. Por ejemplo, se muestra claramente que cada Pedido está asociado a un único Menú.

Las equivocaciones relacionadas con los requisitos de los usuarios suelen derivarse de los malentendidos relativos al significado exacto de las palabras. Por ejemplo, la mayoría de los restaurantes compartirán la definición de los términos Menú y Pedido, pero la diferencia entre un elemento de un pedido y un elemento de un menú puede no ser tan clara. Es importante exponer estas diferencias cuando se discutan los requisitos con las partes interesadas del negocio. El diagrama de clases es una herramienta útil que le ayuda a aclarar los términos y sus relaciones.

El modelo de clases conceptuales puede conformar el vocabulario básico mediante el que puede describirse la lógica del negocio del sistema. Sin embargo, en el software, las clases serán normalmente mucho más complejas que en el modelo conceptual, ya que en su implementación deben tenerse en cuenta aspectos como el rendimiento, la distribución, la flexibilidad y otros factores. Es frecuente encontrar en un único sistema varias implementaciones diferentes de una clase conceptual.

Por ejemplo, Pedidos puede representarse en XML, SQL, HTML y C# en diferentes componentes del sistema y en diferentes interfaces entre los componentes. La asociación entre un Pedido y un Menú puede representarse de muchas maneras distintas, como referencias en el código de C#, como relaciones en una base de datos o como identificadores de referencia cruzada en XML. No obstante, a pesar de estas variaciones, el modelo conceptual proporciona información importante que es verdadera en todos los componentes del software. El diagrama de clases del ejemplo nos indica que en cada implementación, habrá un único Menú asociado a cada Pedido.

La creación de un diagrama de clases de requisitos ayuda a su equipo a:

Definir y normalizar los términos básicos que se utilizan en el análisis de las necesidades de los usuarios.
Aclarar las relaciones entre estos términos.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Información más detallada acerca de cómo buscar clases de requisitos	Diagramas de clases de UML: Instrucciones
Elementos de un diagrama de clases conceptuales	Diagramas de clases de UML: Referencia
Cómo desarrollar código a partir de clases conceptuales	Modelar la arquitectura de un sistema de Software

En un diagrama de clases conceptual, no suele ser útil colocar las flechas en las asociaciones para representar la navegabilidad. Esto se debe a que el diagrama no representa una implementación. Las asociaciones representan las relaciones entre los objetos reales. La siguiente extensión de Visual Studio convierte en predeterminadas las flechas que no son de dirección: Sample: UML Domain Modeling features.

Mostrar reglas de negocios

Una regla de negocio es un requisito que no está asociado a un caso de uso determinado y debe cumplirse en todo el sistema.

Muchas reglas de negocios son las restricciones de las relaciones entre las clases conceptuales. Puede escribir estas reglas de negocios estáticas como comentarios asociados a las clases pertinentes de un diagrama de clases conceptuales. Por ejemplo:

Regla en comentario adjunto a una clase de pedido.

Las reglas de negocios dinámicas restringen las secuencias de eventos admisibles. Por ejemplo, puede utilizarse un diagrama de secuencia o actividades para mostrar que un usuario debe iniciar sesión antes de realizar otras operaciones en el sistema.

Sin embargo, muchas reglas dinámicas pueden formularse de forma más eficaz y general si se sustituyen por reglas estáticas. Por ejemplo, puede agregar el atributo booleano 'Conectado' a una clase del modelo de clases conceptuales. 'Conectado' se agregaría como condición posterior del caso de uso de inicio de sesión y como condición previa de la mayor parte de los demás casos de uso. Este enfoque le permite evitar definir todas las combinaciones de secuencias de eventos posibles. También resulta más flexible cuando necesita agregar nuevos casos de uso al modelo.

Tenga en cuenta que las opciones giran en torno a cómo define los requisitos y que esto es independiente del modo en que se implementan los requisitos en el código del programa.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Información más detallada acerca de cómo buscar y registrar reglas de negocios estáticas	Diagramas de clases de UML: Instrucciones
Elementos de un diagrama de clases conceptuales	Diagramas de clases de UML: Referencia
Cómo desarrollar código que se ajuste a las reglas de negocios	Modelar la arquitectura de un sistema de Software

Describir los requisitos de calidad del servicio

Hay varias categorías de requisitos de calidad del servicio. Algunas de ellas son:

Rendimiento
Seguridad
Facilidad de uso
Confiabilidad
Solidez

Puede incluir algunos de estos requisitos en las descripciones de casos de uso concretos. Otros requisitos no son específicos de los casos de uso y resulta más eficaz incluirlos en un documento independiente. Siempre que pueda, le resultará útil ajustarse al vocabulario definido en el modelo de requisitos. En el ejemplo siguiente, observe que las principales palabras que se utilizan en el requisito son los nombres de los actores, casos de uso y clases de las ilustraciones anteriores:

Si un Restaurante elimina un Elemento del menú mientras que un Cliente está Pidiendo un menú, cualquier Elemento del pedido que haga referencia a ese Elemento del menú aparecerá en rojo.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Información más detallada acerca de cómo registrar los requisitos de calidad del servicio	Guidelines for Defining Quality of Service Requirements
Adjuntar documentos adicionales a los casos de uso	Cómo: Vincular un caso de uso a documentos y diagramas
Cómo desarrollar código que se ajuste a los requisitos de calidad del servicio	Modelar la arquitectura de un sistema de Software

Mostrar el flujo de trabajo entre los usuarios y el sistema

Puede utilizar un diagrama de actividades para mostrar el flujo de trabajo entre los diferentes casos de uso. Normalmente, resulta útil comenzar un modelo de requisitos dibujando un diagrama de actividades en el que se muestren las principales tareas que realizan los usuarios (tanto dentro del sistema como fuera de él).

Por ejemplo:

Actividad con tres acciones y un bucle.

Puede dibujar diagramas de casos de uso y diagramas de actividades para mostrar vistas diferentes de la misma información. El diagrama de casos de uso resulta más eficaz para mostrar el anidamiento de las acciones menores dentro de una actividad mayor, pero no para mostrar el flujo de trabajo. Por ejemplo:

Casos de uso para acciones anteriores

Tenga en cuenta que también puede utilizar diagramas de actividades para describir los algoritmos en el software, aunque cuando utilice los diagramas para el proceso de negocio, se concentrará en las acciones que están visibles fuera del sistema.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Más información acerca de cómo definir los flujos de trabajo de negocio	Diagramas de actividades UML: Instrucciones
Elementos de un diagrama de actividades	Diagramas de actividades UML: Referencia
Cómo desarrollar código a partir de los diagramas de actividades	Modelar la arquitectura de un sistema de Software

Mostrar las interacciones entre los usuarios y el sistema

Puede utilizar un diagrama de secuencia para mostrar el intercambio de mensajes entre los actores del sistema y los actores externos o entre componentes del sistema. De este modo, obtendrá una vista de los pasos de un caso de uso en el que se mostrará con total claridad la secuencia de interacciones. Los diagramas de secuencia resultan especialmente útiles cuando hay diferentes componentes que interactúan en un caso de uso y también cuando el sistema tiene una API.

Por ejemplo:

Diagrama de secuencia con sistema y actores.

Una ventaja de los diagramas de secuencia es que resulta fácil ver qué mensajes entran en el sistema que se está desarrollando. Para diseñar el sistema, puede reemplazar la única línea de vida Sistema por una línea de vida diferente para cada uno de sus componentes y mostrar después las interacciones que se producen entre ellos en respuesta a cada mensaje entrante.

En los temas siguientes se proporciona más información:

Para obtener información acerca de	Vea
Más información acerca de cómo definir las interacciones	Diagramas de secuencia de UML: Instrucciones
Elementos de un diagrama de secuencia	Diagramas de secuencia UML: Referencia
Cómo desarrollar código a partir de diagramas de secuencia	Modelar la arquitectura de un sistema de Software

Usar un modelo para reducir las inconsistencias

Al crear un modelo, normalmente se produce una significativa reducción de las inconsistencias y ambigüedades de los requisitos de los usuarios. A menudo, las partes interesadas tienen visiones distintas del mundo empresarial en que trabaja el sistema. Por tanto, su primera tarea será resolver estas diferencias entre sus clientes.

Descubrirá que de forma natural surgirán muchas preguntas acerca del dominio del negocio mientras crea un modelo. Al trasladar estas preguntas a los usuarios, reducirá la necesidad de realizar cambios en una etapa posterior del proyecto. A continuación, le mostramos algunas preguntas que puede hacerse y, si no encuentra una respuesta clara, puede trasladarlas a las partes interesadas del negocio:

Para cada clase del modelo de requisitos, pregunte "¿Qué caso de uso crea instancias de esta clase?" Por ejemplo, en un servicio de pedido de comida en línea, podría preguntar, "¿Qué caso de uso crea instancias de la clase Menú del restaurante?" Esto podría iniciar un debate acerca de cómo se suscribe un nuevo restaurante al servicio y cómo este restaurante puede contribuir con su menú. Puede plantearse preguntas similares acerca de qué elementos crean o modifican atributos y asociaciones.
En cada caso de uso del modelo de requisitos, intente describir el resultado o la condición posterior del caso de uso con las palabras que se utilizan en los diagramas de clases. Normalmente, resulta útil mostrar el efecto de un caso de uso dibujando instancias de las clases antes y después de una incidencia del caso de uso. Por ejemplo, si la condición posterior del caso de uso dice: "un elemento del menú se agrega al pedido del cliente", trace las instancias de las clases Pedido y Elemento del menú. Muestre los efectos del caso de uso, como un nuevo vínculo o un nuevo objeto, en un color diferente o en un nuevo dibujo. Generalmente, esto iniciará un debate sobre la información que es necesaria en el modelo. Aunque las clases de requisitos no tienen relación directa con la implementación, describen la información que el sistema necesitará almacenar y transmitir.
Pregúntese por las restricciones de los atributos y las asociaciones, especialmente por las restricciones que implican a más de un atributo o asociación.
Pregúntese por las secuencias correctas e incorrectas de los casos de uso y dibuje un diagrama de secuencia o actividades para representarlas.

Al examinar las relaciones entre las vistas que proporcionan los diferentes diagramas, podrá reconocer fácilmente los principales conceptos con los que trabajan los usuarios, lo que le ayudará a saber qué es lo que estos usuarios necesitan del sistema. También le permitirá comprender mejor los requisitos que las partes interesadas tienen menos claros. Plantéese la posibilidad de desarrollar esas características, al menos de un modo simplificado, en una etapa inicial del proyecto para que los usuarios puedan experimentar con ellas.