1. Construir el sistema por partes
1.1. El sistema se debería construir por partes, cada una de las cuales tiene un valor claro para sus usuarios.
1.1.1. Dividir los casos de uso
1.1.2. Elegir la porcion más importante
1.1.2.1. Cuando se va a implementar una porción, es necesario entender el impacto que la porción tendrá en el diseño y en la implementación del sistema.
1.1.3. Se estima el desarrollo en equipo.
2. Entregar el sistema en incrementos
2.1. La mayoría de los sistemas de software evolucionan a lo largo de muchas generaciones, no se producen de una sola vez, sino que se construyen como una serie de versiones
2.1.1. Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se hizo antes.
2.1.1.1. Los diagramas de casos de uso, al mostrar cuales casos de uso se van a tratar en esta versión y cuales casos de uso se relegarán hasta una versión posterior, constituyen una gran herramienta para ilustrar las metas del equipo.
3. Adaptarse para cubrir las necesidades del equipo
3.1. Desafortunadamente, no hay una solución “única” para todos los desafíos del desarrollo de software
3.1.1. Equipos diferentes y situaciones diferentes requieren estilos diferentes y niveles diferentes de detalle.
3.2. Sin importar cuales prácticas y técnicas se seleccionan, es necesario asegurarse de que estas son lo suficientemente adaptables para cubrir las necesidades actuales del equipo.
3.2.1. Los Casos de Uso 2.0 se diseñaron con esto en mente y son tan livianos como se requiera que sean.
4. Los Casos de Uso 2.0 conducen el desarrollo de un sistema ayudándole, en principio, a entender cómo se empleará el sistema y luego ayudándole a evolucionar un sistema apropiado que apoye a los usuarios.
4.1. los Casos de Uso 2.0 son:
4.2. Livianos
4.3. Escalables
4.4. Versátiles
4.5. Fáciles de usar
5. Mantenerlos simples al narrar historias
5.1. Los casos de uso capturan las metas del sistema.
5.1.1. Para entender un caso de uso narramos historias.
5.2. Proporcionan una forma de identificar y capturar todas las historias diferentes, pero relacionadas de una manera simple, aunque detallada.
5.2.1. Esto posibilita que los requisitos del sistema se capturen, compartan y entiendan fácilmente.
6. Entender el panorama general
6.1. Tomar las decisiones correctas acerca de lo que incluye el sistema, lo que estará por fuera, lo que costará y el beneficio que proporcionará.
6.2. Crear algo que resuma el sistema deseado y permita entender el alcance y el progreso a nivel del sistema.
6.2.1. Un diagrama de casos de uso es una forma simple de presentar una visión general de los requisitos de un sistema.
6.2.1.1. Los interesados que usan el sistema y contribuyen al logro de las metas se modelan como actores. Las formas en las que se usará el sistema para alcanzar estas metas se modelan como casos de uso.
6.2.1.1.1. Permite definir rápidamente el alcance del sistema (lo que está incluido y lo que no) y da al equipo un panorama de lo que hará el sistema.
7. Enfocarse en el valor
7.1. Solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se empleará el sistema que en las largas listas de funciones o características que ofrecerá.
7.2. Los casos de uso encierran muchas formas de usar el sistema: aquellas que alcanzan exitosamente las metas del sistema y aquellas que manejan los problemas que pueden ocurrir.
7.2.1. Flujo básico
7.2.1.1. El flujo básico es necesario si el caso de uso se va a completar exitosamente en algún momento; este flujo básico se debe implementar primero.
7.2.2. Flujos alternativos
7.2.2.1. Las alternativas son opcionales y se pueden agregar al flujo básico a medida que se requieran.