El objetivo principal del procedimiento Determinar el alcance es acotar el sistema que vamos a construir. Esta acotación se refiere a diversos aspectos del proyecto,

• Por una parte establecer los límites del sistema a construir, qué forma parte del proyecto y qué no.
• Por otra parte determinar otros sistemas con los que va a estar relacionado y con los que tendrá que comunicarse (Interfaces).
• Determinar qué personas están interesadas en el proyecto y de qué forma van a intervenir en el.
• Determinar las características de alto nivel, funcionales y no funcionales, del sistema a construir.
• Identificar restricciones de cualquier tipo (normativas, legales, tecnológicas, etc.)

El principal instrumento que utilizaremos para conseguir este objetivo es desarrollar un DocumentoDeVisión en el que recogeremos toda esta información.

El Analista de requisitos es la persona responsable de determinar el alcance del proyecto.

Las principales técnicas para obtener el documento de visión y los requisitos de producto y de cliente consisten en realización de entrevistas, estudio de sistemas anteriores y estudio de documentación asociada.

1.- Celebra una primera reunión con el Cliente

Envíale previamente un orden del día realizado con la plantilla OrdenDelDia. Sigue las instrucciones acerca de cómo nombrar el documento de órden del día y dónde debes guardarlo. Los puntos a abordar en el órden del día de esta primera reunión con el cliente son:

• Expertos y usuarios del cliente a intervenir en el proyecto. Perfiles y responsabilidades.
• Problemas de la aplicación actual que quieren resolverse en la nueva.
• Principales características de la nueva aplicación.
• Posibles restricciones de la solución a adoptar
• Otros requisitos del producto.

No te ciñas exclusivamente a los expertos, intenta involucrar también a los usuarios del sistema y ten encuenta que existirán distintos perfiles de usuarios.

Elabora el acta de la reunión

Para realizar el acta utiliza la plantilla Acta. Sigue las instrucciones acerca de cómo nombrar el acta y dónde debes guardarlo. Envíala a los participantes para su aprobación. OjO Por cada reunión da de alta un Jira:

Clona esta tarea en Jira por cada uno de los participantes y asignale las horas que duró la reunión.

1. Que el Jefe de Proyecto dé por cerrada la tarea una vez se apruebe el acta de la reunión.

No deseches la revisión de sistemas previos que puedan estar funcionando y que tu software va a sustituir. Examina tanto el software como la documentación técnica y de usuario que pueda existir. Te ayudará a tener una mejor comprensión del sistema.

El estudio de otros sistemas “de la competencia” también puede resultar interesante.

OjO Cada uno de los Ingenieros de Requisitos participantes en esta tarea DEBE crear un JIRA con los siguientes datos, y registrar las horas de trabajo en ella:

Iniciar la creación de un nuevo Documento de Visión.

1. Apartados 1.- Introducción, 1.1.- Objetivos, 1.2.- Ámbito y 1.3.- Referencias

Rellenalos tal y como indica en la plantilla del documento de visión.

La intención de este primer apartado es definir claramente el sistema a construir, qué subsistemas lo componen, con qué otros puede estar relacionado y qué documentos debemos tener en cuenta. Toda esta información se especificará con mucho más detalle en el resto del documento de visión.

Los interesados se dividen en dos categorías principales, expertos y usuarios.

• Los expertos son aquellos que mejor conocen el sistema que estamos estudiando y que han de definir el software a construir.
• Los usuarios son aquellos que van a utilizar el software a construir y que conocen de manera suficiente las necesidades que ha de satisfacer el software para que ellos puedan desarrollar su trabajo de manera eficaz y eficiente.

1. Apartado 2 del VIS.

Este apartado nos servirá para reconocer a los principales expertos y usuarios que nos ayudarán a definir las principales características del software a construir.

Para cada experto indica:

• Cuál es el principal interés del experto en el desarrollo del sistema, por ejemplo, velar por que se cumple una legislación, definir el catálogo de procesos o las principales funcionalidades que han de contemplarse en el software
• Qué tareas van a realizar durante la construcción del software; de qué manera van a involucrarse para que cumplan con sus responsabilidades durante el desarrollo del proyecto
• Quién es la persona, con nombre y apellidos, que va a adoptar el rol de experto en el proyecto -para cada tipo de experto-.

Si una determinada persona participa en el proyecto por ser un usuario avanzado y va a determinar la parte del proyecto en que es experto no lo incluyas en el apartado de expertos, sino en el de usuarios.

Para cada usuario indica:

• Qué tipo de experto lo va a representar.
• Cuál es su responsabilidad en el sistema, qué parte del proyecto es la que conoce mejor y va a participar activamente en su definición.
• Qué tipo de tareas va a realizar durante la construcción del software; de qué manera va a involucrarse para que cumpla con sus responsabilidades para con el proyecto.

1. Apartado 4.1 del VIS

Identifica otros sistemas con los que el nuestro tenga relación. Identifica las principales interaces de comunicación entre sistemas. Dibuja un diagrama de bloques o de componentes si es necesario.

1. Apartado 3 del VIS

Identifica los principales problemas que ha de resolver tu sistema. Para cada uno de los problemas identificados indica quiénes se ven afectados por el problema, de qué manera y cuál es la solución que ellos proponen para solventar el problema.

Los problemas recogidos aquí han de ser de alto nivel, no pequeños problemillas. El identificar estos problemas de alto nivel, los de mayor importancia para los usuarios, nos ayudará a desarrollar un software más útil para ellos y a enfocar la construcción del software en resolver los problemas de los usuarios.

1. Apartado 4.2 del VIS

Identifica los principales beneficios que el software va a proporcionar a usuarios y expertos. Identifica las características que ha de satisfacer el software para conseguir esos beneficios. Este apartado está íntimamente relacionado con el apartado 3.

1. Apartado 5 del VIS

Identifica las características funcionales de alto nivel del producto, necesarias para conseguir los beneficios necesarios para el usuario. Estas características que especifiques aquí se implementarán más adelante como casos de uso, o historias o el tipo de documento de requisitos funcional que sea adecuado en cada caso.

El nivel de detalle debe ser lo bastante general como para que los expertos y usuarios puedan comprenderlo y a la vez lo suficientemente detallado para que el equipo de análisis obtenga la información necesaria para comenzar a trabajar sobre los requisitos funcionales. Hay que centrarse en qué características se necesitan y en el por qué, no en el cómo, han de ser implementadas.

Cada una de las características debe ser percibida por los usuarios u otros sistemas externos. Estas características deben incluir una descripción de la funcionalidad y cualquier cuestión relevante de usabilidad que deba tenerse en cuenta.

Evita diseñar. Mantén la descripción de la característica a nivel general. Céntrate en qué capacidades se necesitan y por qué, no en cómo deben ser implementadas.

Para una mejor comprensión del documento de visión puedes agrupar las características en módulos de la aplicación.

Codifica cada una de las características comenzando el párrafo correspondiente con VIS-XXX, donde VIS indica que es un requisito de visión -alto nivel- y XXX es un ordinal.

1. Apartado 4.3 del VIS

Si existe algún requisito propio del entorno en el que funcionará la aplicación, recójase aquí.

1. Apartado 4.4 del VIS

Identifica los requisitos de instalación de la aplicación. Si la aplicación es Web en principio no tendrá, pero puede ser que necesite algún tipo de librería en el cliente, como por ejemplo el applet de firma electrónica de la UMU.

1. Apartado 7.1 del VIS

Indica la configuración mínima que debe tener un cliente, o el servidor, para poder ejecutar el sistema desarrollado. Si la aplicación es Web bastaría con indicar las recomendaciones de navegación

1. Apartado 7.2 del VIS

Indica los estándares aplicables al proyecto. Omite en este apartado los relativos a:

• Facilidad de uso
• Fiabilidad
• Mantenimiento
• Rendimiento
• Seguridad

que ya tiene sus apartados específicos

1. Apartado 7.3 del VIS

Una lista de los requisitos y estándares a los que debe ajustarse el producto referidos a la usabilidad y accesibilidad. Por defecto hará referencia a la Normativa de Accesibilidad, Usabilidad y Experiencia de Usuario

1. Apartado 7.4 del VIS

Una lista de los requisitos y estándares a los que debe ajustarse el producto referidos a la fiabilidad. Como mínimo recoge la obligatoriedad del control de errores y la obligatoriedad de gestionar las trazas tal y como indica el apartado “Manejo de Trazas” de la Normativa de desarrollo de aplicaciones FundeWeb

1. Apartado 7.5 del VIS

Una lista de los requisitos y estándares a los que debe ajustarse el producto referidos al mantenimiento de la aplicación. Como mínimo debe hacer referencia al estilo de codificación del lenguaje Java. Si la aplicación incluye código PL/SQL también debe hacerse referencia a las normas de codificación del código PL/SQL

1. Apartado 7.6 del VIS

Si la aplicación tiene requisitos de rendimiento específicos deben ser consignados en este apartado. Los requisitos de rendimiento se especificarán en base a tiempos de respuesta y número de conexiones simultáneas.

1. Apartado 7.7 del VIS

Una lista de los requisitos y estándares a los que debe ajustarse el producto referidos al mantenimiento de la aplicación. Como mínimo debe seguir la Normativa de Seguridad aplicable en ÁTICA. Como evidencia de que se cumple la normativa de seguridad aplicable en ÁTICA se cumplimentará la plantilla de control de requisitos de seguridad para cada una de las partes de la aplicación que tengan requisitos de seguridad diferentes; de forma que se adjuntará al menos una instancia de la citada plantilla, a la documentación de gestión del proyecto de la aplicación. Más info en la Sección sobre Seguridad de la Wiki del Programador.

1. Apartado 8 del VIS

Indica los requisitos relevantes en cuanto a la documentación que ha de proporcionarse con el software. La documentación puede incluir manual de usuario, Ayudas en línea y guías de configuración o instalación.

• NOTAS:
  • XXX: Código del proyecto.
  • yyyymmdd: corresponde a un número con el año, mes y día en formato numérico
  • 1.2.3: Número de version del documento.
  • Descripción: corresponde con una breve descripción del asunto de la reunión

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.GestionProyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja REQ.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Determinar el alcance

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Cuenta el número de reuniones realizadas

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Determinar el alcance
• Label = REUNION

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-REQ-Determinar el alcance
• Label = VIS

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

1. Contar el número de requisitos de visión que se han obtenido en el documento de Visión.

1. Entra en el Documento de visión. En la opción de menú Archivo → Propiedades … → Estadísticas. Réstale 4 páginas al valor que te resulte. Esto es por las páginas de portada que son las mismas siempre.

1. Resultante a partir de las dos métrica anteriores. Se calcula automáticamente.