INGENIERÍA DE

SOFTWARE I

PROCESO DE EDUCCIÓN
ESCUELA POLITÉCNICA NACIONAL

M.Sc. Ing. Raúl Córdova

2019

24/6/2019 1
 DEFINICIONES
 La etapa de educción de requisitos
tiene que ver con la obtención de la
información que finalmente permita
definir los requisitos.
 En esta etapa “el analista debe
educir el conocimiento acerca de
algún dominio de problema y, en
alguna medida, llegar a ser un
`experto´ en el dominio”.
(Loucopoulos and Karakostas, 1995).
24/6/2019 2
 DEFINICIONES
 Esta actividad recibe diversos nombres
como: elicitación, captura, determinación,
adquisición, obtención, aprehensión de
requisitos. La más aceptada es la de
Educción.
 “La educción de requisitos se define como
el proceso de identificar necesidades y
acercar las disparidades entre las
comunidades envueltas con el propósito
de definir requisitos” [Sei 1991].
24/6/2019 3
 DEFINICIONES
 [Saiedian and Dale 2000] definen la
educción de requisitos como “el proceso
específico de obtención, determinación,
extracción o exposición de los requisitos
software”.
 Según [Jitnah et al. 1995] “la educción es
llevar a la luz los requisitos, y análisis es
llevar a la luz las características de estos
requisitos”.

24/6/2019 4
 EL PROCESO DE EDUCCIÓN
 Igual que en el proceso de IR, hay
bastante ambigüedad y diferencias
de enfoques sobre las actividades del
proceso (o subproceso) de educción.
 Este proceso tiene como objetivo
identificar información que determine
las características deseadas del
sistema software.

24/6/2019 5
 EL PROCESO DE EDUCCIÓN
 Para ello es necesario considerar la información
acerca del dominio de aplicación y de los usuarios
del sistema software [Jitnah et al. 1995].
 El conocimiento del dominio ayuda al analista a
obtener un grado común de entendimiento del
mundo del usuario y facilita el proceso de captura
y especificación de requisitos, pues este
conocimiento puede ser reutilizado en futuras
especificaciones significando ahorros de tiempo y
costos [Bolton et al. 1993]

24/6/2019 6
 EL PROCESO DE EDUCCIÓN
 El proceso comprende:
– Entradas:
 Expertos del dominio.
 Literatura acerca del dominio.
 Aplicaciones software similares en otros
dominios.
 Estándares nacionales e internacionales que
condicionan el desarrollo de software en ese
dominio.
 Otras directivas de la organización que
albergará el sistema software.

24/6/2019 7
 EL PROCESO DE EDUCCIÓN
– Actividades:
 Identificar todas las fuentes de requisitos.
 Adquirir el conocimiento.
 Decidir sobre la relevancia del conocimiento
del problema.
 Entender el significado del conocimiento
elicitado y su impacto sobre los requisitos
del software.
– Entregables (productos):
 Modelos formales del dominio del problema.

24/6/2019 8
 TÉCNICAS DE EDUCCIÓN
1. Entrevista no estructurada:
– Es la más utilizada
– Es altamente dependiente de las destrezas y
conocimientos comunicacionales tanto del entrevistador
como del entrevistado.
– Es una interacción sistemática en la que no existe
estructura ni plan previo de objetivos, por lo que se la
utiliza generalmente en las primeras sesiones a modo de
orientación general.

24/6/2019 9
 TÉCNICAS DE EDUCCIÓN
1. Entrevista no estructurada:
– Puede utilizarse con todos los que tienen interés en el
desarrollo del producto.
– Se debe limitar el alcance de la sesión y evitar
profundizar en demasía sobre un problema en particular.
– Permite capturar gran cantidad de información, mucha
de ella imprevista, pero consume bastante tiempo.

24/6/2019 10
 TÉCNICAS DE EDUCCIÓN
2. Entrevista estructurada:
– En este tipo se realiza una preparación sobre el objetivo
y contenido de preguntas hechas a los entrevistados.
– Se debe formular y agrupar las cuestiones lógicamente
respecto de acciones o procesos que se han identificado
en sesiones previas.
– Consumen bastante tiempo de preparación.
– Pueden contener problemas de lenguaje como
ambigüedad.
– Son una excelente forma de profundizar en situaciones
particulares.

24/6/2019 11
 DINAMICA DE LA EDUCCION
 La educción consta de dos tareas:

1. La obtención de información de los

distintos participantes en la actividad
de requisitos.

2. La identificación de requisitos.

24/6/2019 12
 DINAMICA DE LA EDUCCION
 Aspectos del subproceso de educción:
– En qué estado o situación se inicia el
subproceso de educción.
– Cómo se obtiene información en los estados
iniciales de la educción.
– Cómo se identifican los requisitos entre la
información obtenida.
– Cómo se redactan los requisitos.
– Cómo se incrementa la información en las
sesiones posteriores de educción.
– Cuándo se finaliza la educción.

24/6/2019 13
 DINAMICA DE LA EDUCCION
 Inicio de la educción:
 Puede tener lugar en varios escenarios posibles
que son:
a) No se conoce absolutamente nada acerca del sistema
software a desarrollar.
b) Existe una idea, más o menos definida, y/o un
conjunto de objetivos que se sabe debe cumplir el
futuro sistema software.
c) Existe un documento de Concepto de Operaciones
(Concept of Operations – IEEE 1362-1998), que define
las funciones y restricciones, tanto generales como
particularizadas al software, que debe cumplir el
futuro sistema. Incluso en algunos casos, podría
existir una Especificación de Requisitos del Sistema
(IEEE-1233-1998).

24/6/2019 14
 DINAMICA DE LA EDUCCION
 El escenario a) es relativamente
infrecuente.
 En situaciones normales, alguien
(un comercial, el director de
proceso de datos, etc.) se habrá
puesto en contacto con alguna
persona (típicamente el cliente) y
obtenido cierta información acerca
del sistema a desarrollar, aunque
sea poca.

24/6/2019 15
 DINAMICA DE LA EDUCCION
 También es bastante infrecuente
comenzar en un escenario como el
descrito en c).
 Sólo tiene sentido utilizar un documento
de Concepto de Operaciones cuando el
software es únicamente una parte del
sistema más global a construir, hecho
que con frecuencia no es cierto, ya que
en muchos proyectos el SW es con
diferencia el componente principal del
producto a desarrollar.

24/6/2019 16
 DINAMICA DE LA EDUCCION
 Dicho de otro modo, lo normal
es comenzar en una situación
similar a la indicada en el
escenario b).

24/6/2019 17
 DINAMICA DE LA EDUCCION
 Obtención de la información inicial:
 En el escenario b), sólo existe realmente
una alternativa para obtener
información: la utilización de entrevistas,
típicamente no estructuradas, para
obtener algún tipo de información.
 Dichas entrevistas son llevadas a cabo
por analistas experimentados y, de ser
posible, conocedores del dominio, con la
finalidad de extraer la mayor cantidad de
información posible, y de la mayor
calidad.

24/6/2019 18
 DINAMICA DE LA EDUCCION
 Esta estrategia inicial es mejorable.
 Siempre será beneficioso contar con
analistas con un amplio
conocimiento del dominio, pero la
experiencia no es un factor
fundamental de éxito.
 Es mucho más importante, por el
contrario, planificar
cuidadosamente las entrevistas.

24/6/2019 19
 DINAMICA DE LA EDUCCION
 No es sencillo planificar una entrevista
en un estado tan inicial del subproceso
de educción.
 Una solución del compromiso es utilizar
lo que se conoce como “preguntas
independientes del contexto”, como se
muestran a continuación, las cuales
permiten imponer una ligera
estructuración a la entrevista aun en
ausencia de conocimiento específico del
dominio.

24/6/2019 20
 DINAMICA DE LA EDUCCION
1. ¿Qué objetivos persigue con el desarrollo del ‘sistema’?
2. ¿En qué tipos de tareas/actividades de la organización
debe ayudar el ‘sistema’?
3. ¿Qué beneficios espera obtener?
4. ¿Qué tareas debe realizar el nuevo ‘sistema’?
5. ¿Qué usuarios deberán utilizar el nuevo ‘sistema’?
6. ¿Qué personas, además de los usuarios, también podrían
usar el nuevo “sistema”?.
7. ¿Debe el nuevo ‘sistema’ interactuar con otros sistemas
software preexistentes o que se implementarán en el
futuro?
8. ¿Debe el nuevo ‘sistema’ interactuar con otros sistemas
hardware, bases de datos, etc. preexistentes o que se
implementarán en el futuro?
9. ¿Existe alguna restricción de tiempo para el desarrollo del
‘sistema’?
10. ¿Existe alguna restricción (estándar, regulación, etc.) que
deba tomarse en cuenta para el desarrollo del ‘sistema’?21
24/6/2019
 DINAMICA DE LA EDUCCION
 Por preguntas independientes
del contexto se entiende un
conjunto de cuestiones de
aplicabilidad general, las cuales
pueden plantearse para
prácticamente cualquier tipo de
sistema software.

24/6/2019 22
 DINAMICA DE LA EDUCCION
 Son preguntas que pretenden
obtener información acerca del
sistema de forma top-down,
avanzando desde los objetivos
de mayor nivel a las tareas o
características concretas del
software.

24/6/2019 23
 DINAMICA DE LA EDUCCION
 Adicionalmente, las preguntas
anteriores pretenden también
identificar otros aspectos del
sistema, tales como sus
interfaces y cualesquiera
restricciones que puedan
aplicarse.

24/6/2019 24
 DINAMICA DE LA EDUCCION
 Un aspecto de especial interés es el
planteado en las preguntas 5 y 6:
qué usuarios utilizarán, o se verán
afectados, por el nuevo sistema
software.
 Estas preguntas son especialmente
relevantes debido a que, por norma
general, al inicio de la educción sólo
son conocidos los clientes, pero
muy pocos usuarios.

24/6/2019 25
 DINAMICA DE LA EDUCCION
 Las preguntas anteriores están
orientadas a personal de los niveles
organizativos superiores, esto es,
los típicos clientes.
 Las preguntas 5 y 6 permiten, por
consiguiente, ampliar los horizontes
de búsqueda al identificar nuevos
usuarios de los que extraer
información.

24/6/2019 26
 DINAMICA DE LA EDUCCION
 Una vez que se han identificado unos
pocos usuarios relevantes, podría
continuarse con ellos la adquisición de la
información inicial, utilizando las
preguntas independientes de contexto
que se indican a continuación.
 Estas preguntas, a diferencia de las
anteriores, están dirigidas a personal de
nivel inferior, esto es, los típicos usuarios
en ámbitos organizativos.

24/6/2019 27
 DINAMICA DE LA EDUCCION
1. ¿Conoce los planes de la dirección para desarrollar un
sistema que realice ‘característica particular’?
2. Estamos estudiando el modo de desarrollar el sistema, y
necesitamos de su colaboración. ¿Podría ayudarnos?
¿Cómo cree que podría ayudarle el nuevo sistema en sus
tareas?
3. Una vez identificadas algunas tareas, preguntar:
a. ¿Qué recibe Ud. para realizar la ‘tarea’? ¿De dónde?
b. ¿Qué genera Ud. al finalizar la ‘tarea’? ¿A quién se lo envía?
c. ¿Archiva Ud. algo?
d. ¿Interviene alguien más en la ‘tarea’, aunque sea
esporádicamente?
4. ¿Cree Ud. que es necesario hablar con otra persona para
averiguar más cosas acerca de ‘característica particular’?

24/6/2019 28
 DINAMICA DE LA EDUCCION
 Estas preguntas difieren en
intención a las anteriores.
 Persiguen identificar los detalles
procedimentales de los aspectos de
interés del sistema, centrándose en
las tareas a realizar y los datos (de
entrada, salida o almacenamiento)
a utilizar.

24/6/2019 29
 DINAMICA DE LA EDUCCION
 Una vez que las primeras
entrevistas han tenido lugar, es
necesario:
1. Identificar en la información extraída
los requisitos del software.
2. Redactar los requisitos de forma
adecuada.
3. Seguir adquiriendo información hasta
que pueda darse por concluida la
educción.

24/6/2019 30
 IDENTIFICACIÓN DE
REQUISITOS
 Problema habitual: decidir, entre toda la
información obtenida, qué es un
requisito y qué no.
 Ello se conseguiría si clientes y usuarios
fuesen capaces de expresar de forma
precisa y completa sus necesidades.
 Si fuera así, el analista se restringiría a
localizar en el conjunto de información
obtenida, los requisitos del software.

24/6/2019 31
 IDENTIFICACIÓN DE
REQUISITOS
 En la práctica, clientes y usuarios poseen una
idea mucho menos definida de lo que necesitan,
o, al menos, no expresan ésta tan claramente.
 Durante la educción se producen toda una serie
de problemas de comunicación, que nacen de la
incapacidad de los clientes/usuarios para
expresar sus necesidades.
 Se agravan en la dificultad de comunicar dichas
necesidades a un tercero como es el analista, y
se complican finalmente en la propia
incapacidad del analista en entender lo que
realmente necesitan los clientes/usuarios.

24/6/2019 32
 IDENTIFICACIÓN DE
REQUISITOS
 Debido a los problemas
mencionados, no puede
considerarse que el papel del
analista sea únicamente el de un
simple recolector de información
sino que, muy al contrario, debe
desempeñar un papel activo,
construyendo en muchos casos los
requisitos del software.
24/6/2019 33
 IDENTIFICACIÓN DE
REQUISITOS
 Para poder construir o sugerir los
requisitos del software, es
necesario un amplio conocimiento
del dominio de los
clientes/usuarios.
 Cuanto mayor conocimiento,
mayores son las posibilidades de
éxito del proyecto.

24/6/2019 34
 IDENTIFICACIÓN DE
REQUISITOS
 Para ilustrar esto, supongamos el
fragmento de entrevista mostrado
en el Cuadro 3. Todas las frases
subrayadas son potenciales
requisitos que debe implementar un
supuesto sistema para la gestión de
una biblioteca universitaria.

24/6/2019 35
 IDENTIFICACIÓN DE
REQUISITOS
P: ¿Cuáles son sus ocupaciones principales?
R: Me encargo de la catalogación de libros, las reservas,
préstamos y devoluciones y de mantener el orden en la
sala de lectura.

P: ¿En qué consiste la catalogación?

R: Cada vez que se compra un libro se debe registrar en el
fondo bibliográfico. Lo que hago es confeccionar las fichas
del archivo con sus copias y colocar el libro en la
estantería.

P: ¿Quién compra los libros?

R: Pues depende. Normalmente es por encargo de profesores.

CUADRO 3

24/6/2019 36
 IDENTIFICACIÓN DE
REQUISITOS
 En el Cuadro anterior se pueden
distinguir cuatro requisitos distintos: que
el sistema debe permitir la catalogación
de los libros y realizar reservas,
préstamos y devoluciones.
 Supondremos que la referencia al
registro de los fondos bibliográficos es
equivalente a la catalogación de los
libros y se tratan de un único requisito.

24/6/2019 37
 IDENTIFICACIÓN DE
REQUISITOS
 Nótese que dichos requisitos existen
únicamente en la mente del analista, ya
que en ningún momento el usuario
entrevistado indica que necesita un
soporte automatizado para el catálogo
de los libros, o para la realización de
reservas.
 Muy al contrario, el usuario está
hablando únicamente del trabajo que
realiza a diario.
24/6/2019 38
 IDENTIFICACIÓN DE
REQUISITOS
 Es únicamente el conocimiento que
el analista tiene de la informática,
unido a su conocimiento del
funcionamiento de las bibliotecas,
lo que lo llevan a enunciar como
requisitos los anteriormente
indicados.

24/6/2019 39
 IDENTIFICACIÓN DE
REQUISITOS
 Pero surge la pregunta: hasta qué punto
los requisitos obtenidos de este modo
representan las necesidades de los
clientes/usuarios?
 En primer lugar, el conocimiento del
dominio que debe tener el analista le
permite suponer de forma bastante
fidedigna las necesidades de los
clientes/usuarios.

24/6/2019 40
 IDENTIFICACIÓN DE
REQUISITOS
 En segundo lugar, todos los
requisitos tienen que ser validados,
incluso aquellos solicitados
explícitamente.
 Entonces, durante la actividad de
Validación de requisitos será
cuando se determine si dichos
requisitos son adecuados o no.

24/6/2019 41
 REDACCIÓN DE LOS
REQUISITOS
 Deben estar expresados en la forma más
precisa posible, en algún lenguaje
entendido por todas las partes.
 Cualquier tipo de formalismo sería válido:
– Lenguajes formales, como Z o VDM. Usar en
sistemas críticos.
– Lenguajes semi-formales y modelos gráficos,
tales como DFD, caso de uso, etc.
– Lenguaje natural.

24/6/2019 42
 REDACCIÓN DE LOS
REQUISITOS
 Dado que los principales participantes del
proceso de requisitos son el analista y los
clientes/usuarios, el formalismo de
expresión más frecuente es el lenguaje
natural.
 Los requisitos no se pueden expresar de
cualquier forma.
 Existen recomendaciones para redactar los
requisitos del software:

24/6/2019 43
 REDACCIÓN DE LOS
REQUISITOS
 La forma más usual es utilizar frases
cortas, las cuales típicamente comienzan
por “El sistema permitirá…” o alguna
variante.
– Ej. El sistema permitirá registrar los datos
identificativos y contables de los clientes.
– Ej: El sistema deberá generar un listado de
facturas impagadas por un periodo mayor de
15 días. El listado deberá imprimirse los lunes
a las 7:00

24/6/2019 44
 REDACCIÓN DE LOS
REQUISITOS
 Ej: La consulta de un artículo en stock
debe proporcionar los datos requeridos en
un tiempo menor que 0.5 segundos.
 Ej. El sistema deberá funcionar en
entornos windows (todas versiones
posteriores a 1999) y Unix System V.
 Ej. El acceso a los datos personales
deberá cumplir las normas especificadas
en la Ley de Datos Personales.

24/6/2019 45
 REDACCIÓN DE LOS
REQUISITOS
 Los requisitos no tienen por qué
expresarse de forma universal. Es
necesario:
– Decir lo que el sistema no va a hacer.
 Ej:
El sistema determinará la cantidad de
reposición óptima de los productos en
almacén. Sin embargo, el sistema no
generará de forma automática la orden de
pedido a proveedores.

24/6/2019 46
 REDACCIÓN DE LOS
REQUISITOS
 Indicar excepciones, restricciones.
– Ej: El sistema emitirá un balance de
cuentas los días laborables, esto es, de
lunes a sábado. El listado no se emitirá
automáticamente, sino que un operador
dará la orden de impresión.

24/6/2019 47
 REDACCIÓN DE LOS
REQUISITOS
– Proponer ejemplos:
 Ej:El sistema validará los datos de entrada.
Por ejemplo, si el código postal es
incorrecto, el sistema emitirá un mensaje de
error inteligible y pedirá que se repita la
entrada. Lo mismo deberá ocurrir con el
resto de los campos validables (dirección,
teléfono, etc.)

24/6/2019 48
 REDACCIÓN DE LOS
REQUISITOS
 El nivel de detalle requerido en la
redacción es variable, y depende de
varios factores ajenos a los
requisitos en si mismos:
– Complejidad del software.
– Conocimiento del dominio del equipo de
trabajo.
– Libertad de los desarrolladores a la hora
de proponer alternativas de solución.
24/6/2019 49
 REDACCIÓN DE LOS
REQUISITOS
 El efecto de esos factores es el esperado.
 A mayor complejidad del software, mayor
necesidad de detalle en los requisitos, y
viceversa.
 Cuanto mayor sea el conocimiento del
dominio por parte del equipo de trabajo,
menor la necesidad de proveer detalle en
la especificación de requisitos (ya que el
conocimiento del dominio permite al
equipo de trabajo suponer el detalle
ausente) y viceversa.
24/6/2019 50
 REDACCIÓN DE LOS
REQUISITOS
 Un factor que no se acostumbra a
discutir es el grado de libertad del
equipo de trabajo.
 Ello ocurre cuando el cliente/usuario
desea un software que proporcione
una serie de funciones, pero no tiene
preferencias acerca de los detalles.

24/6/2019 51
 REDACCIÓN DE LOS
REQUISITOS
 En este caso, la especificación no puede
ser muy detallada, precisamente por la
ausencia de detalle proporcionado por el
cliente/usuario.
 Alternativamente, cuando el
cliente/usuario desea un software muy
específico, el detalle debe registrarse
necesariamente en la especificación de
requisitos, incluyendo todos aquellos
aspectos referidos al interfaz de usuario,
los cuales acostumbran a pasarse por alto
con frecuencia.

24/6/2019 52