ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS

Presentación del tema: "ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS"— Transcripción de la presentación:

1 ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS
Fundamentos de Ingeniería de Software ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS Asignatura: Fundamentos de Ingeniería del Software Curso Actualización : 2006 Profesor: Ernesto Gómez Vargas Facultad de Ingenieria Universidad Distrital Francisco José de Caldas

2 Qué son Requerimientos?
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar unobjetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

3 Qué son Requerimientos?
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

4 Características de los requerimientos
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación.

5 Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

6 Requerimientos Construir software de alta calidad, en tiempo y presupuesto estimados. Planear el proyecto y los recursos que se usarán en él. Especificar el tipo de verificaciones que se habrán de realizar al sistema Planear la estrategia de prueba a la que habrá de ser sometido el sistema Son el fundamento del ciclo de vida del proyecto.

7 Características de un requerimiento
Los requerimientos deben ser: Especificados por escrito. Como todo contrato o acuerdo entre dos partes Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo sabemos si cumplimos con él o no? Deben tener como fundamento las necesidades de los usuarios actuales o potenciales del sistema. Descritos como una característica del sistema a entregar. Esto es: Que es lo que el sistema debe de hacer (y no como debe de hacerlo) Lo más claro y conciso posible. Para evitar malas interpretaciones.

8 COMO REALIZAR EL ANÁLISIS DE REQUERIMIENTOS
Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre si. Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante la clasificación, estructuración y organización de todo lo que el sistema debe de hacer.

9 ANÁLISIS DE REQUERIMIENTOS (1)
1) Obtener información por diferentes medios de lo que los usuarios desean y dejar escritas esas necesidades 2) Clasificar esas necesidades para poder estructurar los requerimientos o necesidades del sistema.

10 ANÁLISIS DE REQUERIMIENTOS (2)
3) Identificar los niveles de jerarquía del sistema y empezar a alojar los requerimientos en el nivel que les corresponda. 4) Especificar los requerimientos de acuerdo al nivel de audiencia que se requiera 5) Especificar completamente cada necesidad, sin ahorrar tiempo y espacio en su descripción.

11 ANÁLISIS DE REQUERIMIENTOS (3)
6) Entender correctamente las necesidades y cuando afecten dos o mas usuarios, para llegar a acuerdos entre las partes. 7) Manejar las expectativas y estar dispuesto a realizar cambios.

12 ANÁLISIS DE REQUERIMIENTOS (4)
8) Involucrar a todos los que tengan inherencia en el proyecto (Jefes, subalternos, usuarios en general) 9) Se debe mantener una perfecta comunicación entre todos quienes participan en el proceso de levantamiento de los requerimientos

13 COMO OBTENER INFORMACIÓN (1)
Los requerimientos son el punto de acuerdo entre el usuario y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de los usuarios.

14 COMO OBTENER INFORMACIÓN (2)
Si los requerimientos se enfocan a describir las necesidades del usuario, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el usuario o recabando documentación que describa la manera que el usuario desea que funcione el sistema de software.

15 COMO OBTENER INFORMACIÓN (3)
Formato 01 RELACION BASICA DE REQUERIMIENTOS Responsable de la dependencia Información recopilada por Nombre de la dependencia NUMERO FECHA DESCRIPCION FUNCIONARIO 01 02 03 04

16 COMO OBTENER INFORMACIÓN (4)
Las necesidades y/o requerimientos del usuario evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del usuario, así como cada revisión o cambio que se haga a esta documentación. Para poder establecer o estimar el costo de un proyecto es necesario contar con los requerimientos iniciales en su mejor nivel de detalle

17 COMO OBTENER INFORMACIÓN (5)
Como cada necesidad del sistema de información es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuales de ellas serán satisfechas por el software que se quiere desarrollar y cuales por algún otro producto del sistema.

18 TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE REQUERIMIENTOS (1)
1) Un problema puede surgir de la diferencia entre las cosas como se realizaron y como se desean. Por eso es necesario tener en cuenta que en el proceso de levantamiento o búsqueda de requerimientos se pueden presentar problemas que es necesario solucionar.

19 TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE REQUERIMIENTOS (2)
2) Para solucionar el problema se deben tener en cuenta: a.  Generar acuerdo entre las partes involucradas b.  Construir un vocabulario común c.  Identificar los involucrados d.  Definir los límites del sistema e.  Identificar restricciones F. Dejar todo claro y definido en un documento.

20 TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE REQUERIMIENTOS (3)
Manejar diferentes técnicas de levantamiento a.  Entrevistas b.     Encuestas c.      Talleres de requerimientos d.     Lluvia de ideas Prototipos f Escenerario

21 TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE REQUERIMIENTOS (4)
4) Mecanismos de fácil comunicación Durante el proceso se debe facilitar la comunicación entre todos los participantes, de tal forma que todos los usuarios puedan participar aportando sus puntos de vista y sus necesidades. 5) Se debe realizar una especificación formal de todos los acuerdos con las diferentes personas, para que quede constancia expresa de que se tuvieron en cuenta los puntos de vista de los diferentes usuarios.

22 TOPICOS BÁSICOS PARA REALIZAR EL LEVANTAMIENTO DE REQUERIMIENTOS (5)
6) Administrar los cambios. Se debe estar presto a realizar las modificaciones que se presenten durante el proceso de análisis de requerimientos. Después puede ocasionar costos o demoras en el proceso de desarrollo.

23 RESUMEN (1) Para avanzar en esta fase preliminar se deben realizar en resumen las siguientes actividades. Analizar la situación de cada una de las dependencias teniendo en cuenta la participación de todos y cada uno de los involucrados en los procesos. Generar acuerdo entre los involucrados si hay diferencias, de tal forma que se trabaje en el mismo sentido.

24 RESUMEN (2) Hacer el proceso de análisis de requerimientos, utilizando técnicas como las descritas, teniendo en cuenta especialmente quién usa o va a utilizar el sistema. Especificar completamente los requerimientos, en forma escrita y clara para cada una de las dependencias, sin omitir posibles o potenciales usuarios.

25 RESUMEN (3) Controlar el alcance, para que se pueda limitar el proyecto. Comunicar a todos los usuarios acerca de que se está adelantando el proceso de levantamiento de los requerimientos, mediante encuestas, etc. Según se mencionó anteriormente. Almacenar en archivos de bases de datos preferiblemente los requerimientos, de tal forma que se puedan procesar fácilmente.

26 RESUMEN (4) Los errores en el proceso de obtención de requerimientos son de los mas costosos por eso es importante tener cuidado en este proceso. Por último los requerimientos deben ser: No ambiguos, concretos, completos y consistentes.

27 ANALISIS DE REQUERIMIENTOS
Formato 02 ANALISIS DE REQUERIMIENTOS Numero: 01 Nombre del requerimiento Escena 1: Papeles Escena 2: Utensilios Escena 3: Condiciones de entrada Escena 4: Condiciones de salida Escena 5:

28 Formato 03 LISTADO DE ACTORES NUMERO ACTOR (ROL) USUARIO COMENTARIO 01

29 Ingenieria de Requerimientos
DEFINICION: El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. A continuación se darán algunas definiciones para ingeniería de requerimientos. "Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979. "Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones".

30 Beneficios de la Ingeniería de Requerimientos:
Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). Mejora la comunicaion entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto

31 MUCHAS GRACIAS