Casos de Abuso, Parte 4: Resumen ejecutivo

Recapitulemos. Tenemos una lista corta de escenarios en donde estamos usando mal los casos de uso como instrumentos para identificar, organizar, documentar y administrar requisitos de software, tanto funcionales como no funcionales.

Estos son los casos enumerados hasta el momento:

1.    El caso de uso es la única documentación necesaria para construir el software.

Impacto en la calidad: Alto.

2.    El caso de uso se usa en todos los casos.

Impacto en la calidad: Bajo.

3.    Lo que no está documentado en los casos de uso no hace parte del sistema.

Impacto en la calidad: Medio.

4.    El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.

Impacto en la calidad: Medio.

Entonces, ya sabemos que la especificación de requisitos de software (ERS) viene, o puede aparecer, en recipientes de distintos tamaños y diferentes formas y colores: algunos son cacharros escuetos pero con significado y suficiencia para quien los elabora y para los interesados en los mismos, otros son cristalerías sofisticadas que se aproximan a lo mundano, en el sentido de cosmopolita. Pero contienen requisitos de software, al fin y al cabo.

En términos de artefactos de especificación y modelado de sistemas de información, estoy hablando de folios de especificación funcional, con sus requisitos en prosa y todo el detalle aledaño que siempre los acompaña; pero también me refiero a la descripción de procesos del negocio, desde macro-procesos, hasta tareas simples y atómicas, pasando por procesos y subprocesos; representaciones de herramientas visuales como prototipos estáticos y simuladores.

También hago alusión a diagramas de UML, como  diagramas de actividad y de estado, diagramas de procesos, diagramas de contexto y mapas mentales, entre algunos otros; descripción de reglas y políticas del negocio; acuerdos de entendimiento entre los usuarios y el área de tecnología; listas de deseos escritas a mano; y, las más usadas, historias de usuario y casos de uso. Incluso, con las nuevas tecnologías, los requisitos de software bien pueden aparecerse en formato de videos o audios digitales, fotografías de alta definición capturadas por teléfonos inteligentes, mensajes electrónicos y trinos de 140 caracteres o menos.

Usualmente, la ERS se exhibe en una combinación de dos o más de estos instrumentos y lo único que importa es que provenga de las personas apropiadas e interesadas en el producto de software y que cada requisito cumpla o pueda cumplir con algunos atributos o rasgos de calidad:

·         Claridad

·         Atómicidad

·         Precisión

·         Verificabilidad

·         Necesidad u oportunidad

·         Priorización

La ERS, por su parte, debe ser:

·         Independiente de diseño

·         Completa

·         Consistente

·         Rastreable

·         Modificable / Extensible

Ahora ya sabemos cómo corregir algunos de esos defectos. ¿Ustedes qué creen?

Salud@s.