Requisitos del usuario del modelo

Visual Studio le ayuda a comprender, analizar y comunicar las necesidades de los usuarios dibujando diagramas sobre sus actividades y la parte que desempeña el sistema para ayudarles a lograr 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.

Para ver qué versiones de Visual Studio admiten cada tipo de modelo, consulte Compatibilidad de versiones con herramientas de arquitectura y modelado.

Un modelo de requisitos le ayuda a:

• Céntrese en el comportamiento externo del sistema, independientemente de su diseño interno.

• Describa las necesidades de los usuarios y las partes interesadas con mucha menos ambigüedad que en lenguaje natural.

• Defina un glosario coherente de términos que pueden usar los usuarios, desarrolladores y evaluadores.

• Reduzca las brechas e incoherencias en los requisitos.

• Reduzca el trabajo necesario para responder a los cambios de requisitos.

• Planee el orden en el que se desarrollarán las características.

• Use los modelos como base para las pruebas del sistema, lo que hace una relación clara entre las pruebas y los requisitos. Cuando cambian los requisitos, esta relación le ayuda a actualizar las pruebas correctamente. Esto garantiza que el sistema cumpla los nuevos requisitos.

Un modelo de requisitos proporciona una mayor ventaja si lo usa para centrar los debates con los usuarios o sus representantes y volver a revisarlo al principio de cada iteración. No es necesario completarlo en detalle antes de escribir código. Una aplicación de trabajo parcial, aunque sea muy simplificada, generalmente constituye la base más estimulante para el debate de los requisitos con los usuarios. El modelo es una manera eficaz de resumir los resultados de esas discusiones. Para obtener más información, consulte Uso de modelos en el proceso de desarrollo.

Nota:

En estos temas, "sistema" significa el sistema o la aplicación que está desarrollando. Puede ser una gran colección de muchos componentes de software y hardware; o una sola aplicación; o un componente de software dentro de un sistema más grande. En todos los casos, el modelo de requisitos describe el comportamiento visible desde fuera 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. Al crear estas vistas, es mejor cambiar con frecuencia de una a otra. Puede empezar desde cualquier vista.

Diagrama o documento	Lo que describe en un modelo de requisitos	Section
Diagrama de clases conceptuales	Glosario de tipos que se usan para describir los requisitos; los tipos visibles en la interfaz del sistema.
Documentos o elementos de trabajo adicionales	Criterios de rendimiento, seguridad, facilidad de uso y confiabilidad.	Descripción de la calidad de los requisitos de servicio
Documentos o elementos de trabajo adicionales	Restricciones y reglas no específicas de un caso de uso determinado	Mostrar reglas de negocios

Tenga en cuenta que la mayoría de los tipos de diagrama se pueden usar para otros fines. Para obtener información general sobre los tipos de diagrama, consulte Creación de modelos para la aplicación.

Mostrar reglas de negocio

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

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

Las reglas de negocio dinámicas restringen las secuencias de eventos permitidas. Por ejemplo, se usa un diagrama de secuencia o actividad para mostrar que un usuario debe iniciar sesión antes de realizar otras operaciones en el sistema.

Sin embargo, muchas reglas dinámicas se pueden declarar de forma más eficaz y genérica reemplazandolas por reglas estáticas. Por ejemplo, podría agregar un atributo booleano "Logged In" a una clase en el modelo de clase conceptual. Agregarías el estado de Iniciar sesión como condición posterior del caso de uso de inicio de sesión y lo agregarías como condición previa de la mayoría de los demás casos de uso. Este enfoque le permite evitar definir todas las posibles combinaciones de secuencias de eventos. También es más flexible cuando necesita agregar nuevos casos de uso al modelo.

Tenga en cuenta que la elección aquí es sobre cómo definir los requisitos y que esto es independiente de cómo implementar los requisitos en el código del programa.

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

Para obtener información sobre	Read
Cómo desarrollar código que cumpla las reglas de negocios	Modelar la arquitectura de la aplicación

Descripción de los requisitos de calidad de servicio

Hay varias categorías de requisitos de calidad de servicio. Incluyen lo siguiente:

• Performance

• Security

• Usability

• Reliability

• 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 se escriben de forma más eficaz en un documento independiente. Cuando se puede, resulta útil cumplir el vocabulario definido por el modelo de requisitos. En el ejemplo siguiente, observe que las palabras principales usadas en el requisito son los títulos de actores, casos de uso y clases de las ilustraciones anteriores:

Si un restaurante elimina un elemento de menú mientras un cliente está ordenando una comida, cualquier elemento de pedido que haga referencia a ese elemento de menú se mostrará en rojo.

Consulta Modelar la arquitectura de la aplicación para aprender a desarrollar código que cumpla los requisitos de calidad de servicio.

Contenido relacionado

• Uso de modelos en el proceso de desarrollo
• Modelar la arquitectura de la aplicación