Introducción

Todos los sistemas son raramente pensados para todas las personas. Frecuentemente, se intenta hacer estos, tal que sean generosos y resultan en sistemas complejos.

Por consiguiente, los participantes del proyecto y los stakeholders deben colaborar para desarrollar una solución que maximice el beneficio de los stakeholders y cumpla con las restricciones planteadas en el proyecto. Lograr un balance es un proceso dinámico porque si los stakeholders y los participantes del proyecto aprenden más acerca del sistema, entonces sus prioridades y restricciones cambian.

Para tener éxito, los stakeholders y los participantes del proyecto deben converger en un acuerdo y entendimiento claros de estos tres factores:

• El problema a resolver
• Plantear las restricciones del equipo de desarrollo (costos, cronograma, recursos, regulaciones)
• Plantear las restricciones sobre la solución

Colectivamente, estos tres elementos representan los requisitos para el desarrollo del sistema. El desafío para todos los participantes del proyecto es crear una solución que maximice el valor entregado a los stakeholders, sujeto a las restricciones. El balance se refiere a hacer los críticos intercambios de costo-beneficio entre las característica deseadas y las subsecuentes decisiones de diseño que definen la arquitectura del sistema.

Descubrir el punto de equilibrio es desafiar, evadir y continuar, porque el punto de equilibrio es dinámico. Como el sistema evoluciona, los stakeholders necesitan cambiar, aparecen nuevas oportunidades, los riesgos son resueltos, nuevos riesgos aparecen y el equipo de desarrollo descubre nuevas realidades sobre el sistema. Los cambios suceden a través del ciclo de desarrollo. Por consiguiente, los stakeholders y los desarrolladores deben estar preparados para reevaluar los compromisos, restablecer las espectativas y ajustar los planes de acuerdo a como el sistema evoluciona.

Prácticas 

La siguiente sección describe las prácticas asociadas con estos principios.

Conozca su audiencia 

Usted no puede saber cómo hacer los intercambios eficaces si usted no conoce los stakeholders y lo que ellos realmente quieren.

Por consiguiente, conozca sus stakeholders. Mejor aún, trabaje cercanamente con ellos para asegurarse que usted conoce sus necesidades. Empiece por identificar todos los stakeholders y entonces mantenga una comunicación abierta y frecuente entre ellos y el grupo de desarrollo.

Separe el problema de la solución 

Frecuentemen, nosotros nos encontramos precipitadamente con una solución sin entender el problema. Despues de todo, a nosotros nos enseñaron a resolver problemas, no cómo definirlos para que sea más facil. Sin embargo, esto limita nuestra comprensión del problema, impone restricciones artificiales y hace difícil equilibrar los intercambios o incluso cuáles son esos intercambios.

Por consiguiente, es seguro que usted entiende el problema antes de que defina la solución. Al separar claramente el problema (lo que el cliente necesita) de la solución (lo que el sistema debe hacer), es más fácil de mantener el enfoque apropiado y más fácil de ajustar maneras alternativas de resolver el problema.

Therefore, make sure that you understand the problem before you define the solution. By clearly separating the problem (what the customer needs) from the solution (what the system must do), it is easier to maintain the proper focus and easier to accommodate alternate ways of solving the problem.

Crear una comprención compartida del dominio

Los expertos del dominio frecuentemente tienen experticia técnica limitada; los desarrolladores, arquitectos y probadores frecuentemente tienen experticia en el dominio limitada; y revisores y otros stakeholders frecuentemente tienen tiempo limitado para entregarse al proyecto y aprender el dominio del problema. Como resultado, las personas frecuentemente tienen un entendimiento pobre o inconsistente del dominio del problema, lo cual causa problemas de comunicación e incrementa la probabilidad de hacer una entrega de poco valor a los stakeholders.

Por consiguiente, refuerce y comparta con todos el entendimiento de las partes del dominio. Una entendimiento conciso y compartido del dominio del problema mejora la comunicación y efectividad del proyecto. Empiece definiendo el problema en el documento de la Visión. Cuando incrementa el entendimiento, captura conceptos claves del dominio y la terminología en el Glosario puede asegurar un uso del lenguaje del dominio consistente y compartido.

Use escenarios y casos de uso para capturar requisitos

Muchas compañias todavía documentan los requisitos como una lista de instrucciones declarativas, que a veces se llama el "shall statement". Estas listas son frecuentemente dificiles de entender por los stakeholders, debido  a que estos requieren que el usuario final lea a traves de ellos y traduzca mentalmente la lista a una visualización de como los requisitos interactuarán con el sistema.

Por sonsiguiente, use escenarios y casos de uso para capturar los requerimientos funcionales en una forma que sea fácil de enternder por los stakeholders. Los requisitos no funcionales, tales como desempeño, estabilidad, o requisitos de usabilidad son importantes y pueden ser documentados en los Requerimientos de Soporte, usando las técnicas tradicionales.

Establezca y mantenga el acuerdo sobre las prioridades

Tomar decisiones pobres al decidir el proximo desarrollo, puede resultar en esfuerzos inútiles, desarrollar capacidades que nunca serán usadas o popiciar problemas posteriores en el proyecto que resultan en retrasos e incluso el fracaso del proyecto.

Por consiguiente, priorice los requisitos para implementar trabajando regularmente con los stakeholders durante la evolución del producto. Elija lo que aumenta valor y reduce riesgos, mientras construye un sistema que puede evolucionar.

Haga el intercambio para maximizar valor

Los intercambios de costo-beneficio no se hacen independientes de la arquitectura. Los requisitos establecen los beneficios del sistema para los stakeholders, mientras que la arquitectura establece el costo. El costo de un beneficio puede influir en la percepción de los stakeholders del valor del beneficio. 

Por consiguiente, trabaje con los stakeholders y diseñadores para priorizar requisitos y desarrollar arquitecturas candidatas para implementar esas soluciones. Use las arquitecturas candidatas para evaluar el costos de los beneficios. Las soluciones candidatas son consideradas a un alto nivel para determinar la viabilidad arquitectónica. Las diferentes perspectivas arquitectónicas pueden resultar en diferentes valoraciones del costo versus beneficio. La arquitectura candidata que provea el más amplio cubrimiento al menor costo es seleccionada para ser desarrollada.

Maneje el alcance 

El cambio es inevitable. Aunque el cambio presenta oportunidades para mejorar el valor para los stakeholders, cambios sin restricciones resultarán en un sistema gordo, deficiente y con las necesidades de los stakeholders insatisfechas.

Por consiguiente, maneje los cambios mientras mantiene los acuerdos con los stakeholders. Los procesos modernos siempre administran los cambios, continuamente adaptan los cambios al entorno y las necesidades de los stakeholders, evaluando el impacto de los cambios, haciendo intercambios y volviendo a priorizar el trabajo. Las expectativas de los stakeholders y diseñadores deben ser realistas y encaminadas a lo largo del ciclo de vida del desarrollo.

Saber cuando parar

Un sobre-diseño de un sistema no solamente gasta recursos sino que también conduce a un sistema extremadamente complejo.

Por consiguiente, pare de diseñar el sistema cuando se alcanza la calidad deseada. Recuerde que "La calidad es la conformidad de los requisitos” [CRO79]. Esto es los que dá un sentido de completitud a la práctica. Separe el problema de la solución, asegurando que lasolución hace, de hecho, que se resuelva el problema. Despues de que los requisitos críticos son implementados y validados, el sistema esta listo para la aceptación de los stakeholders.