Revisión de conceptos básicos clase IR

Profa. Yamila Gascón

1

CLASE 3

REVISIÓN DE CONCEPTOS BÁSICOS (Material Modulo Ingeniería de

Requisitos)

Tema 1 Requisitos: Conceptos, tipos y

propiedades (Fuente: Barrios, J. y Montilva, J.)

El Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) son dos sub-

disciplinas de la Ingeniería de Software (IS). El MN está relacionado con el estudio del

espacio del problema en IS e IR está asociado al problema de los requisitos y al espacio

de la solución. Cuando se aplican al desarrollo de software como procesos, el MN

precede a la IR.

1) ¿Qué es un requisito?

Perspectiva del usuario

– Un requisito es una condición o capacidad de la aplicación (o sistema de software)

que necesita un usuario para resolver un problema o alcanzar un objetivo. • Perspectiva del desarrollador:

–Es una condición o capacidad que debe ser satisfecha o poseída por la aplicación, a

fin de satisfacer un contrato, estándar, especificación u otro documento

formalmente impuesto. • En ambos casos, es una representación documentada de una condición o capacidad

que debe mostrar la aplicación en desarrollo.

2) ¿Qué es un requisito del software?

Es una condición o capacidad que expresa lo que una aplicación debe hacer para

satisfacer necesidades de información de su dominio (sistema de hardware/software;

negocio).

Los requisitos van a definir lo que la aplicación debe hacer, las interacciones usuarios-

aplicación y aplicación-aplicación, las restricciones bajo las cuales la aplicación debe

operar, los atributos de calidad que la aplicación debe satisfacer.

3) ¿Cuál es la clasificación de los requisitos de software?

Wiegers, 2003


2

Los requisitos del software funcionales establecen los objetivos del negocio con respecto

a la aplicación, los servicios que la aplicación debe proporcionarle al negocio, determinan

la funcionalidad de la aplicación y qué funciones debe ejecutar la aplicación.

Los requisitos funcionales pueden ser:

a) Del negocio

Se expresan desde la perspectiva de la empresa:

• Describen porque la empresa o el cliente desea desarrollar la aplicación

• Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso de la

aplicación

b) Usuarios

–Se expresan desde la perspectiva del usuario:

• Describen las necesidades que los usuarios tienen y las tareas que los usuarios

realizarán con la aplicación

• Expresan lo que el usuario será capaz de hacer con la aplicación

–Se modelan mediante casos de uso

–Ejemplos:

• Hojear la mapoteca digital

• Visualizar un mapa

• Comprar un mapa

c) Del sistema

–Están asociados a productos que tienen componentes de hardware y software

–Asumen que la aplicación es parte de un sistema mayor, p.ej.:

• Videojuegos, equipos de audio, etc.

• Sistemas de información gerencial

• Sistemas de control (Ej. Sensores/actuadores)

–Ejemplos de requisitos del sistema:

• El sistema de control deberá disparar una alarma cada vez que el sensor detecte una

presión fuera del rango permisible

• La interfaz del celular debe bloquearse cada vez que el usuario presione

simultáneamente el botón “Llamar” y la tecla *

d) Del funcionamiento

–Se expresan desde la perspectiva del desarrollador:

• Son requisitos funcionales propiamente dichos

• Describen los servicios que la aplicación presta a todos sus usuarios directos

• Expresan que hace la aplicación bajo ciertos estímulos o eventos (comportamiento del

sistema)

–Ejemplos:

•mimapa.com deberá permitir que el cliente efectúe el pago de su pedido en línea usando

tarjetas de crédito o un sistema de pagos en línea (Ej. paypal)

• El sistema debe permitirle al usuario visualizar el mapa seleccionado por el usuario de

aquellos contenidos en el catálogo de mapas

Los requisitos de software no funcionales no están relacionados directamente con el

comportamiento de la aplicación, restringen el diseño de la aplicación (la solución),


3

establecen las limitaciones para su desarrollo y definen la calidad que la aplicación debe

tener.

Los requisitos no funcionales pueden ser:

a) Restricciones:

–Expresan las limitaciones que se le imponen al desarrollo la aplicación

– Describen aspectos tales como:

• Plataforma de desarrollo y operación (H/S)

• Uso de estándares, prácticas, métodos de desarrollo, herramientas, etc.

• Tiempo máximo de desarrollo

• Costo máximo del proyecto

–Ejemplos:

•mimapa.com debe ser desarrollada:

–Bajo una plataforma LAMP: Linux, Apache, MySQLy PHP

–En un tiempo no mayor a seis meses

–Con costo no superior a los Bs.F 300.000

b) Atributos de calidad

–Son las cualidades o propiedades de calidad que la aplicación debe satisfacer, por

ejemplo:

• El rendimiento que la aplicación debe mostrar

• La confiabilidad que debe poseer

• La seguridad que debe proveer

• La utilidad que debe garantizar

–La calidad de una aplicación se mide en función de sus atributos de calidad

–Para facilitar su medición durante la verificación, deben expresarse cuantitativa o

cualitativamente

• Ejemplo:

– mimapa.com debe tener una confiabilidad igual o mayor al 95%

–Los atributos cualitativos se miden usando escalas cualitativas, tales como la Escala de

LIKERT

–1: muy bajo, 2: bajo, 3: medio, 4: alto, 5: muy alto

• Ejemplo:

–mimapa.com debe ser fácil de usar:

»Debe medir un mínimo de 4 puntos en una escala de 5 puntos

c) Requisitos de interfaz

–Expresan las características de la interacción usuario-sistema o sistema-sistema

–Se dividen en:

• Requisitos de interfaz gráfica (GUI):

–Describen las propiedades generales del interfaz gráfica que permitirá la interacción

entre el usuario y la aplicación

–Ej.: La interfaz de la aplicación mimapa.com debe ser implementada usando tecnología

web

• Requisitos de interfaces con otros sistemas:

–Describen con qué o cómo la aplicación interactuará con otras aplicaciones de software

o sistemas de hardware

–Ej.: mimapa.comdeberá interactuar con el sistema de pagos en línea paypal

d) Reglas del negocio:


4

–Expresan regulaciones que la aplicación debe acatar, p.ej.:

• Regulaciones gubernamentales: Leyes, decretos, providencias, etc.

• Regulaciones de la empresa: Políticas, normas, procedimientos, estrategias, etc.

• Regulaciones propias de la aplicación:

–Estándares y mejores prácticas de desarrollo que deben seguirse

–Algoritmos que deben usarse, etc.

–Ejemplos:

•mimapa.com debe elaborarse siguiendo el método de WATCH adoptado por la

empresa VECTOR C.A.

• Un cliente puede descargar gratuitamente las actualizaciones de un mapa adquirido

por el/ella durante los 12 meses siguientes a su compra

4) ¿Cuáles son los tipos de requisitos no funcionales?

a) Funcionabilidad: Los atributos de calidad asociados a la funcionabilidad, son el grupo

de atributos que permiten calificar si una aplicación maneja adecuadamente las funciones

para las cuales fue diseñada, entre ellas encontramos:

– Adecuación: Capacidad de la aplicación para realizar funciones apropiadas a las tareas

o procesos del negocio que ejecutan los usuarios

–Interoperabilidad: Habilidad de la aplicación para interactuar con otros sistemas o

aplicaciones

–Seguridad: Habilidad de la aplicación para prevenir el acceso no autorizado (accidental

o premeditado) a sus programas y datos

–Conformidad: Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas

b) Confiabilidad: Los atributos de calidad asociados a la confiabilidad, miden la

capacidad de la aplicación para mantener un nivel de rendimiento aceptable bajo

condiciones normales y en un tiempo establecido, entre ellas se encuentran:

– Nivel de Madurez: Mide la frecuencia de fallas ocasionada por errores en el software

–Tolerancia a fallas: Habilidad de la aplicación para mantener un nivel específico de

funcionamiento en caso de fallas

Adecuación

Interoperabilidad

Seguridad

Conformidad

Nivel de Madurez Tolerancia a fallos Facilidad de recuperación

Comprensibilidad

Facilidad de aprendizaje

Operatividad

Uso de recursos

Rendimiento

Capacidad de análisis Facilidad de prueba

Facilidad de modificación

Facilidad de instalación

Adaptabilidad

Coexistencia


5

–Facilidad de Recuperación: Habilidad de la aplicación para restablecer su nivel de

operación y recuperar sus datos ante una falla

c) Utilidad: Los atributos de calidad asociados a la utilidad, permiten evaluar el esfuerzo

que los usuarios invierten en utilizar el sistema, entre ellos se encuentran:

– Comprensibilidad: Capacidad que tiene la aplicación para que sus usuarios reconozcan

la estructura lógica de la aplicación y los conceptos relativos a ella

–Facilidad de Aprendizaje: Capacidad que tiene la aplicación para que sus usuarios

aprendan a usarlo

–Operatividad: Capacidad de la aplicación para que sus usuarios la operen y controlen

d) Eficiencia: Los atributos de calidad asociados a la eficiencia, evalúan la relación entre

el nivel de funcionamiento de la aplicación y la cantidad de recursos utilizados, entre

éstos se encuentran:

–Uso de recursos: Mide la cantidad de recursos usados y la duración de su uso durante la

ejecución de sus funciones

–Rendimiento: Especifican qué tan bien o tan rápido debe la aplicación ejecutar una

función dada en términos de: Velocidad (tiempo promedio de acceso a datos), Volumen

de transacciones por minuto, Capacidad (carga de uso concurrente) y Tiempo (demanda

de tiempo real)

e) Mantenibilidad: Los atributos de calidad asociados a la mantenibilidad, permiten

medir el esfuerzo requerido para mantener la aplicación, bien sea debido a fallas o a

mejoras, entre éstos se encuentran:

–Facilidad de Modificación: Capacidad que tiene la aplicación para que sus

mantenedores puedan modificar aspectos o funciones y adaptar la aplicación a un

ambiente diferente

–Capacidad de análisis: Capacidad de la aplicación para diagnosticar deficiencias o

causas de fallas o identificar partes que han de ser modificadas

–Facilidad de prueba: Capacidad de la aplicación para permitir ser validada, una vez

modificada

f) Portabilidad: Los atributos de calidad asociados a la portabilidad, miden la habilidad

de la aplicación para ser transferida de un ambiente (plataforma de operación) a otro,

entre éstos se encuentran:

– Facilidad de Instalación: Habilidad de la aplicación para instalarse en su ambiente de

operación

–Adaptabilidad: Capacidad de la aplicación para ser adaptada a diferentes ambientes de

operación sin que se requiera modificarla más allá de lo requerido

–Coexistencia: Capacidad de la aplicación para coexistir con otras aplicaciones

compartiendo recursos comunes

5) ¿Cuáles son los niveles de requisitos?

Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que

ellos tratan (adaptado de [Wiegers, 2003])


6

6) ¿Cuáles son las propiedades de los requisitos?

La calidad de los requisitos se mide por sus propiedades:

–Cada requisito debe expresarse de una manera sencilla, clara y sin ambigüedades,

usando:

• Lenguaje natural (Español),

• Lenguajes gráficos (Ej. UML) o

• Lenguajes formales (Ej. Notación Z)

–Preferiblemente, debe expresarse de manera cuantitativa

• Uso de métricas que faciliten la verificación

–Debe identificarse de manera única e inequívoca

• Uso de un sistema de numeración para facilitar su búsqueda y manejo

–Debe ser correcto

• Debe estar validado por el cliente

–Los requisitos deben ser consistentes entre sí

• No debe haber conflictos o incompatibilidad entre requisitos

–Deben ser completos

• Deben describir toda la funcionalidad que la aplicación deberá implementar

– Cada requisito debe ser factible (realista o alcanzable)

– Debe describir algo que el cliente o usuario necesita

• Resuelve algún problema del cliente

–Debe ser verificable

• Deben medibles y sin ambigüedad

–Se le puede hacer un seguimiento a través de todo el desarrollo del sistema

7) ¿Cuáles son los problemas que presentan los requisitos?

• Requisitos incompletos (13.1%)

• Falta de participación del usuario (12.4%)

• Falta de recursos (10.6%)


7

• Expectativas poco realistas (9.9%)

• Falta de apoyo gerencial (9.3%)

• Cambios en los requisitos y las especificaciones (8.7%)

• Falta de planificación (8.1%)

• El sistema dejó de ser necesario (7.5%)

a) Cuando los requisitos son mal definidos, no reflejan las necesidades reales de

los actores del proyecto, son inconsistentes, incompletos, no son factibles, y el

costo de cambiar los requisitos crece a medida que avanza el proyecto.

b) En el caso de que el usuario o cliente no siempre sabe lo que quiere del

sistema, se observa al inicio del proyecto, que el mismo no sabe que esperar del

sistema y los requisitos tienden a surgir en la medida que el usuario se familiariza

con: las tecnología TIC y el sistema de información.

c) Cuando el usuario no tiene tiempo para participar en el proyecto, bien porque

evita participar en el proyecto, no está consciente de la importancia de su

participación ó no ve al sistema como algo que le pertenece.

d) Cuando existen problemas de comunicación, el cliente o usuario no entiende el

lenguaje informático de los analistas y los analistas no entienden el lenguaje del

dominio de la aplicación.

e) En el caso de existir múltiples interpretaciones de los requisitos, el analista

entiende y especifica de manera diferente los requisitos del cliente y el diseñador

interpreta de otra manera los requisitos especificados por el analista.

8) ¿Cuáles son las soluciones a los problemas presentados por los requisitos?

Aplicar la IR, la cual es una sub - disciplina de la Ingeniería del Software que se encarga

de estudiar los problemas asociados a los requisitos y proponer soluciones a estos

problemas. La IR establece métodos, modelos, técnicas, herramientas, prácticas, entre

otros para resolver los problemas de los requisitos.

9) ¿Cómo resolver los problemas de los requisitos?

a) Entender la naturaleza del software: La naturaleza del software promueve cambios

frecuentes en los requisitos.

b) Entender el espacio del problema antes de analizar el espacio de la solución:

Modelar el negocio antes de identificar y especificar requisitos.

c) Utilizar un proceso de Ingeniería de Requisitos bien definido y probado: Este

proceso debe describir como identificar, analizar, documentar, verificar y gestionar

requisitos. Debe ser parte del proceso de desarrollo de software.

d) Utilizar prácticas reconocidas (mejores prácticas), p.ej.:

• Incorporar al usuario en el desarrollo de la aplicación (participación activa)

• Modelar los requisitos usando notaciones gráficas estandarizadas

• Gestionar los requisitos

e) Emplear personal especializado que entienda los problemas de los requisitos:

Tales como Analistas de Negocios y Analistas de Requisitos.

10) Espacio del problema vs. Espacio de la solución


8

En la ingeniería del software existen dos espacios, el problema y la solución, el MN se encarga del espacio del problema – SN, (Las necesidades ocurren en el espacio del problema), y la IR se encarga del espacio de la solución - aplicación (Los requisitos tienen lugar en el espacio de la solución).

11) Soluciones a los problemas de los requisitos

El Modelo de las 6P contribuye, también, a resolver el problema de los requisitos. Este

modelo identifica factores críticos de éxito del desarrollo de software

12) Mejores prácticas de Ingeniería de Requisitos

La Ingeniería de Requisitos (IR) propone un conjunto de mejores prácticas que han

probado ser efectivas -Adaptado de Wiegers (2003)-

a) Prácticas asociadas al conocimiento de la IR

–Capacitar a los analistas en los temas técnicos de la IR

–Educar a los Representantes de Usuarios y Gerentes en la problemática y soluciones de

los requisitos. Concientizar sobre la necesidad de una IR

–Capacitar a los desarrolladores en el dominio de la aplicación (sistema de negocios)

–Crear un glosario de términos del sistema de negocios

b) Prácticas asociadas a la Gestión de Requisitos

–Definir un proceso para controlar los cambios de los requisitos

–Establecer un Comité encargado del control de cambios

–Llevar a cabo el análisis del impacto que cada cambio en los requisitos tiene sobre el

proyecto

–Establecer una línea base de requisitos y llevar control de las versiones

–Mantener históricos de cambios en los requisitos

–Hacerle seguimiento a los requisitos. Llevar las matrices de trazabilidad

–Medir la variabilidad de los requisitos

–Usar herramientas para gestionar requisitos

c) Prácticas asociadas a la Gestión del Proyecto

–Seleccionar un ciclo de vida o método de desarrollo apropiado

–Definir claramente el proceso de Ingeniería de Requisitos


9

–Basar los planes en los requisitos. Planes iterativos

–Renegociar los acuerdos de requisitos

–Manejar los riesgos de los requisitos

–Aprender de proyectos pasados (lecciones aprendidas)

d) Prácticas asociadas al Descubrimiento de Requisitos

–Definir la visión y el alcance del producto

–Identificar los tipos de usuarios

–Identificar casos de uso

–Identificar los eventos y respuestas de la aplicación

–Observar a los usuarios realizando sus actividades

–Reutilizar requisitos de otros proyectos similares

e) Prácticas asociadas al Análisis de Requisitos

–Establecer el contexto de la aplicación. Definir las relaciones entre la aplicación y su

dominio o sistema de negocios

–Crear prototipos

–Analizar la factibilidad de los requisitos

–Establecer las prioridades de los requisitos

–Modelar los requisitos. Crear modelos funcionales, estructural y dinámicos

–Crear un diccionario de datos. Definir los elementos contenidos en los modelos

–Asignar requisitos a los subsistemas de la aplicación. Relacionar los requisitos con la

arquitectura de la aplicación

f) Prácticas asociadas a la Especificación de Requisitos

–Adoptar una plantilla para elaborar el Documento de Requisitos. Usar preferiblemente

los estándares y adaptarlo a las necesidades de su organización

–Identificar las fuentes de los requisitos. ¿Quién propuso este requisito?

–Identificar cada requisito de manera única

–Registrar las reglas del negocio

–Especificar los atributos de calidad. Usar modelos de calidad para seleccionar los

requisitos apropiados a la aplicación. Especificar las métricas para medir los atributos

g) Prácticas asociadas a la Validación de Requisitos

–Inspeccionar el Documento de Requisitos (DR). Realizar la Revisión Técnica del DR

– Probar los requisitos. Diseñar las pruebas funcionales basadas en los requisitos

–Definir los criterios de aceptación. ¿Qué criterios usará el cliente o usuarios para aceptar

la aplicación?

Documents

Revisión de conceptos básicos clase IR