ingenieria requisitos
TRANSCRIPT
INGENIERIA DE REQUISITOSLic. Roxana Laurel R.
INTRODUCCION Lo más difícil en la construcción de un
sistema software es decidir precisamente qué construir... No existe tarea con mayor capacidad de lesionar al sistema, cuando se hace mal... Ninguna otra tarea es tan difícil de rectificar a posteriori...
F. P. Brooks, 1987
LA EXPERIENCIA EMPIRICA DEMUESTRA… Los requisitos contienen demasiados errores Muchos de estos errores no se detectan al
principio Muchos de estos errores podrían ser
detectados al principio No detectar estos errores incrementará los
costes (tiempo, dinero) de forma exponencial Además, los programadores obedecen los
requisitos (cuando existen).
CONSECUENCIAS
El sistema resultante no satisfará a los usuarios
Se producirán desacuerdos entre usuarios y desarrolladores
Puede ser imposible demostrar si el software cumple, o no, los requisitos
Se gastará tiempo y dinero en construir el sistema equivocado
COMPLEJIDAD • OJO: No estamos hablando de
sistemas de 15 o 30 requisitos. También hay Sistemas de cientos de requisitos Sistemas de miles de requisitos Sistemas de 5.000 requisitos Sistemas de más de 10.000 Sistemas de incluso 60.000 requisitos
1995/200: THE CHAOS REPORT
Gasto anual en EEUU: $250 mil millones en unos
175.000 proyectos. 31,1% (23%) son cancelados 52,7% (49%) cuestan un 190% más de lo
estimado Un 16,2% (28%) será finalizado a tiempo y
dentro del presupuesto, pero el producto final poseerá (aprox.) la mitad de los requisitos iniciales
ACUMULACION DE ERRORES
¿QUÉ ES UN REQUISITO? Un requisito es una ”condición o
capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado”.
También se aplica a las condiciones que
debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación.
INGENIERIA DE REQUISITOS
o La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.
o Los requisitos pueden ser funcionales y no funcionales
REQUISITOS FUNCIONALESDefinición de los servicios que el sistema debe proporcionar, cómo debe reaccionar a una entrada particular y cómo se debe comportar ante situaciones particulares.
Describen el funcionamiento del sistema Los RF del usuario pueden ser frases muy
generales sobre lo que el sistema debería hacer. Se suelen expresar como objetivos del sistema.
Los RF del sistema deben describir los servicios que hay que proporcionar con todo detalle: los casos de uso
REQUISITOS FUNCIONALESEJEMPLOS:
1. Se deben poder realizar búsquedas en base a diferentes criterios.2. Se deben proporcionar diferentes visores para que el usuario lea los documentos recuperados.3. Cada factura tendrá un número único y correlativo y la fecha.
REQUISITOS NO FUNCIONALESRestricciones que afectan a los servicios o funciones del sistema, tales como restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.
Definen propiedades emergentes del sistema, tales como el tiempo de respuesta, las necesidades de almacenamiento, la fiabilidad, …
Pueden especificar también la utilización de una herramienta CASE en particular, un lenguaje de programación o un método del desarrollo.
Pueden ser más críticos que los funcionales. Si un RF no se cumple, el sistema se degrada
Si un RNF no se cumple, el sistema puede inutilizarse
REQUISITOS NO FUNCIONALESEJEMPLOS: “El máximo espacio de almacenamiento
ocupado por el sistema debe ser de 8 MB porque el sistema debe alojarse completamente en una memoria de sólo lectura e instalarse en el coche”
“El proceso software y los documentos a realizar deben conformar el proceso y los estándares de documentación recogidos en la norma TELMo-ES-2003”
“El sistema no debe revelar ninguna información personal sobre los clientes excepto su nombre y su número de referencia"
¿COMO ESCRIBIR REQUISITOS? La “mejor forma” de escribir requisitos no
existe Lo más utilizado es el lenguaje natural.
Cada requisito expresado en una frases corta (“el sistema hará X ...”, “se facilitará Y...”, etc)
O lenguaje natural complementado con diagramas y/o notaciones formales
La notación utilizada depende de quien lee o quien escribe los requisitos.
Procesos de la Ingeniería de Requerimientos La Ingeniería de Requerimientos es un
proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema
Procesos de la Ingeniería de Requerimientos Las 4 actividades genéricas de alto nivel
son: estudio de factibilidad del sistema obtención y análisis de requerimientos especificación y documentación de los
requerimientos la validación de los requerimientos
ESTUDIO DE FACTIBILIDAD Un estudio de factibilidad es un estudio
corto y orientado a resolver varias preguntas: ¿ el sistema contribuye a los objetivos
generales de la organización ? ¿ el sistema se puede implementar
utilizando la tecnología actual y con las restricciones de costo y tiempo ?
¿ el sistema puede integrarse a otros que existe en la organización ?
Procesos de la Ingeniería de Requerimientos
OBTENCION Y ANALISIS DE REQUERIMIENTOS El personal del desarrollo técnico del
software trabajará con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, cuáles servicios debe proveer el sistema, el desempeño requerido del sistema, las restricciones del hardware, etc.
OBTENCION Y ANALISIS DE REQUERIMIENTOS La obtención y análisis es un proceso
difícil por varias razones: los stakeholders (personas que tienen
influencia directa o indirecta sobre los requerimientos del sistema) a menudo no conocen realmente lo que desean obtener, excepto en términos muy generales.
los stakeholders expresan los requerimientos con sus propios términos.
OBTENCION Y ANALISIS DE REQUERIMIENTOS La obtención y análisis es un proceso
difícil por varias razones (continuación): diferentes stakeholders tienen
requerimientos distintos y podrían expresarlos de varias formas. Se deben identificar todas las fuentes de requerimientos así como los conflictos.
Los factores políticos influyen en los requerimientos. Las personas buscan aumentar sus influencias.
OBTENCION Y ANALISIS DE REQUERIMIENTOS El método VORD (definición de
requerimientos orientados al punto de vista) se ha diseñado como un marco de trabajo orientado a servicios para la obtención y análisis de requerimientos.
OBTENCION Y ANALISIS DE REQUERIMIENTOS Las etapas principales de VORD son:
1. Identificación de puntos de vista, que implica descubrir los que reciben los servicios del sistema e identificar los servicios específicos que se suministran a cada punto de vista.2. Estructuración de puntos de vista que comprende agrupar los relacionados en una jerarquía
OBTENCION Y ANALISIS DE REQUERIMIENTOS Las etapas principales de VORD son:
3. Documentación de puntos de vista, que comprende refinar la descripción de éstos y los servicios identificados.4. Trazado del punto de vista del sistema, que comprende identificar los objetivos en un diseño OO utilizando la información del servicio encapsulado en los puntos de vista.
VALIDACION DE REQUERIMENTOS Esta validación muestra que éstos son
los que definen el sistema que el cliente desea.
Tiene mucho en común con el análisis ya que implica encontrar problemas con los requerimientos.
VALIDACION DE REQUERIMENTOS La validación de requerimientos es
importante debido a que los errores en el documento de requerimientos pueden conducir a costos excesivos al repetir el trabajo cuando sean descubiertos.
El costo de hacer un cambio en el sistema es mucho mayor que reparar los errores de diseño o codificación
VALIDACION DE REQUERIMENTOS Las verificaciones incluyen:
1. Verificación de validez: para incluir solo requerimientos realmente útiles.2. Verificación de consistencia: para evitar las contradicciones entre los requerimientos.3. Verificación de integridad: para incluir todas las restricciones pedidas.
VALIDACION DE REQUERIMENTOS Las verificaciones incluyen:
4. Verificación de realismo: para asegurarse que los requerimientos se pueden implementar.5. Verificabilidad: para reducir las discusiones entre el cliente y el contratista, los requerimientos deben redactarse de una manera verificable.
VALIDACION DE REQUISISTOS
Algunas preguntas recomendadas para realizar la validación:o ¿ La fuente del requisito está
identificada?o ¿ Cuáles otros requisitos están
relacionados con éste?o ¿ El requisito viola alguna restricción del
dominio del sistema?o ¿ El requisito se puede probar?
DOCUMENTACION DE LOS REQUISITOS Los objetivos de negocios que se desean
satisfacer con el sistema (esto viene del modelo del negocio del cliente)
La visión general del sistema ¿usted que cree?
El propósito del sistema ¿para que lo necesito?
Los objetivos del proyecto (y cómo mido si se cumplieron o no)
Los involucrados
DOCUMENTACION DE LOS REQUISITOS Restricciones impuestas (por el cliente o
el entorno) Otros hechos relevantes El alcance del proyecto El alcance del producto Los requisitos
DOCUMENTACION DE LOS REQUISITOS Soluciones ya existentes Riesgos Costos iniciales (valoración inicial) Ideas de posibles soluciones
¿COMO SE DEFINEN LOS REQUISITOS ? Existen diferentes técnicas:
Descripción en lenguaje natural Lista de características (feature)
ADMINISTRACION DE REQUERIMIENTOS Los requerimientos para sistemas
grandes son siempre cambiantes. Una razón es porque no siempre el
problema puede definirse totalmente. Es difícil anticipar que efectos tendrá el
sistema nuevo en la organización, y siempre se lo comparará con el sistema anterior (manual o automatizado).
ADMINISTRACION DE REQUERIMIENTOS Una vez que los usuarios finales
experimenten el nuevo sistema surgirán nuevos requerimientos porque:
1. Por lo general un sistema grande tiene una comunidad de usuarios diversa, los que tienen diferentes tipos de requerimientos, algunos contradictorios. Esto obliga a aceptar algunos y desechar otros.
ADMINISTRACION DE REQUERIMIENTOS Una vez que los usuarios finales
experimenten el nuevo sistema surgirán nuevos requerimientos porque:
2. Las personas que pagan por los sistemas (clientes) raras veces son las mismas que los usan. Los primeros imponen requerimientos organizacionales o presupuestarios, los segundos funcionales.
ADMINISTRACION DE REQUERIMIENTOS Una vez que los usuarios finales
experimenten el nuevo sistema surgirán nuevos requerimientos porque:
3. El entorno de negocios y técnico del sistema cambia y esto debe reflejarse en el sistema mismo. Se puede introducir nuevo hardware, puede ser necesario que el sistema interactúe con otros sistemas, etc.
¿POR QUE FRACASAN LOS PROYECTOS?
¿QUIENES PARTICIPAN EN LA IR? Entre las personas implicadas hay que
considerar: Organizaciones que integran la
organización del analista que está diseñando el sistema
Organizaciones o sistemas de respaldo Dirección Usuarios
¿QUIENES PARTICIPAN EN LA IR?
PROBLEMAS RELACIONADAS CON LAS PERSONAS INVOLUCRADAS Las vías que pueden dificultar la determinación
de los requisitos son: Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboración de
requisitos escritos Los usuarios insisten en nuevos requisitos después
de que el coste y la programación se hayan fijado. La comunicación con los usuarios es lenta Los usuarios no participan en revisiones o son
incapaces de hacerlo. Los usuarios no comprenden los problemas
técnicos Los usuarios no entienden el proceso del desarrollo
PROBLEMAS RELACIONADOS CON LOS ANALISTAS La correcta redacción de las Especificaciones
de requisitos del Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay que evitar: Uso de terminología ambigua en la redacción de
los documentos de requisitos Sobre especificación de los requisitos Escritura poco legible, voz pasiva, abuso de
negaciones Uso de verbos en condicional, expresiones
subjetivas Ausencia de términos y verbos del dominio de la
aplicación
PROBLEMAS RELACIONADOS CON LOS DESARROLLADORES El personal técnico y los usuarios finales
pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.
Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.
TRABAJO DE INVESTIGACION
Herramientas CASE para la IR. Requisitos de usuario y sistema Técnicas para la especificación de
requisitos.