Requerimientos del Software

2

Importancia

► Los errores en la fase de requerimientos son los más numerosos: ▪ Boehm afirma que el 10% de los errores se producen en

la fase de requerimientos. ▪ Estudios más recientes afirman que entre el 44% y el

80% de los errores proceden de IR.

► El costo crece exponencialmente con el retraso en subsanarlo: ▪ Boehm afirma que la reparación de un error en la fase de

codificación cuesta entre 5 y 10 veces más. ▪ En la fase de mantenimiento cuesta entre 100 y 200 veces

más.

3

Costo de Correcciones a Errores

Costo de cambios

4

Estadísticas de incidencia de errores

¿Qué es un requerimiento de software?

6

Concepto de requerimiento

► El IEEE define: ▪ Requisito o Requerimiento como:

►Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo

►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

► ¿Qué hace el sistema? Y no ¿Cómo lo hace?.

7

Requerimientos

►Diferentes niveles de detalle, perspectivas y tipos de requerimientos

►De usuario ►De sistema ►De negocio ►Técnicos ►Funcionales ►No funcionales

8

Requerimientos

►De negocio ▪ Objetivos generales de la organización o los clientes

que solicitan el sistema ▪ ¿Por qué se está implementando el sistema? ▪ Visión - Alcance

9

Requerimientos

►Del usuario ▪ Objetivos del usuario ▪ Tareas que el usuario debe poder hacer con la

aplicación

►Del sistema ▪ Incluyen elementos de software, hardware e incluso

personas (subsistemas del sistema general)

Requerimientos funcionales

►Describen la funcionalidad o los servicios del sistema

►Depende del tipo de software, Los usuarios esperados y el tipo de sistema en que el software se va a usarse.

► Los requerimientos del usuario funcional pueden ser declaraciones de muy alto nivel sobre lo que el sistema debería hacer, pero los requerimientos funcionales del sistema deberían describir los servicios del sistema con detalle.

Requerimientos no funcionales

► Estos definen las propiedades y restricciones del sistema, p.Ej.: confiabilidad, tiempo de respuesta y requerimientos de almacenamiento.

► Los requerimientos también pueden ser especificados asignando sistemas CASE particulares, programando un lenguaje o desarrollando un método.

► Los requerimientos no funcionales pueden ser más críticos que los funcionales. Si estos no se cumplen, el sistema es inservible.

Clasificaciones no funcionales

► Requerimientos del producto ▪ Requerimientos que especifican que el producto entregado debe

comportarse de una manera determinada. P.Ej.: Velocidad de ejecución, confiabilidad, etc.

► Requerimientos organizacionales ▪ Requerimientos que son una consecuencia de las políticas y

procedimientos organizacionales. P.Ej.: estándares de proceso usados, requerimientos de implementación, etc.

► Requerimientos externos ▪ Los requerimientos que surgen de los factores que son externos al

sistema y su proceso de desarrollo. P.Ej.: interoperabilidad, requerimientos, requerimientos legislativos, etc.

Tipos de requerimientos no funcionales

Requerimientos de desempeño

Requerimientos de espacio

Requerimientos de utilidad

Requerimientos eficiencia

Requerimientosde fiabilidad

Requerimientos de portabilidad

Requerimientos interoperabilidad

Requerimientoséticos

Requerimientos legislativos

Requerimientos implementación

Requerimientos de estándares

Requerimientos de entrega

Requerimientos de seguridad

Requerimientos privacidad

RequerimientosDel producto

Requerimientos organizacionale

s

Requerimientos externos

Requerimientos No funcionales

14

Requerimientos

► Funcionales ▪ Especifican la funcionalidad que se debe construir –

Comportamiento

►No funcionales ▪ Estándares, regulaciones ▪ Interfaces externas, desempeño, restricciones de

diseño/implementación

15

Características de los requerimientos

► Necesario ► Conciso ► Completo ► Consistente ► No ambiguo ► Verificable

16

Dificultades para definir 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.

17

► La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

► Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

►Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.


18


► Los Stakeholders no saben lo que realmente quieren.

► Los Stakeholders expresan los requerimientos con sus propios términos

►D i f e r e n t e s s t a keho l d e r s p ueden t e n e r requerimientos conflictivos

► Los requerimientos cambian durante el proceso de análisis. Pueden surgir nuevos Stakeholders y el entorno de negocios cambia.

Guía para escribir requerimientos

►Definir un formato estándar y usarlo para todos los requerimientos.

►Distinguir entre los requerimientos deseables y obligatorios.

►Resaltar el texto para identificar partes importantes del requerimiento

► Evitar el uso de lenguaje “técnico” de computación

Documento de los requerimientos

► El documento de requerimientos es la exposición oficial de lo que se pide a los desarrolladores del sistema.

►Deber ía inc lu i r tanto la def in ic ión de los requerimientos del usuario como la especificación de los requerimientos del sistema.

►NO es un documento de diseño. Debería fijar, hasta donde sea posible, LO QUE el sistema debería hacer en lugar de CÓMO debería hacerlo.

21

Especificación de Requerimientos de Software (ERS)

►Constituye la línea de base para el diseño del producto y la referencia oficial para determinar si el producto de software es lo que el usuario solicito.

►Normalmente se trata de un documento expresado en lenguaje natural, de modo que funcione como instrumento de comunicación con el cliente y usuario

22

► Punto de vista del cliente: es una descripción comprensiva de lo que el sistema debe resolver

► Punto de vista del administrador del proyecto: es la base para asignar recursos, estimar preliminarmente esfuerzo - costo y establecer hitos del proyecto.

Papel del ERS en un proyecto

23

► Punto de vista del programador: es la “autoridad” definitiva de lo que debe hacer el sistema, no el diseño.

► Punto de vista de los ingenieros de Pruebas: es la base para construir planes de pruebas.

Papel del ERS en un proyecto

Puntos Clave

► Los requerimientos para un sistema determinan lo que debe de hacer el sistema y definen las restricciones en el funcionamiento.

► Los requerimientos funcionales son declaraciones de los servicios que el sistema debe proporcionar o son descripciones de cómo se deben de llevar a cabo algunos cálculos.

24Informática Empresarial, UCR IF 7100 Ingeniería de Software

► Los requerimientos no funcionales restringen el sistema en desarrollo y el proceso de desarrollo que se debe de utilizar.

► Los requerimientos del usuario son para el uso por la gente relacionada con la utilización del sistema, se deben de redactar con lenguaje natural, tablas y diagramas fáciles de entender.


Puntos Clave

► Los requerimientos del sistema se utilizan para comunicar de forma precisa las funciones que debe de proporcionar el sistema.

► Los documentos de requerimientos de software son la declaración acordada de los requerimientos del sistema, se debe de organizar para que lo utilicen clientes del sistema y desarrolladores del software.


Puntos Clave

¿Qué es ingeniería de requerimientos?

IF 7201 - Gestion de Proyectos de Software I 2006 28

Ingeniería de Requerimientos

► El IEEE define:

► Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definición del sistema hw/sw.

► El proceso de estudio y refinamiento de un sistema.

IF 7201 - Gestion de Proyectos de Software I 2006 29

Ingeniería de Requerimientos

► ( Zave ) ▪ Rama de la ingeniería del software que trata

con el establecimiento de los objetivos, funciones y restricciones de los sistemas software.

▪ Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer especificaciones precisas.

Procesos de ingeniería de requerimientos

► Los procesos usados para los Requerimientos varían ampliamente dependiendo del dominio de la aplicación, de las personas involucradas y de la organización que desarrolla los requerimientos.

► No obstante, hay varias actividades comunes a todos los procesos ▪ Obtención de requerimientos; ▪ Análisis de requerimientos; ▪ Validación de requerimientos; ▪ Administración de requerimientos.

30Informática Empresarial, UCR IF 7100 Ingeniería del Software

El proceso de ingeniería de requerimientos

Estudio defactibilidad

Obtención y Análisis de requerimientos

Especificación de requerimientos

Validación de requerimientos

Informe defactibilidad

Modelos de sistemas

Requerimientos del usuario y del sistema

Documento de requerimientos

Ingeniería de requerimientos

Especificación derequerimientos


Obtención de requerimientos

Modelación y especificación De los requerimientos del sistema

Obtención de requerimientos del sistema

Especificación de losRequerimientos del usuario

Obtención deRequerimientosDel usuario

Especificación de requerimientos Del negocio

Creación de prototipos

Estudio de factibilidad

revisiones

Documento de requerimientos Del sistema

Estudios de factibilidad

► Un estudio de factibilidad decide si el sistema propuesto merece o no la pena.

► un estudio corto y orientado a resolver varias preguntas ▪ si el sistema contribuye a los objetivos de la organización; ▪ Si el sistema puede ser implementado utilizando la tecnología actual

y dentro del presupuesto; ▪ Si el sistema puede integrarse con otros que ya se usan.

Factibilidad e implementación

► Basado en la valoración (lo que se necesita) de la recolección de información y redacción de un informe.

► Preguntas para las personas de la organización ▪ ¿cómo se las arreglaría la organización si no se llevase a cabo este

sistema? ▪ ¿Cuáles son los problemas con los procesos actuales? ▪ ¿cómo ayudaría el nuevo sistema a resolverlos? ▪ ¿cuáles serían los problemas de integración? ▪ ¿se necesita nueva tecnología?¿qué capacidades? ▪ ¿A qué debe ayudar el sistema?

Obtención y análisis

► A veces llamado obtención de requerimientos o descubrimiento de requerimientos.

► Implica el trabajo de personal técnico con los clientes para informarse del dominio de la aplicación, los servicios que el sistema debería proporcionar y las restricciones operacionales del sistema.

► Debe implicar a los usuarios finales, administradores, ingenieros implicados en el mantenimiento, expertos del dominio, sindicatos, etc. Todos estos son designados como stakeholders.

Espiral de los requerimientos

Organización y clasificación de los requerimientos

Negociación y priorización de requerimientos

Documentación de requerimientos

Descubrimiento de requerimientos

Actividades del proceso

► Descubrimiento de los requerimientos ▪ Interactuar con los stakeholders para descubrir sus requerimientos.

También son descubiertos los requerimientos del dominio en esta etapa.

► Organización y clasificación de los requerimientos ▪ Agrupa los requerimientos relacionados y los organiza en grupos

coherentes ► Priorización y negociación

▪ Priorizar los requerimientos y resolver los conflictos de los requerimientos.

► Documentación de los requerimientos ▪ Los requerimientos se documentan y son introducidos en la

siguiente ronda de la espiral

38

Técnicas y herramientas utilizadas en la IR

► Entrevistas y Cuestionarios ► Lluvia de Ideas (Brainstorm) ► Prototipos ► Proceso de Análisis Jerárquico (AHP) ► Administración de Requerimientos con casos de

uso

39

Técnica Ventajas Desventajas

Entrevistas y Cuestionarios

• Mediante ellas se obtiene una gran cantidad de información correcta a través del usuario.

• Pueden ser usadas para obtener un pantallazo del dominio del problema.

• Son flexibles. • Permiten combinarse con otras técnicas.

• La información obtenida al principio puede ser redundante o incompleta.

• Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.

Lluvia de Ideas • Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclaradas por expertos.

• Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.

• Es necesaria una buena compenetración del grupo participante.

Prototipos • Ayudan a validar y desarrollar nuevos requerimientos.

• Permite comprender aquellos requerimientos que no están muy claros y que son de alta volatilidad.

• El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado.

• A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo

Análisis Jerárquico • Permite determinar el grado de importancia de cada requerimiento.

• Ayuda a identificar conflictos en los requerimientos.

• Muestra el orden en que deben ser implementados los requerimientos.

• Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.

Casos de Uso • Representan los requerimientos desde el punto de vista del usuario.

• Permiten representar más de un rol para cada afectado.

• Identifica requerimientos estancados, dentro de un conjunto de requerimientos.

• En sistemas grandes, toma mucho tiempo definir todos los casos de uso.

• El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.

40

Técnicas que pueden ser utilizadas en las actividades de IR

Análisis del Problema

Evaluación y negociación

Especificación de Requisitos

Validación Evolución

Entrevistas y Cuestionarios

X X

Lluvia de Ideas X X

Prototipos X

Análisis Jerárquico X X

Casos de Uso X X X


► Se ocupa de demostrar que los requerimientos definen el sistema que el cliente realmente quiere.

► Los costes de los errores de requerimientos son altos así que la validación es muy importante. ▪ Arreglar un error de requerimientos después de la

entrega puede costar unas 100 veces el coste de arreglar un error de implementación.

Comprobación de requerimientos► Validez. ¿Proporciona el sistema las funciones que mejor sostienen

las necesidades del cliente? ► Consistencia ¿hay algún conflicto entre requerimientos? ► Integridad ¿Se incluyen todas las funciones requeridas por el cliente? ► Realismo ¿Pueden los requerimientos ser implementados, dotados de

presupuesto y tecnología disponibles? ► Verificabilidad ¿Pueden comprobarse los requerimientos?

Técnicas de validación de requerimientos

►Revisión de requerimientos ▪ Análisis sistemático manual de los requerimientos

►Creación de prototipos ▪ Utilizar un modelo ejecutable del sistema para

comprobar los requerimientos. Tratado en el tema 17.

►Generación de casos de prueba ▪ Desarrollar pruebas ayuda a verificar la claridad de

los requerimientos.

Revisión de requerimientos

► Deberían ser realizadas revisiones regulares mientras está siendo formulada la definición de los requerimientos

► Tanto el cliente como el contratista deberían estar involucrados en las revisiones.

► Las revisiones pueden ser formales (con documentos completos) o informales. Las buenas comunicaciones entre los desarrolladores, el cliente y los usuarios puede resolver los problemas en una etapa temprana.

45

Evolución de requerimientos

► Los requerimientos evolucionan constantemente con dos objetivos básicos: ▪ Entender mejor las necesidades de los usuarios. ▪ Para adaptarse a las necesidades cambiantes de los

usuarios.

► Es esencial tener en cuenta estos cambios, tanto del sistema como del proceso de desarrollo.

Evolución de requerimientos

Entendimiento inicial del problema

Cambios en el entendimiento del

problema

Requerimientos Iniciales

Requerimientos Cambiados

Control de la evolución

Documento de Requerimientos V1

Implementación Sistema V1






Cambio de Requerimientos

Requerimientos y Sistema Inconsistentes

Requerimientos y Sistema Consistentes

LA INGENIERÍA DE REQUISITOS EN LOS MÉTODOS DE DESARROLLO AGILES

Informática Empresarial, UCR IF 7100 Ingeniería de Software

48

Métodos Agiles

Informática Empresarial, UCR IF 7100 Ingeniería de Software

49

► Métodos que dan soporte a los valores incluidos en el Manifiesto Ágil.

► Iterativos de ciclo corto y flexibles.

► Se centran más en el código que en la documentación, debido a: ▪ Son más adaptativos que predictivos: poca planificación. ▪ Orientados a las personas: confian en la experiencia, competencia y

colaboración

► Extreme Programming (XP) ▪ No habla explicitamente de técnicas de IR. ▪ Usa entrevistas, brainstroming, priorización e historias

de usuario.

► Scrum ▪ Los requisitos se recolectan en el backlog (lista

priorizada de características a implementar) ▪ En cada sprint se implementan las más prioritarias.


Métodos Agiles

► Metodologías Crystal ▪ Alguna de las técnicas pueden ser comparadas con

las de IR (prototipado, revisiones, pruebas)

►Desarrollo dirigido por características (FDD) ▪ La lista de características recogen de algún modo los

requisitos. ➢ Desarrollo dirigido por pruebas (TDD) ▪ La lista de características se documenta en los casos

de prueba automatizados y la validación se da corriendo dichas pruebas contra el código fuente.


Métodos Agiles

►Método de desarrollo de sistemas dinámico (DSDM) ▪ Los requisitos se elicitan en las dos primeras fases (viabilidad y estudio del negocio) ▪No hay técnicas especificas, se pueden usar varias.

►Desarrollo adaptativo de software (ASD) ▪Desarrollo iterativo e incremental con prototipos.


Métodos Agiles

Técnicas de IR en los MA

IF 7201 - Gestion de Proyectos de Software I 2006

53

►Implicación de los usuarios: ▪ Suponen “cliente ideal” con todo el conocimiento. ▪ La IR tradicional evitan esta suposición con

técnicas para confrontar y validar. ▪ En estos métodos los clientes sólo se implican en

las primeras fases.

►Entrevistas ▪ Es la principal técnica de elicitación de los MA

(orientación al cliente)


IF 7201 - Gestion de Proyectos de Software I 2006

54

►Priorización: ▪ Practica común de los MA ▪ Implementan primero los requisitos más valiosos para el

cliente. ▪ Se re prioriza muy frecuentemente: adaptación al entorno.

►Reuniones de análisis ▪ Son frecuentes durante todo el proceso. ▪ La documentación es menos extensa pero altamente

disciplinada (por ejemplo todas las historias a implementar deben cumplir con un criterio de aceptación con un formato estándar)


55

► Modelado ▪ A diferencia de la IR tradicional, en los MA solo se

usan para facilitar la comprensión. ▪ Son de usar y tirar

►Documentación ▪ No se pretende generar una documentación

completa del proyecto. ▪ Se deja mucha libertad al equipo de desarrollo.


56

► Validación ▪ Usan reuniones de revisión para la validación de

requisitos.

► Gestión de los Requisitos ▪ No es posible la trazabilidad total de los requisitos como

en la IR tradicional. ▪ Sin embargo, proporcionan una buena base: backlog, lista

de características, ... ▪ Aproximación perezosa (lazy) a la elicitación: se omiten

detalles para completarlos más tarde.

Historias de Usuario

57

►Una de las técnicas más usadas en los MA. ► Escritas por el usuario en su lenguaje, no contienen

aspectos técnicos.

► Sirven para estimar tiempos de desarrollo (casos de uso), no necesitan más detalle.

►Tres frases aproximadamente y entre una y tres

semanas de desarrollo.

Puntos Clave

58

► Las fases de la IR están presentes en los MA, pero no claramente separadas.

► Las técnicas están vagamente descritas, confian en la capacidad de los técnicos, lo que requiere buen entrenamiento de los equipos

►Documentación poco extensa ▪ Perdida de conocimientos ▪ Más compacta y fácil de mantener

► Problemas de trazabilidad, seguimiento manual si no se tienen altos niveles de automatización

Puntos Clave

59

► Estimación de coste y tiempo difíciles, por la aproximación perezosa.

► Los MA proporcionan muchas ventajas en el desarrollo en comunicación y eficiencia.

►Requiere una alta disciplina y automatización de procesos (como la trazabilidad) para poder ser realmente agiles.

Requerimientos del Software -...

Documents

Transcript of Requerimientos del Software -...