ANÁLISIS Y DISEÑO ORIENTADO A OBJETO

SEMANA 3
Técnicas de recopilación y análisis de requerimientos
Técnicas de recopilación y análisis de requerimientos

Técnicas de captura de requerimientos.

• Entrevista

• Encuesta

• Observación Directa
Técnicas de recopilación y análisis de requerimientos

Entrevista

• Forma más natural y rápida de comunicación con una persona.

• En informática la entrevista debe ir enfocada a aquellas personas que más

conocen sobre los procesos de la organización y a las personas que
utilizarán el sistema .

• Los requerimientos van a ir cambiando producto de la falta de entendimiento

que los clientes suelen tener sobre sus propios procesos.
Técnicas de recopilación y análisis de requerimientos

Encuesta

• Son documentos que tienen un conjunto de preguntas relevantes del sistema

que se desea construir.

• Se obtiene información más precisa sobre los puntos sobre los cuales
necesitamos una respuesta cerrada.

• Las encuestas puede llevar preguntas abiertas o de selección múltiple, en la

que los encuestados deberán seleccionar una alternativa.
Observación Directa.

• El encargado de la toma de requerimientos observa las personas mientras

realizan su trabajo.

• Se conoce cuáles son los procedimientos que se realizan, quiénes son los
encargados de hacerlos y cuál es el orden en el que se ejecutan.

• Observar, proceso que consiste en fijar la atención en un objeto o situación

para identificar sus características. La identificación ocurre en dos etapas:

• La primera concretar (primer contacto con el objeto)

• La segunda, abstracta (podemos predecir del objeto e imaginamos sus

características)
Observación

La observación permite identificar las características de

objetos, situaciones o sucesos a través de los cinco
sentidos; esto es, vista, olfato, oído, tacto y gusto.

La observación es la base de todos los procesos mentales

que realizamos.
Criterios que debe cumplir una observación.

 La observación es un proceso que consiste en identificar las

características presentes en los objetos. No se observa lo que los
objetos no tienen.

 Cada característica corresponde una variable.

 Antes de observar debemos plantear un objetivo.

 No es observación lo que uno se imagina o supone de los objetos,

estas son inferencias (lo lógico).

 Tampoco son observaciones los juicios de valor o las criticas que se

hacen acerca de los objetos, estas son evaluaciones.
Beneficios de una Buena
Administración de Requerimientos.

 Mejor control de proyectos complejos.

 Mejora en la calidad del software y en la satisfacción del

cliente.

 Reducción en los retrasos y en los costos del proyecto.

 Mejora en la comunicación del equipo.

 Facilita la conformidad con estándares y regulaciones.

Los Problemas de la Administración
de Requerimientos

 No son siempre obvios y tienen muchas fuentes.

 No son siempre fáciles de expresar en palabras.
 Hay muchos tipos diferentes a distintos niveles de detalle.
 El número puede llegar a ser inmanejable.
 Están relacionados a otros en una variedad de formas.
 Hay muchos interesados y partes responsables.
 Cambian.
 Pueden ser sensibles al tiempo.
Especificación de requerimientos
en lenguaje natural

Los requerimientos…

 se suelen especificar en lenguaje natural,

 se expresan de forma individual (p.ej.
esquemáticamente),
 se organizan de forma jerárquica (a distintos niveles
de detalle),
 a menudo, se numeran (para facilitar su gestión),
Especificación de requerimientos
en lenguaje natural

Los requerimientos han de ser…

claros y concretos
• (evitando imprecisiones y ambigüedades)
• p.ej. Uso de puntos suspensivos, etcétera…

concisos
• (sin rodeos ni figuras retóricas),

completos y consistentes,
Especificación de requerimientos
en lenguaje natural

Los requerimientos funcionales…

• deben estar redactados de tal forma que sean
comprensibles para usuarios sin conocimientos
técnicos avanzados (de Informática, se entiende),

• deben especificar el comportamiento externo del

sistema y evitar, en la medida de lo posible, establecer
características de su diseño,

• deben priorizarse (al menos, se ha de distinguir entre

requisitos obligatorios y requisitos deseables).
Especificación de requerimientos
en lenguaje natural

Los requerimientos no funcionales…

• han de especificarse cuantitativamente, siempre que

sea posible (para que se pueda verificar su
cumplimiento).
Especificación de requerimientos
en lenguaje natural

MAL
Para facilitar el uso del editor gráfico, se podrá activar y
desactivar una rejilla que permitirá alinear las figuras del
diagrama. Cuando se ajuste la figura al tamaño de la
pantalla, se reducirá el número de líneas de la rejilla para
que no se dificulte la visualización del diagrama.

¿Por qué?

Una mezcla de varios requisitos.

Especificación de requerimientos
en lenguaje natural

BIEN
El editor permitirá el uso de una rejilla de líneas horizontales y
verticales que aparecerán dibujadas tras el diagrama.

Justificación: La rejilla facilita la creación de diagramas

cuidados en los que las figuras se puedan alinear con facilidad.
(Manual Práctico de Usabilidad, sección 15.3).

¿Por qué?

Preciso, conciso y justificado correctamente.

Especificación de requerimientos
en lenguaje natural
Especificación de requerimientos
en lenguaje natural
Especificación de requerimientos
en lenguaje natural
Especificación de requerimientos
en lenguaje natural
¿Qué necesitamos para un requisito?
Una necesidad / problema

Al igual que ponemos los caballos delante del carro, pongamos

primero un problema, y después, una solución.

Busquemos un problema sencillo (en su concepción).

Por ejemplo una tienda de música on-line.

Descripción del Problema

• Quiero vender música a través de Internet.

• Los usuarios comprarán créditos para adquirir canciones.
• Los usuarios buscaran las canciones que deseen y las pagaran con créditos.
• Los usuarios tendrán algunos días para descargar en su ordenador las canciones
que hayan adquiridos.
• Quiero hacer ofertas generales.

 ¿ La solución serán un sistema de software?

 ¿Qué características debe tener este sistema para satisfacer las necesidades
de nuestro cliente?

A esto se le llama Ingeniería de Requisitos o Requerimientos.

Requisitos Funcionales

Los usuarios compraran créditos para adquirir canciones.

Pero no estrega mucha información.

Ejemplo

• El sistema debe registrar la información de los usuarios y los créditos

que poseen.

• El sistema debe permitir que los usuarios registrados compren

créditos y proporcionar las herramientas para que los usuarios
paguen.

Ahora que piensan ustedes¡¡¡¡¡¡

Requisitos Funcionales

1. Los usuarios buscaran las canciones que deseen y las pagaran con créditos.
2. El sistema debe almacenar información sobre las canciones que se pueden
adquirir y su precio en créditos.
3. El sistema debe permitir a los usuarios buscar y consultar la información sobre
las canciones.
4. El sistema debe permitir a un usuario adquirir una canción a cambio de una
cantidad de crédito.
5. Los usuarios tendrán algunos días para descargar en su ordenador las
canciones que hayan adquirido.
6. El sistema debe almacenar las canciones y la fecha, para saber durante cuanto
tiempo puede descargar dicha canciones.
7. El sistema debe permitir descargar las canciones que un usuario ha adquirido
mientras tenga tiempo.
8. Los usuarios tendrán algunos días para descargar en su ordenador las
canciones que hayan adquirido.
Requisitos NO funcionales

¿Qué se les ocurre? o ¿Qué debemos de considerar como No funcional?

1. El sistema debe visualizarse y funcionar correctamente en cualquier

navegador, especialmente en Internet Explorer, Mozilla, Chrome, Eged.

2. El sistema debe cumplir las disposiciones recogidas en la Ley Orgánica de

Datos personales y en el reglamento de medidas de seguridad.

3. El sistema no debe tardar mas de cinco segundo en mostrar las

resultados de una búsqueda. Si se supera este plazo, el sistema detiene la
búsqueda y muestra los resultados encontrados.
Técnicas de recopilación y análisis de requerimientos

Definición de actividades.

• Tomar cada uno de los procesos del cliente y dividirlo en actividades más
pequeñas, las cuales juntas y en algún orden en particular dan como
resultado alguna acción que deseamos convertir en software.
Problemas en ingeniería

Un problema en ingeniaría surge del deseo de transformar un estado de cosas

en otro. En ese sentido podemos graficar un problema según el esquema:

Un problema en ingeniería se puede ver

como la descripción de dos estados (A y
B) de una situación. El estado A es la
situación actual, mientras que el estado B
corresponde a la situación futura deseada.
La solución del problema es la
transformación T que lleva el estado A al
estado B.
Se ha representado un problema con el anillo exterior para dar cuenta que un problema
necesariamente requiere de dos situaciones, la actual que resulta insatisfactoria y la futura
esperada o deseada. En caso de no existir alguno de estos estados entonces no se estaría
frente a un problema.

Del mismo modo el círculo interior representa a la solución del problema, lo afecto a diseño
para nuestro contexto, que es aquello que permite la transformación del estado actual en el
deseado.
Ejemplo de un problema
Por ejemplo, si tenemos a una persona en una ribera de un río (estado A) y esa
persona desea estar en la ribera opuesta (estado B) entonces claramente
tenemos un problema.
La solución es aquel proceso, mecanismo, artefacto u otro que permita la
transformación del estado A en el estado B.

Formulación ampliada del problema

Una persona está en la ribera de un río (estado A) y desea estar en la ribera
opuesta (estado B) haciendo uso de un bote.

Enunciado así, el problema presentaría aspectos de una alternativa de solución (el uso del
bote). Cuando un problema presenta en su formulación características de una solución o
de una clase de soluciones, entonces es muy probable que se esté formulando
inadecuadamente.
El principal peligro detrás de la formulación estrecha es que limita el espacio de solución
con restricciones falsas. Así, es recomendable que la formulación de problemas sea lo más
amplia posible.
Espacio de Solución

El espacio de solución corresponde a aquel que hipotéticamente contendría todas

las soluciones posibles para un problema independiente de si el ingeniero las
visualiza o no.

Este espacio de solución es inicialmente infinito aunque, dependiendo de las

características de la formulación del problema y del conocimiento del ingeniero se
ve acotado por fronteras que lo delimitan.

Se identifican conceptualmente tres fronteras: las restricciones reales, las

restricciones ficticias y el conocimiento del ingeniero.

Las restricciones reales determinan una frontera sobre el espacio de solución que
limita las alternativas de solución a aquellas que cumplen con aquella o aquellas
restricciones.