Un stakeholder (SH) Es un individuo que se ve afectado materialmente por los resultados del sistema, o los proyectos que están construyendo dicho sistema.
Está interesado en el éxito del proyecto.
Algunos ejemplos son: los usuarios finales y el equipo de desarrollo.

[Siguiente:: Categorías de actores]

Tipos de stakeholders

• Usuarios
  • Serán los actores dentro del sistema
• Sponsors
  • Invierten en la producción del proyecto, pero no lo usarán directamente
• Desarrolladores
• Autoridades
  • Expertos en el dominio del problema o solución
• Clientes
  • La gente/organización que adquiere el sistema final

Representación de los stakeholders y sus roles

• Se debe definir un conjunto de roles de stakeholders, para reclutar un conjunto de representantes que se involucren directamente en el proyecto.
• Definir los roles indica a los SH su compromiso en el proyecto.

El rol de los SH y los SH representantes

• Los SH son los dueños del problema, y la fuente principal de requerimientos
• La documentación de las requisitos es una formalización de las metas de los SH
• El rol del SH debe, entre otras cosas:
  • Representar las visiones y necesidades de la comunidad de SH que representa
  • Tener un rol activo
  • Revisar los requerimientos
  • Asistir a reuniones
  • Investigar
  • Defender el proyecto ante los demás SH

El stakeholder usuario

• Es esencial tener un perfil de cada tipo de usuario para entender las habilidades, actitudes, idioma, etc.
• Muchas veces es imposible involucrar a todos los usuarios. Lo que sí es esencial es que el conjunto de SH representantes incluya a los usuarios representativos, y que para cada tipo de usuario haya una representación definida.

Stakeholders y el modelado de Casos de uso

• En algunos CU habrá metas secundarias que no afectan a los usuarios, pero son de interés para los stakeholders, como cuando se deben generar y enviar reportes
• Por esto recordamos, que los SH que representan a los usuarios no son los únicos que definen requerimientos

Involucrar a los SH y usuarios en el proyecto

1. Identificar a los SH y a los tipos de usuario

• Puede haber muchos SH. Empecemos por identificar los tipos de SH involucrados
• Información del tipo de stakeholder
  • Nombre del tipo
  • Descripción breve
  • Representante (referenciar el rol o roles aplicables)
• Información del tipo de stakeholders usuarios
  • Características (ambiente físico/social, números)
  • Competencias

2. Identificar y reclutar a los stakeholders representantes

• Ahora hay que reclutar SH representantes que participarán en el proyecto, especialmente quienes se involucren en modelar los CU
• Primero definimos los roles y responsabilidades
• Información del rol de SH
  • Nombre
  • Descripción breve: El rol típicamente representa uno o más tipos de usuarios
  • Responsabilidades en el proyecto
  • Compromiso: Cómo se ven involucrados

3. Involucrar a los stakeholders en el proyecto

• En este paso se usan a los SH como fuentes de información y se les hace participar en el desarrollo, mediante diversas actividades:
  • Entrevistas, cuestionarios
  • Grupos de foco, comités de consultarías, talleres
  • Revisiones

Comenzar el proyecto

1. Crear visión compartida
   • Todas las partes deben tener el mismo entendimiento del problema a resolver
2. Analizar el problema
   • Se debe definir bien el problema que el cliente sufre
   • Es útil usar una Declaración del problema

Entender el problema

• Necesidades (del stakeholder): Un reflejo del problema que debe ser encarado para justificar el nuevo sistema
  • Cada necesidad de un SH debe justificarse
• Características (del nuevo sistema): Son las capacidades de alto nivel
  • Para complementar el modelo de CUs, se crea una vista de requerimientos de alto nivel
  • El conjunto de características da un resumen de los beneficios del nuevo sistema
  • Pueden ser funcionales o no funcionales
  • Son puntuales a cada versión y atienden necesidades urgentes
    • En cambio, los CU son generalmente estables entre versiones y muestran la funcionalidad completa del sistema

Comenzar a documentar

• Cada característica debe identificarse y describirse

• Las características se documentan de forma general, evitando enfocarse en la implementación

• Tambien incluir como características no funcionales cualidades que no sean cruciales para el sistema, sino para el rendimiento, usabilidad, manejo de errores, escalabilidad, etc.

• Otros requerimientos del producto, los enfocados al ambiente operativo y restricciones, deben documentarse separadamente de las características principales

• Restricciones: Son restricciones ajenas a las capacidades del desarrollo del software, como:

  • económicas: costos, disponibilidad, números de licencias
  • de ambiente
  • técnicas: qué stack tecnológico se va a usar para el proyecto
  • de sistema
  • de calendario y recursos: fechas límite y manejo de recursos de hardware
  • Estas restricciones pueden ser puestas por los SH debido a políticas de empresa o normas organizacionales

• Requerimientos operativos: Si la solución se despliega, el entorno donde va a correr necesita cumplir estos requerimientos

  • Cosas como los requerimientos del sistema (SO, Memoria, ancho de banda)
  • Cosas como el ambiente del hardware (temperatura, humedad) y del software (manejos de error, recuperación de fallos, ambiente del usuario final)

Completando la vista general del producto

• Para tener la vista completa del producto, pueden ser necesarios otros aspectos no capturados por los requerimientos de alto nivel
• Puede ser útil documentar:
  • Síntesis de capacidades a los usuarios
  • Beneficios a los clientes, y qué características los hacen cumplir
  • Suposiciones y dependencias
  • Alternativas y competencia, con sus puntos débiles y fuertes

Documento de visión

• Es el documento que resume los detalles clave del proyecto: las necesidades del SH, metas y objetivos, ambientes de usuario, plataformas objetivo, características del producto
• Provee:
  • Una base de alto nivel (a veces contractual) para los requerimientos técnicos
  • Un vehículo para el inicio de la retroalimentación con el cliente
  • Un punto para establecer el alcance y prioridad de las características del producto
• Debe ser entendible por mucha gente de conocimientos distintos, por lo que debe ser general el nivel de detalle
• Secciones:
  • Posicionamiento (Oportunidad de negocio, declaración del problema, demografías, ambientes de usuario)
  • Stakeholders y usuarios
  • SH clave y necesidades del usuario
  • Vista general del producto
  • Características, otros requerimientos del producto

Actores

Encontrar los actores

• & Recordar que los tipos de usuarios se definen por competencias y capacidades, mientras que los actores se definen por metas y relaciones con el sistema
• Es fácil encontrar a los actores que representan personas
  • Ver qué gente usará el sistema, luego generalizar para identificar los roles que interpretan

1. Identificar los actores primarios: aquellos que realmente usarán el sistema
   • Trabajar desde lo específico a lo general
2. Identificar a los actores de soporte: aquellos que reciben y procesan información o toman decisiones, apoyando al caso de uso
3. Considerar la información de requerimientos existentes y establecer relaciones
   • Tipos de usuario - Actores: Hay actores definidos para cubrir todos los tipos de usuarios?
   • Stakeholders - Actores: Hay suficientes actores para representar las interacciones requeridas por todos los SH?
   • Roles de SH - Actores: Sabe cuál SH representante estará validando las decisiones hechas sobre cada definición de actor?
   • Características: Quién está interesado en esta capacidad?
4. Incluir a otros sistemas que intervengan en el proceso de nuestro sistema
   • & Recordar que los actores no siempre son personas
   • Representar a sistemas externos como actores ayuda a definir lo que nuestro sistema hará y lo que no; el límite del sistema
   • Un sistema externo puede comportarse de dos formas:
     • como actor: Si es necesario para comunicarse con otro sistema y la comunicación afecta el flujo de eventos
       • " Rule of Thumb: Si no puedes controlarlo, es un actor
     • como dispositivo: Si el sub-sistema es un componente controlado por el gran sistema/el diseñador para mover info. de un lado al otro
5. Identificar fuentes de información
   • Si, para cierto actor, el sistema no cuenta con la información suficiente para manejar alguno de sus eventos, algún actor (probablemente nuevo) deberá proveerla

Documentar los actores

• Nombrar a los actores: El nombre debe describir el rol que el actor interpreta en el sistema, o alternativamente, sus responsabilidades en él
• No confundir actores con roles organizacionales/cargos laborales
• No generalizar demasiado
  • ~ ???
• Describir brevemente los actores: Capturando las responsabilidades del sistema y estableciendo las metas del actor
• Caracterizar los actores: Las características de un actor pueden definir cómo funciona el sistema, y pueden incluir:
  • Alcance de la responsabilidad
  • Ambiente físico del actor
  • Número y tipo de usuarios representado por el actor
  • La frecuencia con la que el actor usará el sistema