ir10 refinando definicion sistema

Ingeniería de requerimientos

Ingeniería de Sistemas e Informática

Propósito de la sesión• Describe como se realiza el

proceso de refinamiento del sistema.

Contenido de la sesión• Refinamiento del sistema.

Propósito y contenido de la sesión

Recapitulando …

REFINANDO LA DEFINICIÓN DEL SISTEMARequerimientos de software

Puntos claves

• Un sistema completo de requisitos puede ser determinadodefiniendo las entradas, las salidas, las funciones, los atributosy los atributos del entorno del sistema

• Los requisitos deben excluir la información relacionada con elproyecto, tal como horario, planes del proyecto, presupuestosy test de pruebas, así como la información del diseño

• Los requisitos y el proceso del diseño son iterativos; losrequisitos conducen a la selección de ciertas opciones deldiseño, que alternadamente pueden iniciar nuevos requisitos.

• Las restricciones del diseño son restricciones en el diseño delsistema o del proceso

Definición de requerimientos de software

• Una Capacidad del software necesaria para el usuario para resolver el problema y alcanzar un objetivo

• Una capacidad del software que se debe satisfacer o poseer un sistema o un componente del sistema para satisfacer el contrato, el estándar, la especificación, o la otra documentación formalmente impuesta.

Elementos del sistema

Entradas al Sistema

Salidas del Sistema

Funciones del Sistema

Características del Sistema

Atributos del entorno del Sistema

Relación entre las características y los requerimientos del software

• Las características son simples descripciones de un deseo y comportamiento beneficioso– El documento de visión cita las características en el lenguaje del usuario

• Los requerimientos de software expresan las características con más detalles, usando uno o mas especificaciones de requerimientos de software que deben ser cumplidos por los desarrolladores para suministrar las características al usuario

• Las características ayudan a comprender y comunicar a un alto nivel de abstracción, pero no podemos describir el sistema y escribir código de esas descripciones

• Los requisitos de software son específicos.– Podemos codificar de ellos y deben ser lo suficientemente específico para ser

"Sometidos a pruebas"; es decir, podemos validar el sistema (se implementa un requisito real)

Relación entre las características y los requerimientos del software

Documento Visión Requerimientos del sw

Característica 63: El sistema deseguimientos de defectosproporcionará la informaciónpara ayudar al usuario adeterminar estado del proyecto.

SR63.1 La información será proporcionadaen un histograma que demuestra tiempoen el eje “x” y el número de los defectosencontrados en el eje “y”.

SR63.2 El usuario puede ingresar elperíodo en días, semanas, o meses.

SR63.3 Un informe ejemplo se demuestraen la ilustración 1.

El dilema de los requerimientos: “que” versus “como”

Excluir la Información del proyecto• Calendarios, plan de la administración de la

configuración, planes de verificación y validación, presupuestos, …

Excluir la Información del diseño• Diseño del sistema, arquitectura

Más sobre requisitos versus diseño

• Iteración de requerimientos y de diseño.

Otras características de los requisitos

Requerimientos de Software (1)

• Requerimientos Funcionales• Requerimientos no Funcionales

– Usabilidad– Confiabilidad

• Disponibilidad• Promedio entre fallas• Promedio de reparación• Exactitud• Máximo número de defectos o ratio de defectos• Defectos por tipo

– Funcionamiento• Tiempo de respuesta• Rendimiento, transacciones por segundo• Capacidad, número de clientes o transacciones• Modos de degradación

– Adaptabilidad


• Restricciones del diseño– Son limitaciones en el diseño del sistema o proceso

• Use Oracle BDMS• Programar en Visual Basic• Use la librería de clases XYZ• Compatibilidad con los sistemas existentes• Estándares

• ¿Las Restricciones de Diseño son requisitos verdaderos?– No, porque no representan a ninguno de los 5 elementos

del sistema– Si, cuando es elevada a nivel de negocio, política o asunto

técnico.

Usando requisitos padre-hijo para incrementar la especificidad (1)

Usando requisitos padre-hijo para incrementar la especificidad (2)

REFINANDO LOS CASOS DE USO

Refinando la definición del sistema

Puntos claves

• Para soportar las actividades del diseño y la codificación, los casos de uso desarrollados en las actividades de recopilación de requerimientos deben estar completos

• Los casos de uso son apropiados cuando el sistema es rico en funcionalidad y debe soportar diferentes tipos de usuarios

• Los casos de uso no son tan efectivos cuando aplicamos a sistemas sin usuarios o con pocos usuarios y pocas interfaces, aquellos con principalmente requisitos no funcionales y restricciones de diseño

Redundancia del problema

• Los casos de uso esta dirigido a la redundancia significativa, aumentando el tamaño de la documentación de los requisitos– Muchos casos de uso son muy similares, sin embargo no son

lo suficientemente distintos para descomponerlo– El mantenimiento puede ser un desafío cuando el

comportamiento común es expresado en muchos casos de uso

• Requiere el uso adicional relaciones de caso, como la generalización, include, extend; que añaden complejidad.

Refinando las especificaciones de caso de uso

Ítem ValorNombre caso de uso Control de luzBreve descripción Este caso de uso describe la forma como las luces son

encendidas o apagadas o su intensidad es disminuida cuando los usuarios presionan los interruptores de luz de varias maneras.

Flujo de eventos El flujo básico del caso de uso comienza cuando el Residente presiona el botón del Control de Interruptores(CI). Si el Residente deja de presionar el CI dentro del periodo de tiempo, el sistema “conmuta” el estado de la luz. Esto significa:• Si la luz estaba encendida, la luz se apaga, no hay

iluminación.• Si la luz estaba apagada, la luz se enciende con el ultimo

nivel de iluminación conocido.


Ítem ValorFlujo alternativo de eventos

Si el Residente mantiene pulsado el CI por mas de un segundo, el sistema inicia la disminución de la iluminación para el nivel indicado de luz. La siguiente acción ocurre mientras el residente continua presionando el botón CI:1. La iluminación se incrementa lentamente hasta el valor máximo a un

ratio de 10% en un segundo.

2. Cuando el nivel máximo de iluminación es alcanzado, la iluminación disminuye lentamente hasta el valor mínimo a un ratio de 10% en un segundo

3. Cuando el valor mínimo es alcanzado, la secuencia del caso de uso regresa al paso 1.

Cuando el residente libera la presión del botón CI.

4. El sistema cesa el cambio de iluminación.


Ítem ValorPre condiciones • El botón seleccionado CI debe estar “Graduación

de iluminación activada” • El botón seleccionado CI debería estar pre

programado para el control de banco de luces.Post condiciones Al salir de este caso de uso, la intensidad de la luz

es recordado por el sistema.Requerimientos especiales

El nivel mínimo de luz no puede ser 0. Debe ser un valor mínimo aceptable tal que las luces sean adecuadas para la noche.

UNA MODERNA ESPECIFICACIÓN DE SOFTWARERefinando la definición del sistema

Puntos Claves

• Un paquete moderno de ERS (ERS, Software Requirements Specification) es una colección de artefactos que describen el comportamiento externo del sistema (modelo conceptual).

• El documento de Visión es la entrada del moderno ERS. Es una declaración ampliada de las necesidades del usuario, metas y objetivos, mercados objetivos y características del sistema; lo último se enfoca en los detalles a implementar.

• El “correcto balance” de la técnica esta en el mix del modelo de casos de uso y la especificación tradicional de requerimientos.

El moderno paquete ERS

• Históricamente, la técnica de documentación de requerimientos fue usar el lenguaje natural

• El mejoramiento de la técnica derivo en el varios estándares, tal como IEEE (Institute of Electrical and Electronics Engineers) 830: Standard for Software Requirements Specification (1994).

• Con las herramientas y técnicas hoy, el ERS es una estructura lógica en vez de un documento físico.

Elementos de un paquete moderno ERS

El moderno paquete ERS

• Es un paquete activo y viviente.• Tiene varios papeles cuando se comienza con el desarrollo.

– Es la base para la comunicación entre desarrolladores y los grupos externos, usuarios y stakeholders.

– Formalmente e informalmente representa una acuerdo entre las partes. Se desarrolla lo que esta en ello.

– El administrador del proyecto lo usa como estándar en las discusiones con el equipo de proyecto

– Sirve de entrada al diseño e implementación– Sirve de entrada al testeo y aseguramiento de la calidad– Controla la evolución del sistema durante toda la fase de

desarrollo

¿Quién es el propietario del paquete ERS?

• ¿Quién es responsable de crear y mantener los componentes del ERS?– Usualmente, los miembros del equipo– El análisis del sistema refinara el documento de visión– Recuerde, es un artefacto vivo y necesita ser actualizado

Organizando un paquete moderno ERS (1)

Organizando un paquete moderno ERS (2)

Organizando un paquete moderno ERS

Balanceando los requerimientos

Sobre la ambigüedad y especificidad

• El requerimiento “sweet spot” es punto de balance de la gran cantidad de comprensibilidad y la mínima cantidad de ambigüedad

• Encontrar el “sweet spot” dependerá de las habilidades de los miembros del equipo, el contexto de la aplicación y el nivel de seguridad

• Si el riesgo de malinterpretar es inaceptable, más técnicas de requerimientos formales es necesario ser aplicado.

Moderador

Notas de la presentación

Sweet spot= punto justo, punto ideal, punto óptimo Sweet= dulce, suave azucarado Spot= lugar, sitio, lugar, punto

Encontrando el “sweet spot”

• ¿Realmente, tenemos que especificar Pantone 287 como el fondo de nuestras GUI? ¿No? ¿Le gusto el color la ultima vez?

• ¿A que nivel de detalle de especificar los requisitos para evitar cualquier cambio?• Eso depende.

El principal reto es detallar

suficientemente los

requerimientos

Caja de luz

• Características– Controlado por un

microprocesador– Almacena el estado del botón

Count si ha sido pulsado un numero par o impar de veces

– El detector de bombilla quemada destella la bombilla restante

Objetivo del ejercicio

• Escribir de manera clara y simple los requerimientos– Usando el lenguaje natural o los casos de uso– Para el ejercicio, el usuario esta disponible para entrevistarlo, así se

puede refinar los requerimientos

Especificación de requerimientos (Davis,1993)

• Después de pulsar on (antes pulso off) el sistema esta encendido.

• Después de pulsar off (antes pulso on) el sistema esta apagado.

• Si esta en ON, si “Count” ha sido presionado un numero impar de veces, brilla “Odd”.

• Si esta en ON, si “Count” ha sido presionado un numero par de veces, brilla “Even”.

• Si uno de las luces esta quemada el otro debe parpadear a intervalos de 1 segundo

¿Es suficiente?

• La especificación es suficiente para la mayoría de casos.• Refleja la forma como el dispositivo debe trabajar• Para el programador, quien debe escribir el código, descubre

por lo menos la siguiente ambigüedad: – ¿Qué significa parpadear a intervalos de 1 segundo?– ¿Todavía parece obvio?

Posible ciclo de servicio de la lámpara

¿Ciclo A o B?

• ¿Cuál escoge? ¿Ciclo de servicio A o B?– Aunque la mayoría escoge B, esta claro que el requerimiento es

ambiguo. – El programador preguntara al cliente ¿Qué ciclo debe ser usado?

• Si el programador no es perspicaz o no reconoce la ambigüedad o piensa “Sé que significa porque se como debe trabajar”– El proyecto podría estar en riesgo– Para la mayoría de aplicaciones, no es importante si se enciende

durante un segundo o 0.25 segundos.– Si el equipo es electro quirúrgico si importa .

¿Cuál es nivel de especificidad?

• Depende del contexto de la aplicación• ¿Cuán capaces para tomar las decisiones correctas son los

desarrolladores?• Mínimo nivel de seguridad para hacer preguntas donde hay

ambigüedad– Para el equipo electro quirúrgico se debería ahondar en la

especificación• Tiempo de elevación• Precisión del tiempo• Voltaje, etc.

Ambigüedad VS especificidad

Moderador

Notas de la presentación

Understandability = comprensibilidad

Mary tiene un pequeño cordero

• Tiene 1ª: mantiene en posición como propiedad ….. 4ª: Adquiere o toma posesión de: obtiene (como en “lo mejor”) 4c: ACEPTA; Tiene matrimonio … 5ª: Marcado o caracterizado por (tiene el cabello rojo)… 10ª: Mantener una posición de ventaja… 10b: TRAMPA, ENGAÑO… 12b: DAR A LUZ (tener un bebe)… 13: Compartir (tener una cena)… 14: SOBORNO, (se puede tener a un precio)

• Cordero 1ª: Una joven oveja de menos de un año de edad o sin dientes permanentes … 1b: El joven de los animales (ej. Pequeños antílopes)… 2ª: Una persona caballerosa o débil como un cordero… 2b: MASCOTA… 2c: Una persona fácil de engañar o engañada, especialmente en falsificación de pagares… 3ª: Carne de cordero usado como comida.

Mary tiene un cordero

Técnicas de desambiguación

• Memorización heurística– Preguntar al grupo de desarrollo, usuarios o stakeholder

• Técnica de la palabra clave– El codero de Mary

• Técnica énfasis– Lea el requisito en voz alta y enfatice las palabras individuales hasta tener

muchas interpretaciones como sea posible• Si sólo una interpretación es correcta, declare de nuevo el requerimiento• Si múltiples interpretaciones son correctas, generar requerimientos

adicionales• Otras técnicas

– Use figuras, gráficos u otros métodos formales

¿Qué hacer?

• Para encontrar “sweet spot”– Use el lenguaje natural si fuera posible– Use figuras y diagramas– Cuando este en duda, pregunte– Argumente sus especificaciones con mas métodos formales

• Entrene a su equipo a reconocer problemas de ambigüedad y como solucionarlos

MÉTODOS TÉCNICOS PARA ESPECIFICAR REQUERIMIENTOS


Puntos claves

• Los métodos técnicos son apropiados cuando la descripción de los requerimientos son demasiados complejos para decirlo en lenguaje natural o si no puede permitirse malas interpretaciones

• Los métodos técnicos son seudocódigo, diagrama de estados finitos, arboles de decisión, diagrama de actividades, modelo entidad relación, análisis orientado a objetos y análisis estructurado

Seudocódigo

Diagrama de estado finitos

Árbol de decisión

Diagrama de actividad

Diagrama entidad relación

Modelo orientado a objetos

Diagrama de flujo de datos

MEDIDA DE LA CALIDAD DE LOS REQUERIMIENTOS DE SOFTWARE


Puntos clave

• Tener un conjunto de requerimientos de calidad es objetivo principal, estos requisitos deben cubrir nueve medidas de calidad

• Las lista de chequeo pueden ser usadas para asegurar la calidad de los requerimientos, modelo de casos de uso, especificación de casos de uso y actores

• Una alta calidad en ERS tiene un buen TOC, a buen índice, historial de revisiones y glosario

Nueve medidas de la calidad

• Correcto• Inequívoco (no ambiguo)• Completo• Consistente• Clasificado por importancia y estabilidad• Verificable• Modificable• Trazable• Entendible

Universo necesidades y requerimientos

Requerimientos no ambiguos

Si y solo si tiene una sola interpretación•IEEE 830-1993, § 4.3.2, 1994

Completitud del conjunto de requerimientos

Si y solo si describen todo los requisitos significativos concernientes al usuario, relacionados con al funcionalidad, el rendimiento, las restricciones de diseño, atributos o las interfaces externas

• IEEE 830-1993, §4.3.3, 1994

Asegurando la completitud

• Asegurarse que las figuras, etiquetas y diagramas tienen las etiquetas y referencias apropiadas

• Algunos aspectos pueden ser evaluados por un desarrollador sin conocimiento especial de la aplicación– La raíz cuadrada de un numero – ¿Si es negativo?

• Revisar las entradas de las clases realizables para asegurarnos que el comportamiento de sistema este descrito para entradas válidas e invalidas

Completitud en los requerimientos no funcionales

• A menudo se descuida aspectos de rendimiento y restricciones de diseño o suposiciones sobre las interfaces externas con otros sistemas

• Se debería crear una lista de chequeo siguiendo las guías en el área de usabilidad, confiabilidad, rendimiento y suportabilidad. Asimismo, para la restricciones de diseño.

Completitud de los requerimientos funcionales

• Omitir la funcionalidad es difícil• Los desarrolladores técnicos no saben si se ha omitido alguna

funcionalidad– La funcionalidad es nueva

• A veces, la funcionalidad es profundamente arraigada y obvia para el usuario– En un sistema de nómina, el pago del día feriado

• El uso de técnicas de caso de uso ayudan

Completitud a través del prototipo

• Los storyborads, la revisión de requerimientos y los prototipos nos acercaran mejor a los verdaderos requerimientos.

• El equipo de desarrollo debe dar un paso adicional con preguntas “que pasa-si” (what-if) para las condiciones limites del sistemas, excepciones y eventos inusuales.

Consistencia en el conjunto de requerimientos

• Si solo si ningún conjunto individual de requerimientos esta en conflicto con otro– IEEE 830-1993, §4.3.4.1, 1994

• Los conflictos toman varias formas y son visibles en varios niveles de detalle– Si esta formalizada y automatizada, se identifican mecánicamente– Sino es necesaria una evaluación manual

• Algunas veces, son obvios– Cuando ocurre X se da la acción P– Cuando ocurre X se da la acción Q

• Los prototipos ayudan en la consistencia de los requerimientos• Los profesionales de testeo y aseguramiento de calidad lo hacen a través de

una evaluación manual

Ranqueo de requirimientos por importancia y estabilidad

• En un conjunto de alta calidad, los desarrolladores, clientes y otros stakeholders tienen ranqueado los requerimientos por importancia para el cliente y en términos de estabilidad– IEEE 830-1993, §4.3.5, 1994– Importante en el alcance del proyecto

• Los recursos son insuficientes para implementar todos los requerimientos

• Por eso, se planifica y presupuesta• Es útil saber que requerimientos son volátiles y que requerimientos el

usuario considera críticos– Los requerimientos tienen atributos como: costo, riesgo, dificultad y otros.

(Documento visión)• Basados principalmente en la estrategia de implementación

– Los atributos importancia y estabilidad son asociados con la percepción del usuario del mundo

Ranqueo de requerimientos

Ranqueo de requerimientos

• Dada esta información y otros factores, se debe determinar el porcentaje para determinar la importancia y relativa volatilidad.– El administrador del proyecto debería estar preparado para dedicar

una proporcionalidad alta de recursos en SR103 y SR172– Igualmente en SR071

Requerimientos verificables

• Es verificable en conjunto si y solo si cada uno de los componentes contenidos en los requerimientos es verificable

• Los requerimientos pueden ser considerados verificables si y solo si allí existe un finito, costo efectivo del proceso con el cual una persona o máquina puede determinar que el desarrollo del sistema de software satisface verdaderamente los requerimientos– IEEE 830-1993, §4.3.6, 1994

Pruebas para verificar los requerimientos

• No es posible proveer una prueba científica rigurosa de verificación para cada requisito, pero eso no es generalmente necesario.

• La responsabilidad del personal de pruebas (testing) y de aseguramiento de la calidad (quality assurance) es crear los apropiados casos de prueba y los procedimientos de prueba para llevar la comprobación en cuanto el software ha sido desarrollado.– Ellos necesitan requerimiento bien definidos y sin ambigüedad– Es común tener una reunión con los especialistas de las pruebas y

preguntarles• ¿Esta Ud. Seguro que puede crear un “test script” para verificar que el

requerimiento ha sido satisfecho?

Típicas reacciones de los desarrolladores y/o profesionales de las pruebas en relación a la verificación

• El sistema debe soportar 1000 usuarios simultáneamente– Eso depende de que son capaces de a hacer cuando ellos están conectados

(logged in).– Si el usuario tiene abierta las posibilidades podrían entrar a una transacción

que la aplicación explore secuencialmente a través de cada registro de la base de datos• Podría ser difícil de verificar que el sistema tiene mil usuarios cargados• Hay una probabilidad mínima pero diferente de cero que los 1000

usuarios decidan realizar tal transacción al mismo tiempo• Si los usuarios están limitados a cierta clase de transacciones y si

podemos determinar una típica, la transacción costosa, podemos verificar que el requerimiento ha sido satisfecho con un razonable grado de certeza, aunque tendremos que usar una herramienta de carga para simular 1000 terminales activos

Típicas reacciones de los desarrolladores y/o profesionales de las pruebas en relación a la verificación

• El sistema responderá a una consulta arbitraria en 500 milésimas de segundo– Eso depende de lo que signifique arbitrario. Si el rango de las posibles consultas es finita y si

podemos identificar la consulta más compleja, nosotros podemos verificar el comportamiento del sistema.

• El tiempo de visualización será de “forma placentera” – No se preocupe por eso. La belleza esta en el ojo del espectador

• El sistema será amigable con el usuario– Esto es igual de incorrecto que “forma placentera”– Pero sin definir cuidadosamente los términos y detalles, “amigable al usuario” es una invitación a

la discusión• El sistema exporta vista de datos en el formato separado por comas

– Me gustaría aclarar los detalles; por ejemplo, ¿Qué sucede si la vista de datos es nula?– Pero en principio, si, podemos verificar que el sistema produce el comportamiento deseado en

esta área.• La verificación y validación son aspectos importantes para desarrollar software de alta calidad.

Conjunto de requerimientos modificables

• Si sólo si su estructura y estilo son tal que cualquier cambio de los requerimientos pueden ser hechos fácilmente, completamente y consistentemente, mientras se conserva la estructura y estilo existente. – IEEE 830-1993, §4.3.7, 1994– Estos requerimientos tienen mínima redundancia y están

bien organizados, con una tabla de contenido, índice y referencia cruzada.

– Podría o no mantenerse el paquete de requerimientos con una herramienta automatizada. Aunque es una necesidad en sistemas grandes, que pueden tener miles de requisitos.

Trazabilidad de requerimientos

• Si sólo si cada uno de los requerimientos esta claro y existe un mecanismo que hace factible referirlo en el futuro desarrollo– IEEE 830-1993, §4.3.8, 1994– Los requerimientos tienen identificadores como etiquetas o números– Algunos componentes necesitaran “trazar” a otros componentes del mismo proyecto

y posiblemente del mismo paquete.• El cambio de un requerimiento podría afectar a otro requerimiento• Algunos requerimientos pueden ser descritos como sub o hijo, por lo que la

trazabilidad es obvia.– La trazabilidad permite contestar “Que pasa-si”

• ¿Qué pasa si cambiamos este requisito?• ¿Interactúa con el desarrollo de software y, si es así, con qué elementos?• ¿Fuerza a revisar el plan de pruebas, si es así, cuales?

– Para el mismo proyecto se puede usar la matriz de trazabilidad

Matriz de trazabilidad

Requerimientos entendidos

• Un conjunto de requerimientos es entendible si el usuario y el desarrollador comprenden los requerimientos individuales y la funcionalidad completa.

Preguntas

¿Qué hemos aprendido?

Reflexionemos

ir10 refinando definicion sistema

Documents