NOTA: Para cambiar la imagen de esta dispositiva, seleccione la imagen y elimínela. A continuación haga clic en el icono Imágenes en el marcador de posición e inserte su imagen. UNIDAD II Análisis de requerimientos 2.2 Análisis de Requerimientos

Características Completos: Tanto el cliente como el desarrollador deben revisarlos para asegurar que no tienen errores. Deben ser consistentes: Dos requerimientos son inconsistentes cuando es imposible satisfacerlos simultáneamente. Deben estar completos: El conjunto de requerimientos está completo si todos los estados posibles, cambios de estado, entradas, productos y restricciones están descritos en alguno de los requerimientos. Deben ser realistas: Todos los requerimientos deben ser revisados para asegurar que son posibles.

Características ¿Cada requerimiento describe algo que es necesario para el cliente? Los requerimientos deben ser revisados para conservar sólo aquellos que inciden directamente en la resolución del problema del cliente. Verificables: Se deben poder preparar pruebas que demuestren que se han cumplido los requerimientos. Deben ser rastreables: ¿Se puede rastrear cada función del sistema hasta el conjunto de requerimientos que la establece?

El Proceso de Ingeniería de Requerimientos Estudio de Factibilidad Análisis de Requerimientos Definición de Requerimientos Especificación de Requerimientos Reporte de Factibilidad Modelos del Sistema Documento de Requerimientos Definición de Requerimientos Especificación de Requerimientos

Estudio de viabilidad [Sommerville, 2005] define el estudio de viabilidad como un estudio corto y orientado a resolver las siguientes preguntas: 1.¿El sistema contribuye a los objetivos generales de la organización o empresa? 2.¿El sistema se puede implantar utilizando tecnología actual dentro de las restricciones de tiempo y presupuesto? 3.¿El sistema puede integrarse a otros sistemas existentes en la empresa?

Estudio de viabilidad (Ejemplo de preguntas) ¿Cómo se las arreglaría la organización o empresa si no se implantara el sistema? ¿Cuáles son los problemas con los procesos actuales y como ayudaría un sistema nuevo a aliviarlos? ¿Cuál es la contribución directa que hará el sistema a los objetivos y requerimientos del negocio? ¿Se puede obtener y transferir la información a otros sistemas de la organización? ¿El sistema requiere tecnología que no se ha utilizado previamente en la organización? ¿A que debe ayudar el sistema y a qué no necesita ayudar?

Obtención y análisis de requerimientos Revisar la situación actual. Trabajar en el ámbito del usuario para comprender el contexto, los problemas y las relaciones. Entrevistar a los usuarios actuales y potenciales. Realizar un prototipo para mostrar cómo podría funcionar el nuevo sistema. Investigar en documentos existentes. Conducir tormentas de ideas con los usuarios actuales y potenciales. Organización y sistemas existentes

Análisis de requerimientos Involucra trabajo técnico de grupo con los clientes para averiguar el dominio de la aplicación, los servicios que el sistema debe proporcionar y las restricciones operacionales propias del sistema Debe involucrar a los usuarios finales, administradores, ingenieros de mantenimiento, etc. Quienes son llamados líder especialista "ztakeholder: "

Análisis de requerimientos (conflictos) Problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema. Problemas de comprensión. Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información o por considerar que es «obvia», especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables. Problemas de volatilidad. Los requisitos cambian con el tiempo.

Análisis de requerimientos (actividades) Valorar el impacto en el negocio y la viabilidad técnica del sistema propuesto; Identificar las personas que ayudarán a especificar requisitos y contrastar su papel en la organización; Definir el entorno técnico (arquitectura de computación, sistema operativo, necesidades de telecomunicaciones) en el sistema o producto a desarrollar e integrar; Identificar «restricciones de dominio» (características específicas del entorno de negocio en el dominio de la aplicación) que limiten la funcionalidad y rendimientos del sistema o producto a construir;

Análisis de requerimientos (actividades) Definir uno o más métodos de obtención de requisitos (entrevistas, grupos de trabajo, equipos de discusión); Solicitar la participación de muchas personas para que los requisitos se definan desde diferentes puntos de vista, asegurarse de identificar lo fundamental de cada requisito registrado; Identificar requisitos ambiguos como candidatos para el prototipado, y Crear escenarios de uso para ayudar a los clientes/usuarios a identificar mejor los requisitos fundamentales.

Análisis de Requerimientos

Preguntas que deben ser contestadas durante el análisis ¿Cada requisito es consistente con los objetivos generales del sistema/producto? ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? Es decir, ¿algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa? ¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema? ¿Cada requisito está delimitado y sin ambigüedad?

Preguntas que deben ser contestadas durante el análisis Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o específico) conocido para cada requisito? ¿Existen requisitos incompatibles con otros requisitos? ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto? ¿Se puede probar el requisito una vez implementado?

Proceso de análisis de requerimientos

Áreas de esfuerzo El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: 1.reconocimiento del problema, 2.evaluación y síntesis, 3.modelado, 4.especificación y 5.revisión

Técnicas Especificación formal de datos Diagrama de flujo Diccionario de datos Especificación de procesos Lenguaje natural Lenguaje estructurado Tablas de decisión Árboles de decisión

Diagrama de Flujo de Datos -Proceso -Decisión -Datos -Documento -Conector -Pantalla -Terminador -Datos almacenados

Diagramas de Flujo de Datos (Un ejemplo) *Proceso de Evaluación Docente del Sistema de Gestión de Calidad en el ITSSP (2007)

Diccionario de datos

Diccionario de Datos (Ejemplos) PETICION LIBROS = {CARNET BIBLIOTECA} + FICHA LIBROS CARNET BIBLIOTECA =NUM. CARNET + APELLIDOS + NOMBRE + TIPO CARNET TIPO CARNET =[SALA | FIN DE SEMANA | COLABORADOR | PROYECTO | DOCTORADO] FICHA LIBROS = {LIBROS} LIBROS = SIGNATURA + TITULO + AUTOR CARNET BIBLIOTECA = NUM. CARNET + APELLIDOS + NOMBRE + TIPO CARNET + (NUMERO TELEFONO)

Lenguaje natural Es el lenguaje hablado o escrito por humanos para propósitos generales de comunicación. Son aquellas lenguas que han sido generadas espontáneamente en un grupo de hablantes con propósito de comunicarse, a diferencia de otras lenguas, como puedan ser una lengua construida, los lenguajes de programación o los lenguajes usados en el estudio de la lógica formal, especialmente la lógica matemática.

Lenguaje estructurado

Tablas de decisión

Arboles de decisión

NOTA: Para cambiar la imagen de esta dispositiva, seleccione la imagen y elimínela. A continuación haga clic en el icono Imágenes en el marcador de posición e inserte su imagen. UNIDAD II Análisis de requerimientos 2.3 Casos de Uso

Definición y características Definición: Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado Están basado en el lenguaje natural, es decir, es accesible por los usuarios

Casos de Uso - Notación

Casos de Uso - Actores Son los usuarios del sistema. En realidad son categorías o tipos de usuario. Son entidades externas que interactúan con el sistema para conseguir un objetivo. Son de distintos tipos. Principales: personas que usan el sistema Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados Otros sistemas: sistemas con los que el sistema interactúa

Casos de Uso - Actores La misma persona física puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeñado Los casos de uso son lo que sucede cuando el actor interactúa con el sistema El actor usa el sistema para conseguir un objetivo Al registrar todas las formas en que el sistema se usa (Casos de Uso) acumulamos todos los objetivos o requerimientos del sistema.

Casos de Uso - Actores Preguntas que ayudan a encontrar Actores: ¿ Quién está interesado en cierto requisito ?. ¿ Dónde en la organización se utiliza el sistema ?. ¿ Quién proveerá, utilizará y eliminará del sistema esta información ?. ¿ Quién utilizará esta función ?. ¿ Quién le dará soporte y mantenimiento al sistema ?. ¿ Usa el sistema un recurso externo ? ¿ Qué actores necesita este caso de uso ? ¿ Desempeña un actor varios roles? ¿ Hay actores que desempeñan el mismo rol ?

Casos de Uso – Casos de Uso Preguntas que ayudan a encontrar Casos de Uso: ¿ Cuáles son las tareas de determinado actor ?. ¿ El actor, creará, guardará, cambiará, eliminará o leerá información en el sistema ?. ¿ Qué caso de uso, creará, guardará, cambiará, eliminará o leerá esta información ?. ¿ Necesitará el actor informar al sistema sobre cambios externos imprevistos ?. ¿ Es necesario que el actor esté informado sobre ciertas ocurrencias del sistema ?.

Casos de uso - relaciones Comunicación: Relación entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado

Casos de uso - relaciones Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

Casos de uso - relaciones Extensión : el caso de uso origen extiende el comportamiento del caso de uso destino.

Casos de uso - Ejemplos

Casos de Uso - Documentación Caso de Uso: nombre del caso de uso. Actores: lista de actores en la que se indica quien inicia el caso de uso. Tipo: que puede ser Primario, Secundario u Opcional, entre otros. Descripción: repetición del caso de uso de alto nivel o alguna síntesis similar.

Casos de Uso - Documentación TIPOS DE CASOS DE USO 1 (PRIMARIOS, SECUNDARIOS, OPCIONALES) Casos primarios de uso: representan los procesos comunes más importantes. Casos secundarios de uso: representan procesos menores o raros. Casos opcionales de uso: representan procesos que pueden no abordarse TIPOS DE CASOS DE USO 2 (ESENCIALES, REALES) Casos esenciales de uso: son casos expandidos que se expresan en forma teórica y que contiene poca tecnología y pocos detalles de implementación. Las decisiones de diseño se posponen y se abstraen de la realidad. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción. Casos reales de uso: describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías específicas de entrada, salida, etc.

Casos de Uso - Documentación La estructura del formato expandido agrega a la de alto nivel lo siguiente: Propósito: intención del caso de uso. Referencias Cruzadas: caso de uso y funciones relacionadas con el sistema. Curso Normal de los Eventos: es la parte medular del formato expandido; describe detalles de la conversión interactiva entre los actores y el sistema. Un aspecto esencial de la sección es explicar la secuencia más común de eventos: la historia normal de las actividades y el termino exitoso de un proceso. No incluye situaciones alternativas. Cursos Alternativos: describe importantes opciones o excepciones que pueden presentarse en relación al curso normal. Si éstas son complejas se pueden expandir y convertir en nuevos casos de uso.

Casos de Uso - Documentación