Implementar requisitos

Los requisitos describen lo que las partes interesadas esperan del producto. Los requisitos deben formularse de modo que faciliten el debate con las partes interesadas, utilizando el vocabulario y los conceptos propios del ámbito empresarial. Los requisitos no deben abordar ni depender de la implementación. Los requisitos no solo incluyen las expectativas de los usuarios en materia de comportamiento y calidad de servicio sino también las restricciones estatutarias y los estándares empresariales.

El registro de los requisitos en Visual Studio Team Foundation Server mediante el elemento de trabajo de requisito ofrece las siguientes ventajas:

• Permite comprobar si se han cumplido los requisitos vinculándolos a los casos de prueba.

• Permite supervisar el progreso de la implementación de los requisitos vinculándolos a los elementos de trabajo de tarea.

• Permite organizar los requisitos en requisitos globales y requisitos más detallados para administrarlos más fácilmente y para que se pueda resumir la información en los informes de progreso.

• Permite modelar los requisitos en Visual Studio Ultimate, vinculándolos a los elementos del modelo en Team Foundation Server.

En este tema, no se intenta reproducir la gran cantidad de literatura disponible sobre la determinación de los requisitos. En su lugar, se centra en los aspectos que son importantes para utilizar las herramientas de Visual Studio de una manera que se ajusta a CMMI. Para obtener más información sobre CMMI, vea Información general de CMMI.

Al igual que cualquier actividad de desarrollo, las actividades que se describen en este tema no se deben realizar en un orden estricto. Desarrolle un modelo de dominio mientras escribe escenarios porque una actividad ayudará a mejorar la otra. Desarrolle los escenarios cuando se aproxime el momento de su codificación. Incluya la experiencia obtenida con código escrito y probado en los escenarios pendientes de implementación.

En este tema

Cuándo desarrollar los requisitos

Escribir una visión

Escribir escenarios

Modelar el ámbito empresarial

Desarrollar los requisitos de calidad de servicio

Revisar los requisitos

Validación

Inspeccionar y editar los requisitos

Cuándo desarrollar los requisitos

Team Foundation Server admite el trabajo iterativo y esta práctica es más eficaz cuando las iteraciones tempranas se utilizan para obtener comentarios de los posibles usuarios y otras partes interesadas. Esta información se puede utilizar para mejorar los requisitos que se han enunciado para futuras iteraciones. Esto contribuye a crear un producto que sea mucho más eficaz en su última instalación que un producto desarrollado en el mismo período sin ningún tipo de prueba por parte del usuario. Si el proyecto representa solo uno de los muchos componentes de un programa, la integración temprana con los demás componentes permite a los arquitectos mejorar el producto global.

Esta flexibilidad debe sopesarse frente a la necesidad de proporcionar un firme compromiso al cliente o a los socios de proyectos paralelos.

Por consiguiente, hasta cierto punto, los requisitos se desarrollan y se perfeccionan a lo largo de todo el proyecto. Dado que es probable que los requisitos detallados cambien durante el proyecto, resulta inútil determinarlos íntegramente antes de que se produzca la implementación adecuada.

• En la iteración 0, se desarrolla un conjunto de requisitos que describen las principales características, con un nivel de detalle suficiente para elaborar un plan del producto. En este plan, se asignan los requisitos a las iteraciones y se indican los requisitos que se habrán cumplido al final de cada iteración. Se crea un modelo de dominio de los principales conceptos y actividades y se define el vocabulario que se va a usar para esos conceptos en las conversaciones con los usuarios y en la implementación. Se deben determinar requisitos amplios que engloben todas las características, como la seguridad y otros requisitos en materia de calidad de servicio.

• Al comienzo de cada iteración, o cuando esta se aproxima, se desarrollan más detalladamente los requisitos correspondientes a esas características. Se determinan los pasos que los usuarios deben seguir con ayuda de diagramas de actividades o diagramas de secuencia. Se define lo que sucede en casos excepcionales.

• Se han de comprobar todos los requisitos implementados con tanta frecuencia como sea posible. Los requisitos ubicuos, como la seguridad, se deben comprobar con pruebas para cada nueva característica. Si es posible, se deben automatizar las pruebas porque las pruebas automáticas se pueden realizar de manera continuada.

Administrar los cambios en los requisitos

Las siguientes instrucciones indican cómo llevar a cabo un proceso incremental y cómo supervisarlo para que se cumplan los requisitos de CMMI.

• No cambie los requisitos establecidos para una iteración. En el caso excepcional de que se produzca un cambio abrupto en las circunstancias, es posible que haya que cancelar una iteración, revisar el plan del producto e iniciar una nueva iteración.

• Identifique las incertidumbres en los requisitos. Intente organizar el plan de modo que la experiencia del usuario en las iteraciones tempranas aporte información que reduce las incertidumbres.

• Utilice los elementos de trabajo de solicitud de cambio a fin de registrar las solicitudes para cambiar el comportamiento implementado, a menos que la mejora solicitada ya forme parte del plan. Vincule cada solicitud de cambio a los correspondientes elementos de trabajo de requisito. Para obtener más información, vea Solicitud de cambio (CMMI).

• Revise las solicitudes de cambio cuando revise el producto antes de cada iteración. Examine el impacto de la solicitud sobre los proyectos dependientes y los usuarios y calcule el costo que supone realizar cambios en el código. Si se acepta una solicitud de cambio, actualice el requisito.

• Actualice las pruebas de modo que se ajusten a los cambios realizados en los requisitos.

• Designe una fecha límite (por ejemplo, después de la iteración 2 ó 3) después de la cual se han de justificar mucho más los cambios en los requisitos. Si el proyecto va destinado a un cliente de pago, esta es la fecha en la que el cliente debe aprobar un conjunto básico de requisitos y pasar del pago por hora a un precio fijo.

• Utilice los elementos de trabajo de error para registrar el comportamiento implementado que no se ajuste a los requisitos explícitos o implícitos. Si es conveniente, cree una nueva prueba que detecte el error.

Escribir una visión

Hable con el equipo sobre la visión y muéstrela en el portal web del proyecto de Team Foundation Server.

Una visión es un breve resumen de lo que va a aportar el producto. ¿Qué podrán hacer los usuarios que antes no podían? La visión ayuda a aclarar el ámbito del producto.

Si el producto ya existe, se debe escribir una visión para la versión en cuestión. ¿Qué podrán hacer los usuarios del producto que antes no podían?

Escribir escenarios

Trabaje junto con el cliente y las demás partes interesadas para crear los escenarios y defínalos como elementos de trabajo de requisito estableciendo el campo Tipo de requisito en Escenario.

Un escenario o caso de uso es una descripción de una secuencia de eventos, muestra cómo se logra un objetivo concreto y, normalmente, implica la interacción entre las personas u organizaciones y los equipos.

Asígnele un título descriptivo que lo diferencie claramente de los demás escenarios de una lista. Asegúrese de que se indiquen los principales actores y de que su objetivo sea claro. Un ejemplo de un buen título sería:

El cliente compra una comida.

Se podrá escribir un escenario de las siguientes maneras. A veces, resulta útil hacerlo de varias formas:

• Una o dos frases en la descripción del elemento de trabajo:

  Un cliente realiza un pedido de comida en un sitio web y paga con una tarjeta de crédito. El pedido se pasa a un restaurante, que prepara y entrega la comida.

• Pasos numerados en la descripción del elemento de trabajo:

  Un cliente visita el sitio web y crea un pedido para una comida. El sitio web redirige al cliente a un sitio para realizar el pago. Se agrega el pedido a la lista de trabajo del restaurante. El restaurante prepara y entrega la comida.

• Guión gráfico. Un guión gráfico es básicamente una tira de dibujos en la que se refleja el relato. Se puede dibujarlo en PowerPoint. Adjunte el archivo del guión gráfico al elemento de trabajo de requisito o cárguelo en el portal del equipo y agregue un hipervínculo al elemento de trabajo.

  Un guión gráfico es sobre todo útil para mostrar las interacciones con el usuario. Sin embargo, para un escenario empresarial, se recomienda utilizar un estilo boceto que indique claramente que no se trata del diseño final de la interfaz de usuario.

• Documentos de los requisitos. En los documentos de los requisitos, se puede proporcionar el nivel de detalle apropiado para cada requisito. Si opta por utilizar documentos, cree un documento de Word para cada requisito y adjúntelo al elemento de trabajo de requisito, o bien, cargue el archivo en el portal del equipo y agregue un hipervínculo al elemento de trabajo.

• Diagrama de secuencia UML (Unified Markup Language). Un diagrama de secuencia es sobre todo útil en los casos en los que interactúan varias entidades. Por ejemplo, para poder realizar un pedido de comida, el cliente, el sitio web de DinnerNow, el sistema de pago y el restaurante tienen que interactuar en una secuencia concreta. Dibuje el diagrama de secuencia en un modelo UML, compruébelo en Team Foundation Server y agregue un vínculo al elemento de trabajo de requisito. Para obtener más información, vea Diagramas de secuencia de UML: Instrucciones.

Escenarios específicos

Escriba escenarios específicos con un conjunto determinado de actores en una secuencia concreta. Por ejemplo, "Carlos pide una pizza y pan de ajo en el sitio web de DinnerNow. El sitio web redirige a Carlos al servicio de pago de Woodgrove Bank. Fourth Coffee prepara la pizza y hace la entrega."

Los escenarios específicos ayudan a imaginarse el sistema que se usa y son sobre todo útiles cuando se explora una característica por primera vez.

Asimismo, puede resultar útil crear roles que faciliten datos y describan otras actividades de las personas y organizaciones. Carlos duerme al raso y utiliza un cibercafé; Wendy vive en una urbanización privada; Sanjay pide comida para su mujer en su trabajo; Contoso tiene una cadena de 2.000 restaurantes en todo el mundo; Fourth Coffee está en manos de una pareja que realiza las entregas en bicicleta.

Escenarios más genéricos en términos de "un cliente", "un plato del menú", etc. pueden resultar más prácticos pero es menos probable que conduzcan a la identificación de características útiles.

Niveles de detalle

En la iteración 0, escriba algunos escenarios importantes con cierto nivel de detalle, pero escriba la mayoría de los escenarios en forma de esquema. Cuando se aproxime una iteración en la que se va a implementar parcial o totalmente un escenario concreto, agregue más detalles.

Cuando considere un escenario por primera vez, puede resultar útil describir el contexto empresarial, incluso los aspectos en los que el producto no interviene. Por ejemplo, describa el método de entrega de DinnerNow: ¿cada restaurante organiza sus propias entregas o DinnerNow cuenta con un servicio de entrega? Las respuestas a esas preguntas aportan un contexto útil al equipo de desarrollo.

En los escenarios más detallados que se desarrollan al comienzo de una iteración, se pueden describir las interacciones con la interfaz de usuario; en los guiones gráficos, se puede mostrar el diseño de la interfaz de usuario.

Organizar los escenarios

Los escenarios se pueden organizan de las siguientes maneras:

• Dibujando diagramas de casos de uso en los que se muestra cada escenario como un caso de uso. Se recomienda este método porque facilita en gran medida la presentación y el debate en torno a los escenarios. Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.

  • Vincule cada caso de uso al elemento de trabajo que defina el escenario. Para obtener más información, vea Cómo: Vincular elementos de trabajo con elementos de modelo.

  • Dibuje relaciones de extensión para reflejar que un escenario es una variación de otro. Por ejemplo, "El cliente especifica direcciones de pago y de entrega diferentes" es una extensión del caso de uso básico "El cliente realiza un pedido". Las extensiones son sobre todo útiles para apartar los escenarios que se van a implementar en una iteración posterior.

  • Dibuje relaciones de inclusión para separar un procedimiento como "El cliente inicia sesión", que comparten varios casos de uso.

  • Dibuje relaciones de generalización entre los escenarios generales como "El cliente paga" y las variantes concretas como "El cliente paga mediante tarjeta".

• Cree vínculos primario-secundario entre los elementos de trabajo del escenario en Team Foundation Server. Puede ver la jerarquía en Team Explorer. Para obtener más información, vea Organizar los requisitos en un plan de producto.

Modelar el ámbito empresarial

Cree un modelo UML que describe los principales conceptos y actividades que intervienen en el uso del producto. Utilice los términos que se definen en este modelo como "lenguaje ubicuo" en los escenarios, las conversaciones con las partes interesadas, la interfaz de usuario, los manuales de usuario y en el propio código.

Muchos de los requisitos no los especifica explícitamente el cliente y, para comprender los requisitos implícitos, es necesario entender el ámbito empresarial, es decir, el contexto en el que va a funcionar el producto. Por consiguiente, parte del trabajo ligado a la recopilación de los requisitos en un ámbito desconocido consiste en conocer ese contexto. Una vez recabado este tipo de información, se podrá utilizarlo en varios proyectos.

Guarde el modelo en el sistema de control de versiones.

Para obtener más información, vea Crear modelos de los requisitos de los usuarios.

Modelar los comportamientos

Dibuje diagramas de actividades para resumir los escenarios. Utilice calles para agrupar las acciones realizadas por los diferentes actores. Para obtener más información, vea Diagramas de actividades UML: Instrucciones.

Un escenario normalmente describe una secuencia concreta de eventos pero un diagrama de actividades muestra todas las posibilidades. Dibujar un diagrama de actividades puede llevarle a pensar en secuencias alternativas y a preguntarles a los clientes qué debería suceder en esos casos.

En la ilustración siguiente, se muestra un ejemplo sencillo de un diagrama de actividades.

Cuando el intercambio de mensajes es importante, quizás sea más eficaz usar un diagrama de secuencia que incluya una línea de vida para cada actor y componente principal del producto.

Los diagramas de casos de uso permiten resumir los diferentes flujos de actividad admitidos por el producto. Cada nodo del diagrama representa una serie de interacciones entre los usuarios y la aplicación a fin de lograr un objetivo concreto. Asimismo, se pueden incluir secuencias comunes y extensiones opcionales en nodos de caso de uso independientes. Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.

En la ilustración siguiente, se muestra un ejemplo sencillo de un diagrama de casos de uso.

Modelar los conceptos

Dibuje diagramas de clases de dominio para describir las entidades importantes y las relaciones que se mencionan en los escenarios. Por ejemplo, en el modelo de DinnerNow figuran Restaurante, Menú, Pedido, Plato de menú, etc. Para obtener más información, vea Diagramas de clases de UML: Instrucciones.

Etiquete los roles (extremos) de las relaciones con nombres y cardinalidades.

En un diagrama de clases de dominio, no se suelen adjuntar las operaciones a las clases. En el modelo de dominio, los diagramas de actividades describen el comportamiento. La asignación de las responsabilidades a las clases del programa forma parte del desarrollo.

En la ilustración siguiente, se muestra un ejemplo sencillo de un diagrama de clases.

Restricciones estáticas

Agregue a los diagramas de clases las restricciones por las que se van a regir los atributos y relaciones. Por ejemplo, los platos de un pedido deben proceder todos del mismo restaurante. Este tipo de reglas son importantes para el diseño del producto.

Coherencia del modelo

Asegúrese de que el modelo y los escenarios sean coherentes. Uno de los usos más eficaces de un modelo es la resolución de ambigüedades.

• En las descripciones de los escenarios se utilizan los términos que se definen en el modelo y son coherentes con las relaciones definidas. Si en el modelo se define el término plato, en los escenarios no se deben usar el término producto para hacer referencia a lo mismo. Si en el diagrama de clases se muestra que un plato pertenece exactamente a un menú, en los escenarios no se debe mencionar que varios menús comparten el mismo plato.

• En cada escenario, se describe una serie de pasos permitidos por los diagramas de actividades.

• En los escenarios o en las actividades, se describe cómo crear y destruir cada clase y cada relación en el diagrama de clases. Por ejemplo, ¿en qué escenario se crea un plato? ¿Cuándo se destruye un pedido?

Desarrollar los requisitos de calidad de servicio

Cree elementos de trabajo que especifiquen los requisitos de calidad de servicio. Establezca el campo Tipo de requisito en Calidad de servicio.

Entre los requisitos de calidad de servicio o requisitos funcionales se encuentran el rendimiento, la facilidad de uso, la confiabilidad, la disponibilidad, la integridad de datos, la seguridad, la asequibilidad, la capacidad de servicio, la capacidad de actualización, la capacidad de entrega, la capacidad de mantenimiento, el ajuste y el acabado.

Tenga en cuenta cada una de estas categorías para cada escenario.

El título de cada requisito de calidad de servicio debe reflejar su definición mediante un contexto, una acción y una medición. Por ejemplo, se podría crear el siguiente requisito: "Al realizar una búsqueda en el catálogo, se deben devolver los resultados en menos de tres segundos".

Además, es útil incluir más detalles para explicar por qué es necesario el requisito. Describa por qué el rol valoraría el requisito y por qué se requiere este nivel de servicio. Proporcione un contexto y una justificación. En esta explicación se podría incluir información útil referente a la administración de riesgos, como los datos de un estudio de mercado, un grupo de enfoque del cliente o un estudio sobre la facilidad de uso; informes/vales del departamento de soporte técnico; u otra prueba anecdótica.

Vincule el requisito de calidad de servicio a cualquier escenario (elemento de trabajo de requisito) que se vea afectado por la calidad de servicio. La vinculación de los elementos de trabajo relacionados permite a los usuarios de Team Foundation Server realizar un seguimiento de los requisitos dependientes. Las consultas y los informes pueden mostrar cómo los requisitos de calidad de servicio afectan a los requisitos funcionales que se capturan como escenarios.

Revisar los requisitos

Después de escribir o actualizar los requisitos, las partes interesadas pertinentes deberán revisarlos para asegurarse de que describen adecuadamente todas las interacciones entre el usuario y el producto. Normalmente, entre las partes interesadas figuran un experto en la materia, un analista de negocios y un arquitecto de experiencia del usuario. Los escenarios también se revisan para garantizar que se pueden implementar en el proyecto sin ningún tipo de confusión ni problema. Si se detecta cualquier problema, se han de corregir los escenarios para que sean válidos al término de esta actividad.

Cree un elemento de trabajo de revisión para realizar un seguimiento de la revisión. Este elemento proporciona una prueba importante para una valoración según el método SCAMPI (Standard CMMI Appraisal Method for Process Improvement) y puede ser una buena fuente de información para un análisis futuro de las causas principales.

Revise en cada escenario las siguientes características:

• El escenario se ha escrito en el contexto de lo que deben realizar los usuarios de las tareas, de lo que ya saben y de sus expectativas con respecto a la interacción con el producto.

• El escenario describe un problema y las soluciones propuestas no impiden verlo claramente.

• Se identifican todas las interacciones pertinentes entre el usuario y el producto.

• El experto en la materia, el analista de negocios y el arquitecto de experiencia del usuario revisan cada escenario en el contexto del proyecto para validar que todos los escenarios puedan implementarse correctamente. Si un escenario no es válido, se revisa de modo que sea válido.

• El escenario se puede implementar con las técnicas, las herramientas y los recursos disponibles y según el presupuesto y la programación establecidos.

• El escenario tiene una sola y fácil interpretación.

• El escenario no entra en conflicto con otro escenario.

• El escenario puede someterse a prueba.

Validación

Planee la implementación de versiones beta del producto en su entorno de trabajo antes de la versión final. Planee la actualización de los requisitos en función de los comentarios aportados por las partes interesadas con respecto a esa implementación.

La validación significa asegurarse de que el producto se ajusta al uso previsto en su entorno operativo. En MSF for CMMI, la validación se realiza mostrando el software operativo a las partes interesadas al final de cada iteración del proyecto. La programación se realiza de modo que los comentarios facilitados a los desarrolladores en demostraciones anteriores puedan abordarse en el plan correspondiente a las iteraciones restantes.

Para lograr una auténtica validación, el producto no solo debe ejecutarse en un contexto de demostración o de simulacro sino que, en la medida de lo posible, debe someterse a prueba en condiciones reales.

Inspeccionar y editar los requisitos

El escenario y los requisitos de calidad de servicio, que conducen a la mayoría de las tareas de desarrollo, pueden inspeccionarse usando la consulta de requisitos del cliente. Si prefiere mostrar todos los requisitos, puede escribir una consulta que devuelva todos los elementos de trabajo correspondientes al tipo de elemento de trabajo de requisito. Establezca las columnas del resultado de modo que se muestre la ruta de acceso de las iteraciones. Para obtener más información, vea Consultas de equipo (CMMI).

Además de ver la consulta directamente en Team Explorer o Team Web Access, se puede abrirla en Office Excel o en Office Project. Estas herramientas se prestan más para editar y agregar elementos de trabajo como un lote. Para obtener más información, vea Trabajar en Microsoft Excel y Microsoft Project en conexión con Team Foundation Server y Realizar la planeación descendente mediante una lista de árbol de elementos de trabajo (en Excel).

El equipo debe crear la mayoría de los requisitos en las iteraciones tempranas del proyecto. Se irán creando nuevos requisitos y se irán ajustando otros a medida que se vayan recopilando comentarios de las versiones anteriores.

Recursos adicionales

Para obtener más información, vea los recursos web siguientes:

• A Practical Guide to Feature Driven Development, Stephen R. Palmer y Malcolm J. Felsing; Prentice-Hall PTR, 2002.

• Streamlined Object Modeling: Patterns, Rules and Implementation, Jill Nicola, Mark Mayfield, and Mike Abney; Prentice Hall PTR, 2001.

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler; Wiley, 2002.

• Domain Driven Design: Tackling Complexity in the Heart of Software, Eric Evans; Addison Wesley Professional, 2003.

• Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean; Addison Wesley Professional, 2002.