INGENIERIA DEL SOFTWARE II TRAYECTO III

FUNDAMENTOS DE INGENIERA DE REQUISITOS Y ANLISIS

UNIDAD II
ESPECIFICACIN DE REQUERIMIENTOS
CONTENIDO
1. Introduccin
2. Lenguaje Unificado de Modelado UML,
2.1.
Concepto
2.2.

Modelamiento de Clases

2.3.

Casos de Uso

2.4.

Diagrama de Interaccin

3. Tcnicas para escribir requerimientos de alta calidad.

4. Estndares de Documentacin.
5. Tipos de requerimientos:
5.1.
funcionales,
5.2.
no-funcionales,
5.3.
del dominio,
6. Atributos y medidas de calidad del software
6.1.
Atributos de calidad en operacin
6.2.
Atributos de calidad en desarrollo
6.3.
Atributos de calidad en implementacin
1.- INTRODUCCIN
La especificacin de requerimientos de software (ERS) es una
descripcin completa del comportamiento del sistema que se va a
desarrollar. Incluye un conjunto de casos de uso que describe todas
las interacciones que tendrn los usuarios con el software. Los casos
de uso tambin son conocidos como requisitos funcionales. Adems
de los casos de uso, la ERS tambin contiene requisitos no
funcionales (o complementarios). Los requisitos no funcionales son
requisitos que imponen restricciones en el diseo o la
implementacin, como, por ejemplo, restricciones en el diseo o
estndares de calidad.
Est dirigida tanto al cliente como al equipo de desarrollo. El lenguaje
utilizado para su redaccin debe ser informal, de forma que sea
fcilmente comprensible para todas las partes involucradas en el
desarrollo.
2.- LENGUAJE UNIFICADO DE MODELADO UML

Una exigencia de la gran mayora de instituciones dentro de su Plan

Informtico estratgico, es que los desarrollos de software bajo una
arquitectura en Capas, se formalicen con un lenguaje estndar y
unificado.
Es decir, se requiere que cada una de las partes que comprende el
desarrollo de todo software de diseo orientado a objetos, se
visualice, especifique y documente con lenguaje comn.
Se necesitaba un lenguaje que fuese grfico, a fin de especificar y
documentar un sistema de software, de un modo estndar incluyendo
aspectos conceptuales tales como procesos de negocios y funciones
del sistema.
Este lenguaje unificado que cumple con estos requerimientos, es
ciertamente UML, el cual cuenta con una notacin estndar y
semnticas esenciales, para el modelado de un sistema orientado a
objetos.
2.1.-Concepto de UML
El Lenguaje de Modelamiento Unificado (UML - Unified Modeling
Language) es un lenguaje grfico para visualizar, especificar y
documentar cada una de las partes que comprende el desarrollo de
software. UML entrega una forma de modelar cosas conceptuales
como lo son procesos de negocio y funciones de sistema, adems de
cosas concretas como lo son escribir clases en un lenguaje
determinado, esquemas de base de datos y componentes de software
reusables.
Es un lenguaje para especificar, construir, visualizar y documentar los
artefactos de un sistema de software orientado a objetos (OO). Un
artefacto es una informacin que es utilizada o producida mediante
un proceso de desarrollo de software.
UML no es un mtodo de desarrollo, lo que significa que no sirve para
determinar qu hacer en primer lugar o cmo disear el sistema, sino
que simplemente le ayuda a visualizar el diseo y a hacerlo ms
accesible para otros. UML est controlado por el grupo de
administracin de objetos (OMG) y es el estndar de descripcin de
esquemas de software.
UML est diseado para su uso con software orientado a objetos, y
tiene un uso limitado en otro tipo de cuestiones de programacin.

El UML es una tcnica de modelado de objetos y como tal supone

una abstraccin de un sistema para llegar a construirlo en trminos

concretos. El modelado no es ms que la construccin de un modelo a

partir de una especificacin.
Un modelo es una abstraccin de algo, que se elabora para
comprender ese algo antes de construirlo. El modelo omite detalles
que no resultan esenciales para la comprensin del original y por lo
tanto facilita dicha comprensin.
Los modelos se utilizan en muchas actividades de la vida humana:
antes de construir una casa el arquitecto utiliza un plano, los msicos
representan la msica en forma de notas musicales, los artistas
pintan sobre el lienzo con carboncillos antes de empezar a utilizar los
leos, etc. Unos y otros abstraen una realidad compleja sobre unos
bocetos, modelos al fin y al cabo.
2.2.- Modelo de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las
clases que involucran el sistema, las cuales pueden ser asociativas,
de herencia, de uso y de contenimiento.
Un diagrama de clases est compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y
Uso.

Elementos

Clase
Una clase define los atributos y los mtodos de una serie de
objetos. Todos los objetos de esta clase (instancias de esa clase)
tienen el mismo comportamiento y el mismo conjunto de
atributos (cada objetos tiene el suyo propio).
Es la unidad bsica que encapsula toda la informacin de
un Objeto (un objeto es una instancia de una clase). A travs
de ella podemos modelar el entorno en estudio (una Casa, un
Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee
tres divisiones:

En donde:
o Superior: Contiene el nombre de la Clase
o Intermedio: Contiene los atributos (o variables de
instancia) que caracterizan a la Clase (pueden ser private,
protected o public).
o Inferior: Contiene los mtodos u operaciones, los cuales
son la forma como interacta el objeto con su entorno
(dependiendo de la visibilidad: private, protected o
public).
Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
o Balance
Puede realizar las operaciones de:
o Depositar
o Girar
o y Balance
El diseo asociado es:

Atributos y Mtodos:
o Atributos:
En UML, los atributos se muestran al menos con su nombre, y
tambin pueden mostrar su tipo, valor inicial y otras
propiedades. Los atributos tambin pueden ser mostrados
visualmente:

Los atributos o caractersticas de una Clase pueden ser de

tres tipos, los que definen el grado de comunicacin y
visibilidad de ellos con el entorno, estos son:

public (+,
): Indica que el atributo ser visible
tanto dentro como fuera de la clase, es decir, es
accesible desde todos lados.

private (-,
): Indica que el atributo slo ser
accesible desde dentro de la clase (slo sus
mtodos lo pueden accesar).

protected (#,
): Indica que el atributo no ser
accesible desde fuera de la clase, pero si podr ser
accesado por mtodos de la clase adems de las
subclases que se deriven (ver herencia).

o Mtodos:
Los mtodos u operaciones de una clase son la forma en
como sta interacta con su entorno, stos pueden tener
las caractersticas:

public (+, ): Indica que el mtodo ser visible

tanto dentro como fuera de la clase, es decir, es
accesible desde todos lados.

private (-,
): Indica que el mtodo slo ser
accesible desde dentro de la clase (slo otros
mtodos de la clase lo pueden accesar).

protected (#,
): Indica que el mtodo no ser
accesible desde fuera de la clase, pero si podr ser
accesado por mtodos de la clase adems de
mtodos de las subclases que se deriven (ver
herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar
cmo se pueden interrelacionar dos o ms clases (cada uno con
caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de
relaciones:
Existen muchas definiciones de cardinalidad, aunque todas vienen a
decir lo mismo:

a. es el nmero de veces que una entidad aparece

asociada a otra entidad.
b. es el nmero de ocurrencias de entidad que se pueden
asociar a otra a travs de una relacin.
c. Nmero de instancias o elementos de una entidad que
pueden asociarse a un elemento de la otra entidad
relacionada

En UML, la cardinalidad de las relaciones indica el grado

y nivel de dependencia, se anotan en cada extremo de la
relacin y stas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
nmero fijo: m (m denota el nmero).
i.

Relaciones:

Herencia

(Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos
especificados por una Sper Clase, por ende la Subclase
adems de poseer sus propios mtodos y atributos,
poseer las caractersticas y atributos visibles de la Sper
Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camin heredan de

Vehculo, es decir, Auto posee las Caractersticas de
Vehculo (Precio, VelMax, etc) adems posee algo
particular que es Descapotable, en cambio Camin
tambin hereda las caractersticas de Vehculo (Precio,
VelMax, etc) pero posee como particularidad propia
Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo nico

"visible" es el mtodo Caractersticas aplicable a
instancias de Vehculo, Auto y Camin, pues tiene
definicin
pblica,
en
cambio
atributos
como
Descapotable no son visibles por ser privados.
ii

Relaciones: Agregacin:
Para modelar objetos complejos, no bastan los tipos de
datos bsicos que proveen los lenguajes: enteros, reales y
secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el
desarrollador de la aplicacin, tenemos dos posibilidades:
i. Por Valor: Es un tipo de relacin esttica, en
donde el tiempo de vida del objeto incluido est
condicionado por el tiempo de vida del que lo
incluye. Este tipo de relacin es comnmente
llamada Composicin (el Objeto base se
construye a partir del objeto incluido, es decir, es
"parte/todo").
ii. Por Referencia: Es un tipo de relacin
dinmica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este
tipo de relacin es comnmente llamada
Agregacin (el objeto base utiliza al incluido
para su funcionamiento).
Un Ejemplo es el siguiente:

En donde se destaca que:

iii. Un Almacn posee Clientes y Cuentas (los
rombos van en el objeto que posee las
referencias).
iv. Cuando se destruye el Objeto Almacn tambin
son destruidos los objetos Cuenta asociados, en
cambio no son afectados los objetos Cliente
asociados.
v. La composicin (por Valor) se destaca por un
rombo relleno.

vi. La agregacin (por Referencia) se destaca por un

rombo transparente.
La flecha en este tipo de relacin indica la navegabilidad
del objeto referenciado. Cuando no existe este tipo de
particularidad la flecha se elimina.
iii

Asociacin:
La relacin entre clases conocida como Asociacin,
permite asociar objetos que colaboran entre s. Cabe
destacar que no es una relacin fuerte, es decir, el tiempo
de vida de un objeto no depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas rdenes de

Compra, en cambio una orden de compra solo puede
tener asociado un cliente.
iv

Dependencia o Instanciacin (uso):

Representa un tipo de relacin muy particular, en la que
una clase es instanciada (su instanciacin es dependiente
de otro objeto/clase). Se denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para
denotar la dependencia que tiene una clase de otra, como
por ejemplo una aplicacin grafica que instancia una
ventana (la creacin del Objeto Ventana est
condicionado a la instanciacin proveniente desde el
objeto Aplicacin):

Cabe destacar que el objeto creado (en este caso la

Ventana grfica) no se almacena dentro del objeto que lo
crea (en este caso la Aplicacin).
Casos Particulares:
o Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y

de los mtodos con letra "itlica". Esto indica que la clase
definida no puede ser instanciada pues posee mtodos
abstractos (an no han sido definidos, es decir, sin
implementacin). La nica forma de utilizarla es
definiendo subclases, que implementan los mtodos
abstractos definidos.
o Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en

el extremo superior de la clase, en donde se especifican
los parmetros que deben ser pasados a la clase para que
esta pueda ser instanciada. El ejemplo ms tpico es el
caso de un Diccionario en donde una llave o palabra tiene
asociado un significado, pero en este caso las llaves y
elementos pueden ser genricos. La genericidad puede
venir dada de un Template (Plantilla o Patrn de diseo)
(como en el caso de C++) o bien de alguna estructura
predefinida (especializacin a travs de clases).
En el ejemplo no se especificaron los atributos del
Diccionario, pues ellos dependern exclusivamente de la
implementacin que se le quiera dar.
Ejemplo:
Supongamos que tenemos un el caso del Diccionario implementado
mediante un rbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la bsqueda, puede ser

genrica.

tem: Contenido a almacenar en el diccionario asociado a "key",

cuyo tipo tambin puede ser genrico.

Para este caso particular hemos definido un Diccionario para

almacenar String y Personas, las cuales pueden funcionar como llaves
o como tem, solo se mostrarn las relaciones para la implementacin

del

Diccionario:

2.3.- Casos de Uso (Use Case)

El diagrama de casos de uso representa la forma en como un Cliente
(Actor) opera con el sistema en desarrollo, adems de la forma, tipo y
orden en como los elementos interactan (operaciones o casos de
uso).
Un diagrama de casos de uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario

juega con respecto al sistema. Es importante destacar el uso de
la palabra rol, pues con esto se especifica que un Actor no
necesariamente representa a una persona en particular, sino
ms bien la labor que realiza frente al sistema.
Como ejemplo a la definicin anterior, tenemos el caso de un
sistema de ventas en que el rol de Vendedor con respecto al
sistema puede ser realizado por un Vendedor o bien por el Jefe
de Local.

Caso de Uso:

Relaciones:

Es una operacin/tarea especfica que se realiza

tras una orden de algn agente externo, sea
desde una peticin de un actor o bien desde la
invocacin desde otro caso de uso
o Asociacin
Es el tipo de relacin ms bsica que indica la invocacin
desde un actor o caso de uso a otra operacin (caso de
uso). Dicha relacin se denota con una flecha simple.
o Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en
la cual una clase depende de otra, es decir, se instancia
(se crea). Dicha relacin se denota con una flecha
punteada.

o Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple
una doble funcin dependiendo de su estereotipo, que
puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>).
Este tipo de relacin est orientado exclusivamente para
casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso
es similar a otro (caractersticas).
Uses (o Include versin nueva de UML): Se
recomienda utilizar cuando se tiene un conjunto de
caractersticas que son similares en ms de un caso de
uso y no se desea mantener copiada la descripcin de la
caracterstica.
De lo anterior cabe mencionar que tiene el mismo
paradigma en diseo y modelamiento de clases, en donde
est la duda clsica de usar o heredar.
Ejemplo:
Como ejemplo est el caso de una Mquina Recicladora: Sistema que
controla una mquina de reciclamiento de botellas, Tarros (frascos de
vidrio o plstico) y jabas (contenedores de plstico). El sistema debe
controlar y/o aceptar:

Registrar el nmero de tems ingresados.

Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado
b. El valor de cada tem
c. Total

El usuario/cliente presiona el botn de comienzo

Existe un operador que desea saber lo siguiente:

a. Cuantos tems han sido retornados en el da.
b. Al final de cada da el operador solicita un resumen de
todo lo depositado en el da.

El operador debe adems poder cambiar:

a. Informacin asociada a tems.
b. Dar una alarma en el caso de que:
i.

tem se atora.

ii.

No hay ms papel.

Como una primera aproximacin identificamos a los actores que

interactan con el sistema:

Luego, tenemos que un Cliente puede Depositar items y un Operador

puede cambiar la informacin de un tem o bien puede Imprimir un
informe:

Adems podemos notar que un tem puede ser una Botella, un Tarro o
una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser

realizada despus de depositar algn tem por un cliente o bien
puede ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:

2.4.- Diagrama de Interaccin

Introduccin
El diagrama de interaccin, representa la forma en como un Cliente
(Actor) u Objetos (Clases) se comunican entre s en peticin a un
evento. Esto implica recorrer toda la secuencia de llamadas, de donde
se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama
Esttico de Clases o el de Casos de Uso (son diferentes).
Los componentes de un diagrama de interaccin son:

Un Objeto o Actor.

Mensaje de un objeto a otro objeto.

Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectngulo representa una instancia de un Objeto en

particular, y la lnea punteada representa las llamadas a
mtodos del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa

la llamada de un mtodo (operacin) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a mtodos de objetos externos pueden

realizarse, tambin es posible visualizar llamadas a mtodos
desde el mismo objeto en estudio.
Ejemplo
En el presente ejemplo, tenemos el diagrama de interaccin
proveniente del siguiente modelo esttico:

Aqu se representa una aplicacin que posee una Ventana grfica, y

sta a su vez posee internamente un botn.
Entonces el diagrama de interaccin para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre

objetos) y la llamada a Paint() por el objeto Botn.
3.- TECNICAS PARA ESCRIBIR REQUERIMIENTOS DE ALTA
CALIDAD.
En todas las tcnicas involucradas descritas en la unidad I de la
ingeniera de requerimientos, las actividades y caractersticas
resaltantes para obtener o escribir requerimientos de alta calidad son
los siguientes.
Identificar las clases de usuario del producto esperado.
Extraer las necesidades de los individuos que representan
cada clase de usuario.
Comprender las tareas y metas del usuario y los objetivos
de negocio con los que esas tareas se alinean.
Analizar la informacin recibida de los usuarios para
distinguir sus objetivos de tarea de requerimientos
funcionales, requerimientos no-funcionales, reglas de
negocio, y otros
Destinar partes de los requerimientos de alto nivel a
definir componentes de software en la arquitectura
sistema.
Comprender la importancia de los atributos de calidad.
Negociar las prioridades de implementacin.
Traducir las necesidades de usuario escritas dentro de las
especificaciones y modelos de requerimientos

 Examinar los requerimientos documentados para

asegurar el conocimiento comn de los requerimientos
presentados por los usuarios y corregir cualquier
problema antes de que el grupo de desarrolladores los
acepte.
Definir el punto de partida de los requerimientos.
Revisar y evaluar el impacto de cada requerimiento
cambiado antes de aprobarlo.
Seguir cada requerimiento en su diseo, cdigo fuente y
pruebas.
Agrupar los requerimientos segn rendimiento y actividad
de cambio durante todo el proyecto.
La iteracin es una clave para el xito del desarrollo de
los requerimientos.
4.ESTNDARES
REQUERIMIENTOS.

DE

LA

DOCUMENTACIN

DE

LOS

El documento de los requerimientos de software es la declaracin

oficial de qu es lo que requieren los desarrolladores del sistema.
Incluye tanto los requerimientos del usuario para el sistema como una
especificacin detallada de los requerimientos del sistema. En
algunos casos, los dos tipos de requerimientos se integran en una
nica descripcin. En otros, los del usuario se definen en una
introduccin de la especificacin de los del sistema. Si existe un gran
nmero de requerimientos, los detalles de los requerimientos del
sistema se pueden presentar como documentos separados.
El documento de requerimientos tiene un conjunto diverso de
usuarios que va desde los administradores principales de la
organizacin, quienes pagan por el sistema, hasta los ingenieros
responsables del software. Una gran variedad de organizaciones han
definido estndares para los documentos de requerimientos. Por
ejemplo la IEEE sugiere la siguiente estructura para los documentos
de requerimientos.
1. Introduccin, propsito del documento de requerimientos, Alcance
del producto, Definiciones, acrnimos y abreviaturas, Referencias,
Resumen del resto del documento.
2. Descripcin general, Perspectiva del producto, Funciones del
producto, caractersticas del usuario, Restricciones generales,
Suposiciones y dependencias
3. Requerimientos especficos. Cubren los requerimientos funcionales,
no funcionales y de interfaz. Obviamente, sta es la parte ms

sustancial del documento, pero debido a la amplia variabilidad en la

prctica organizacional, no es apropiado definir una estructura
estndar para esta seccin. Los requerimientos pueden documentar
las interfaces externas, describir la funcionalidad y el desempeo del
sistema, especificar los requerimientos lgicos de la base de datos,
las restricciones de diseo, las propiedades emergentes del sistema y
las caractersticas de calidad.
5.- TIPOS DE REQUERIMIENTOS
5.1- Requerimientos funcionales
Son declaraciones de los servicios que proveer el sistema, de la
manera en que ste reaccionar a entradas particulares. En algunos
casos, los requerimientos funcionales de los sistemas tambin
declaran explcitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la
funcionalidad o los servicios que se espera que ste provea. Estos
dependen del tipo de software y del sistema que se desarrolle y de los
posibles usuarios del software. Cuando se expresan como
requerimientos del usuario, habitualmente se describen de forma
general mientras que los requerimientos funcionales del sistema
describen con detalle la funcin de ste, sus entradas y salidas,
excepciones, etc.
Muchos de los problemas de la ingeniera de software provienen de la
imprecisin en la especificacin de requerimientos. Para un
desarrollador de sistemas es natural dar interpretaciones de un
requerimiento ambiguo con el fin de simplificar su implementacin.
Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al
sistema, retrasando la entrega de ste e incrementando el costo.
En principio, la especificacin de requerimientos funcionales de un
sistema debe estar completa y ser consistente. La complecin
significa que todos los servicios solicitados por el usuario estn
definidos. La consistencia significa que los requerimientos no tienen
definiciones contradictorias. En la prctica, para sistemas grandes y
complejos, es imposible cumplir los requerimientos de consistencia y
complecin. La razn de esto se debe parcialmente a la complejidad
inherente del sistema y parcialmente a que los diferentes puntos de
vista tienen necesidades inconsistentes. Estas inconsistencias son
obvias cuando los requerimientos se especifican por primera vez. Los
problemas emergen despus de un anlisis profundo. Una vez que
stos se hayan descubierto en las diferentes revisiones o en las fases
posteriores del ciclo de vida, se deben corregir en el documento de
requerimientos.
5.2- Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema.

Incluyen restricciones de tiempo, sobre el proceso de desarrollo,
estndares, etc.
Son aquellos requerimientos que no se refieren directamente a las
funciones especficas que entrega el sistema, sino a las propiedades
emergentes de ste como la fiabilidad, la respuesta en el tiempo y la
capacidad de almacenamiento. De forma alternativa, definen las
restricciones del sistema como la capacidad de los dispositivos de
entrada/salida y la representacin de datos que se utiliza en la
interface del sistema.
Muchos requerimientos no funcionales se refieren al sistema como un
todo ms que a rasgos particulares del mismo. Esto significa que a
menudo con ms crticos que los requerimientos funcionales
particulares. Mientras que el incumplimiento de este ltimo degradar
el sistema, una falla en un requerimiento no funcional del sistema lo
inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario,
debido a las restricciones en el presupuesto, a las polticas de la
organizacin, a la necesidad de interoperabilidad con otros sistemas
de software o hardware o a factores externos como los reglamentos
de seguridad, las polticas de privacidad, etctera.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con
sus implicaciones.
Requerimientos del producto. Especifican el comportamiento del
producto; como los requerimientos de desempeo en la rapidez de
ejecucin del sistema y cunta memoria se requiere; los de fiabilidad
que fijan la tasa de fallas para que el sistema sea aceptable; los de
portabilidad y los de usabilidad.
Requerimientos organizacionales. Se derivan de las polticas y
procedimientos existentes en la organizacin del cliente y en la del
desarrollador: estndares en los procesos que deben utilizarse;
requerimientos de implementacin como los lenguajes de
programacin o el mtodo de diseo a utilizar, y los requerimientos
de entrega que especifican cundo se entregar el producto y su
documentacin.
Requerimientos externos. Se derivan de los factores externos al
sistema y de su proceso de desarrollo. Incluyen los requerimientos de
interoperabilidad que definen la manera en que el sistema interacta
con los otros sistemas de la organizacin; los requerimientos legales
que deben seguirse para asegurar que el sistema opere dentro de la
ley, y los requerimientos ticos. Estos ltimos son impuestos al
sistema para asegurar que ser aceptado por el usuario y por el
pblico en general.

6.- ATRIBUTOS Y MEDIDAS DE CALIDAD DEL SOFTWARE

Una atributo es una propiedad del producto, que cuando es asociada
con la calidad se relaciona con los elementos que considera el cliente
para aceptar o rechazar el producto. Estos atributos de calidad deben
ser
medidos
para
poder
ser
comparados.
Es importante entenderlos desde la concepcin de la idea a partir de
las necesidades del cliente o mercado, considerarlos como parte de la
solucin y creacin del producto para finalmente demostrar que han
sido adecuadamente integrados en el producto final. Aqu se
presentan diferentes atributos y medidas considerados en los
entornos de desarrollo, instalacin y operacin que pueden ser tiles
identificar en cada caso.
6.1- Atributos de calidad en operacin
Los atributos de calidad en operacin, en general, se pueden
identificar como cinco atributos y estn relacionados con
caractersticas que se espera cumpla el producto durante su
operacin.
1. Rendimiento, se mide en trmino de la respuesta del sistema a
ciertas funcionalidades como pueden ser velocidad de
respuesta al recibir una peticin o procesar una informacin,
capacidad de almacenamiento o volumen de informacin ,
tiempo de ejecucin y nmero de usuarios concurrentes en una
unidad de tiempo.
2. Confiabilidad, caracterizada por la probabilidad del sistema de
operar sin fallas. Se puede medir en funcin del tiempo
promedio entre fallas, tasa de ocurrencia de fallas o la
probabilidad de fallas ante peticiones recibidas.
3. Tolerancia a fallas, entendido tambin como robusto es la
propiedad del producto de recuperarse ante una falla o
interrupcin en su operacin. Se mide en relacin con el tiempo
de recuperacin despus de una falla, porcentaje de eventos
que causan fallas o datos afectados por la falla.
4. Seguridad, o integridad es la caracterstica que evita el acceso
no autorizado o accidental de usuarios. Normalmente se puede
medir como el nmero o porcentaje de intentos fallidos por tipo
de acceso.
5. Uso, es la caracterstica que permite que el sistema pueda ser
fcilmente utilizado de manera efectiva. Es medido en relacin

con el tiempo que le toma a un tipo de usuario obtener las

habilidades para completar una tarea especfica, promedio de
errores que comete un usuario en un periodo de tiempo, nivel
de satisfaccin o intuicin para poder completar una tarea sin
ayuda o asesora.
6.2- Atributos de calidad en desarrollo
Los atributos de calidad en el entorno de desarrollo se refieren a los
elementos a considerar para garantizar un adecuado desarrollo del
producto y se relacionan con:
1. Eficiencia, es una medida de la eficiencia en el uso de los
recursos del sistema y se mide en trminos del uso de la
memoria, ancho de banda, espacio en disco o disponibilidad de
capacidad del procesador durante las operaciones.
2. Mantenimiento, o capacidad de modificarse es la habilidad para
corregir defectos, reparar o agregar nuevas funcionalidades sin
afectar la operacin del sistema en uso. Se mide en funcin del
tiempo que toma cambiar o corregir un componente
determinado.
3. Reuso, es la posibilidad de utilizar componentes existentes para
crear nuevos; medido como el costo de cambio de un
componente al integrarlo en otros sistemas.
4. Verificable, es una medida del costo de identificar fallas en las
pruebas, porcentaje de defectos en pruebas, cantidad o costo
de las pruebas.
6.3- Atributos de calidad en implementacin
Los atributos de calidad en implementacin se relacionan con las
caractersticas que se esperan del producto durante la etapa de
despliegue y liberacin de la solucin.
1. Disponibilidad, est relacionada con la habilidad de acceder al
sistema bajo factores que lo afectan durante el respaldo,
recuperacin o reinicio y se mide como el porcentaje del tiempo
en que el sistema puede estar disponible.
2. Flexibilidad, o capacidad de adaptacin para aumentar,
extender o expandirse con usuarios adicionales. Es medido en
funcin del esfuerzo, duracin o costo de agregar o modificar
componentes especficos.

3. Interoperabilidad, es la facilidad en que un sistema puede

intercambiar informacin o servicios con otros sistemas y es
cuantificado como el esfuerzo, duracin o costo del intercambio
de datos o servicios en protocolos de comunicacin, hardware o
aplicaciones.
4. Instalable, es la facilidad para instalar el software dentro del
hardware y se mide como el tiempo para cargar o configurar un
sistema dentro de un dispositivo.
5. Portable, est relacionado con el costo o esfuerzo de mover un
sistema a otro equipo, sistema operativo, lenguaje o
compilador.
6. Recuperable, es la habilidad para recuperar el sistema en caso
de fallas medido como el tiempo para restablecer el sistema al
punto previo al que se present el problema.
7. Escalable, es la capacidad de expandirse en usuarios o
incrementar la capacidad del sistema sin realizar cambios.
8. Seguridad, est relacionada con la confianza en que el sistema
funciona sin afectar a las personas o al medio. Es medido en
funcin de la probabilidad de dao o riesgo a la seguridad,
nmero o porcentaje de daos y el nmero o porcentaje
aceptado de accidentes; clasificados por tipo y severidad.
En otros contextos los atributos de calidad pueden considerar
tambin caractersticas como etiquetado, empacado, garantas,
caducidad, atributos fsicos como: peso, volumen, color y acabados,
as como atributos ambientales, txicos y de transporte.

7.- Tcnicas para Identificar Requisitos Funcionales y No

Funcionales

Contenidos
7.1. Identificacin de Requerimientos funcionales
7.2. Identificacin de Requerimientos no funcionales
7.3. Aspectos a tener en cuenta en la identificacin
requerimientos funcionales y no funcionales
7.4. Identificacin de elementos
7.5. Preguntas generales:

de

Ya que los requerimientos de sistemas de software se clasifican en

funcionales y no funcionales, se deben tener en cuenta las siguientes
tcnicas para la identificacin correcta.
7.1.- Identificacin de Requerimientos funcionales
Los requerimientos funcionales son declaraciones de los servicios que
proveer el sistema, de la manera en que ste reaccionar a entradas
particulares. En algunos casos, los requerimientos funcionales de los
sistemas tambin declaran explcitamente lo que el sistema no debe
hacer.
Muchos de los problemas de la ingeniera de software provienen de la
imprecisin

en

la

especificacin

de

requerimientos.

Para

un

desarrollador de sistemas es natural dar interpretaciones de un

requerimiento ambiguo con el fin de simplificar su implementacin.
Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al
sistema, retrasando la entrega de ste e incrementando el costo.
En principio, la especificacin de requerimientos funcionales de un
sistema debe estar completa y ser consistente. La complecin
significa que todos los servicios solicitados por el usuario estn
definidos. La consistencia significa que los requerimientos no tienen
definiciones contradictorias.
En la prctica, para sistemas grandes y complejos, es imposible
cumplir los requerimientos de consistencia y complecin. La razn de
esto se debe parcialmente a la complejidad inherente del sistema y
parcialmente a que los diferentes puntos de vista tienen necesidades
inconsistentes.

Estas

inconsistencias

son

obvias

cuando

los

requerimientos se especifican por primera vez. Los problemas

emergen despus de un anlisis profundo. Una vez que stos se
hayan descubierto en las diferentes revisiones o en las fases
posteriores del ciclo de vida, se deben corregir en el documento de

requerimientos.
7.2.- Identificacin de Requerimientos no funcionales
Son aquellos requerimientos que no se refieren directamente a las
funciones especficas que entrega el sistema, sino a las propiedades
emergentes de ste como la fiabilidad, la respuesta en el tiempo y la
capacidad de almacenamiento. De forma alternativa, definen las
restricciones del sistema como la capacidad de los dispositivos de
entrada/salida y la representacin de datos que se utiliza en la
interface del sistema.
Los requerimientos no funcionales surgen de la necesidad del
usuario, debido a las restricciones en el presupuesto, a las polticas
de la organizacin, a la necesidad de interoperabilidad con otros
sistemas de software o hardware o a factores externos como los
reglamentos de seguridad, las polticas de privacidad, entre otros.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con
sus implicaciones.
Requerimientos del producto. Especifican el comportamiento del
producto; como los requerimientos de desempeo en la rapidez de
ejecucin del sistema y cunta memoria se requiere; los de fiabilidad
que fijan la tasa de fallas para que el sistema sea aceptable; los de
portabilidad y los de usabilidad.
Requerimientos organizacionales. Se derivan de las polticas y
procedimientos existentes en la organizacin del cliente y en la del
desarrollador: estndares en los procesos que deben utilizarse;
requerimientos

de

implementacin

como

los

lenguajes

de

programacin o el mtodo de diseo a utilizar, y los requerimientos

de entrega que especifican cundo se entregar el producto y su
documentacin.
Requerimientos externos. Se derivan de los factores externos al

sistema y de su proceso de desarrollo. Incluyen los requerimientos de

interoperabilidad que definen la manera en que el sistema interacta
con los otros sistemas de la organizacin; los requerimientos legales
que deben seguirse para asegurar que el sistema opere dentro de la
ley, y los requerimientos ticos. Estos ltimos son impuestos al
sistema para asegurar que ser aceptado por el usuario.
En la prctica, la especificacin cuantitativa de requerimientos es
difcil. A los clientes no les es posible traducir sus metas en
requerimientos cuantitativos; para algunas de stas, como las de
mantenimiento, no existen mtricas que se puedan utilizar; el costo
de verificar de forma objetiva los requerimientos no funcionales
cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se
diferencian en el documento de requerimientos. En la prctica, esto
es difcil. Si un requerimiento no funcional se declara de forma
separada a los funcionales, algunas veces es difcil ver la relacin
entre ellos. Si se declaran con los requerimientos funcionales, es
difcil separar las condiciones funcionales y no funcionales e
identificar los requerimientos que se refieren al sistema como un
todo. Se debe hallar un balance apropiado que dependa del tipo de
sistema

especificar.

Sin

embargo,

los

requerimientos

que

claramente se refieren a las propiedades emergentes del sistema se

deben resaltar. Esto se hace colocndolos en una seccin aparte o
diferencindolos, de alguna forma, de los otros requerimientos del
sistema.
7.3.- Aspectos a tener en cuenta en la identificacin de
requerimientos funcionales y no funcionales
Requerimientos bsicos: se estructura su identificacin al buscar
respuestas a preguntas como:
Cul es el proceso bsico de la empresa?
Qu datos utiliza o produce este proceso?
Cules son los lmites impuestos por el tiempo y la carga de

trabajo?
Qu controles de desempeo utiliza?
Siempre se debe comenzar con lo bsico. Cuando se hacen preguntas
y se reciben respuestas, se proporcionan antecedentes sobre detalles
fundamentales relacionados con el sistema y que sirven para
describirlo.
Las siguientes preguntas son de utilidad para adquirir la comprensin
necesaria:
Cul es la finalidad de la actividad dentro de la empresa?
Qu pasos se siguen para realizarla?
Dnde se realizan estos pasos?
Quines los realizan?
Cunto tiempo tardan en efectuarlos?
Con cunta frecuencia lo hacen?
Quines emplean la informacin resultante?
7.4.- Identificacin de elementos
Durante esta, se debe identificar muy claramente los siguientes
elementos:
Procesos
Flujos de datos entre procesos
Datos de cada flujo de datos
Bases de datos
Datos de las bases de datos

7.5.-Preguntas generales:
Cuntos empleados laboran para la organizacin en el rea(s) que
se pretende desarrollar el sistema; o sea, cuntos tienen relacin
directa con el proyecto
Cules son las personas claves en el sistema? Por qu son
importantes?

 Existen obstculos o influencias de tipo poltico que afectan la

eficiencia del sistema?
Existen manuales de procedimientos, polticas o lineamientos de
desempeo documentados oficial o no oficialmente?. Si los hay, Se
cumplen en forma cabal en el 100% de las ocasiones?, es decir, se
respetan dichos procedimientos?
Existen mtodos para evadir el sistema?, Por qu se presentan?
Qu reas necesitan un control especfico?
Qu criterios se emplean para medir y evaluar el desempeo?