PRUEBAS DE SOFTWARE

VERIFICACION DEL REQUERIMIENTO

INTEGRANTES
:
1.

2.

3.

4.

5.

HUAMANI GUILLEN,
YEFFER
HERNANDEZ RAMIRES,
FRANK
MATTA COMENA, CARLOS
POMASONCCO
GARAMENDI VLADIMR
QUISPE DONAYRE,
MANUEL

VERIFICACION DEL REQUERIMIENTO

REQUERIMIENTO:
v

Es una caracterstica del sistema o una descripcin

de algo que el sistema es capaz de hacer con el
objetivo de satisfacer el propsito del sistema.
Los requerimientos identifican el qu del sistema,
mientras que el diseo establece el cmo del
sistema.

Atributos que debe cumplir un requerimiento antes de entregar

al equipo de desarrollo

CARACTERSTICAS

Las caractersticas de
los requerimientos
mencionados en el
estndar de
Especificacin de
requerimientos
IEEE830 los explica
Shari Lawrence

CORRECTOS: Tanto el cliente como el desarrollador

deben revisar los requerimientos para asegurar que
no tienen errores.
INCONSISTENTES: Dos requerimientos son
inconsistentes cuando es imposible satisfacerlos
simultneamente.
COMPLETOS: El conjunto de requerimientos est
completo si todos los estados posibles, cambios de
estado, entradas, productos y restricciones estn
descritos en alguno de los requerimientos.
REALISTAS: Todos los requerimientos deben ser
revisados para asegurar que son posibles.

VERIFICACIN DE REQUERIMIENTOS

La verificacin formal es una

rigurosa demostracin matemtica
de la concordancia del cdigo fuente
con sus especificaciones.
La validacin es la evaluacin del
software al final del proceso de
desarrollo del software para
determinar su conformidad con los
requisitos.

Objetivos de V&V

Descubrir defectos (para corregirlos)

Provocar fallas (una forma de detectar defectos)

Revisar los productos (otra forma de detectar defectos)

Evaluar la calidad de los productos

El probar o revisar el software da una idea de la calidad del

mismo

COMO REALIZAR EL ANLISIS DE REQUERIMIENTOS

1.

Los requerimientos de un
sistema de software, cuando se
ven en su conjunto son extensos
y
detallados, y adems
contienen mltiples relaciones
entre si.
Esto se logra mediante la
clasificacin, estructuracin y
organizacin de todo lo que el
sistema debe de hacer.

2.

3.

4.

Obtener informacin por diferentes medios de lo que los

usuarios desean y dejar escritas esas necesidades
Clasificar esas necesidades para poder estructurar los
requerimientos o necesidades del sistema.
Identificar los niveles de jerarqua del sistema y empezar a
alojar los requerimientos en el nivel que les corresponda.
Especificar completamente cada necesidad, sin ahorrar tiempo
y espacio en su descripcin.

COMO REALIZAR EL ANLISIS DE REQUERIMIENTOS

5. Entender correctamente las necesidades y cuando

afecten dos o mas usuarios, para llegar a acuerdos
entre las partes.
6. Manejar las expectativas y estar dispuesto a realizar
cambios.
7. Se debe mantener una perfecta comunicacin entre
todos quienes participan en el proceso de
levantamiento de los requerimientos

COMO OBTENER INFORMACIN

v

Los requerimientos son el punto de acuerdo entre el usuario y el proyecto de

desarrollo de software, este entendimiento es necesario para poder construir
software que satisfaga las necesidades de los usuarios.
Si los requerimientos se enfocan a describir las necesidades del usuario,
entonces es lgico que para recabarlos haya que obtener la informacin de
primera mano. Esto es, mediante entrevistas con el usuario o recabando
documentacin que describa la manera que el usuario desea que funcione el
sistema de software.
Las necesidades y/o requerimientos del usuario evolucionan con el tiempo y
cada cambio involucra un costo. Por eso es necesario tener archivada una copia
de la documentacin original del usuario, as como cada revisin o cambio que
se haga a esta documentacin. Para poder establecer o estimar el costo de un
proyecto es necesario contar con los requerimientos iniciales en su mejor nivel
de detalle

COMO OBTENER INFORMACIN

LA ENTREVISTA

La entrevista es una forma de recoger informacin

de otra persona a travs de una comunicacin
interpersonal que se lleva a cabo por medio de una
conversacin estructurada.

Las entrevistas sirven para obtener una comprensin

general de lo que hacen los futuros usuarios del
sistema, cmo podran interactuar con el sistema y
las dificultades a las que se enfrentan con los
sistemas actuales. A la gente le gusta hablar de su
trabajo y normalmente se alegran de verse
implicados en las entrevistas.

COMO OBTENER INFORMACIN

FASES DE LA ENTREVISTA

Apertura: Presentarse e informar al entrevistado sobre la

razn de la entrevista.

Preparacin: El entrevistador debe documentarse e

investigar la situacin de la organizacin, analizando los
documentos de la empresa disponible.

COMO OBTENER INFORMACIN

FASES DE LA ENTREVISTA

Desarrollo: Cumplir las reglas del protocolo, hay que llegar a

un acuerdo sobre como se va a registrar la informacin
obtenida.
Terminacin: Se termina recapitulando la entrevista
agradeciendo el esfuerzo y dejando abierta la posibilidad de
volver a contactar para aclarar conceptos o bien citndole
para otra entrevista.

Las entrevistas con los involucrados con el sistema son parte de la mayora de los procesos de
la ingeniera de requerimientos. En estas entrevistas, el equipo de la ingeniera de
requerimientos hace preguntas sobre el sistema que utilizan y sobre el sistema a desarrollar.
Los requerimientos provienen de las respuestas a estas preguntas.

COMO OBTENER INFORMACIN

TIPOS DE ENTREVISTA:
ENTREVISTAS CERRADAS:
donde los entrevistados responden a un
conjunto predefinido de preguntas.
v

COMO OBTENER INFORMACIN

TIPOS DE ENTREVISTA:
ENTREVISTAS ABIERTAS:
donde no hay un programa predefinido. El
equipo de la ingeniera de requerimientos
examina una serie de cuestiones con los
involucrados con el sistema y, por lo tanto,
desarrolla una mejor comprensin de sus
necesidades.
v

COMO OBTENER INFORMACIN

CARACTERISTICAS DE LOS ENTREVISTADORES:

No tienen prejuicios, evitan ideas preconcebidas sobre los

requerimientos y estn dispuestos a escuchar a los
entrevistados. Si el entrevistado propone requerimientos
sorprendentes, estn dispuestos a cambiar su opinin del
sistema.
Ayudan al entrevistado a empezar las discusiones con una
pregunta, una propuesta de requerimientos o sugiriendo
trabajar juntos en un prototipo del sistema. Preguntar al cliente
por lo que quiere de manera general normalmente no
proporciona informacin til. Para la mayora de la gente es
mucho ms fcil hablar de algo en particular que en trminos
generales.

COMO OBTENER INFORMACIN

EL ENTREVISTADO PUEDE PRESENTAR:

Pasividad, inhibicion

No aceptacion

Rechazo

Agresividad

EL ENTREVISTADOR DEBE POSEER:

Trato cordial

Conocimiento de tecnicas de comunicacin

Actitud para escuchar sin prejuicios

Experiencia prctica

Inters por el tema

DOCUMENTOS DE REQUERIMIENTOS
Existen dos documentos que emanan del anlisis de
requerimientos:
DEFINICIN DE REQUERIMIENTOS:

Es un documento que debe escribirse en trminos que

el cliente pueda entender. Es decir, este documento es
un listado completo de todas las cosas que el cliente
espera que haga el sistema propuesto.
Este documento es escrito en forma conjunta por el
cliente y el desarrollador.

DOCUMENTOS DE REQUERIMIENTOS
ESPECIFICACIN DE REQUERIMIENTOS:

Documento que reitera la definicin de los

requerimientos en los trminos tcnicos apropiados
para el desarrollador del diseo de un sistema.
Es la contrapartida tcnica al documento de definicin
de requerimientos y es escrito por los analistas de
requerimientos.

A veces un nico documento puede servir para ambos

propsitos, lo que lleva a un entendimiento comn entre
clientes, analistas de requerimientos y diseadores, pero
a menudo se necesitan ambos documentos.

Es muy importante, que al usar ambos documentos exista un correspondencia directa entre cada
requerimiento del documento de definicin y aquellos documentos en la especificacin.

CLASIFICACION DE LOS REQUERIMIENTOS

Segn el Tipo los requerimientos se clasifican
en:

Requerimientos funcionales.
Requerimientos no funcionales.

Segn a quien van dirigidos se clasifican

en:

Requerimientos del Usuario.

Requerimientos del Sistema.

CLASIFICACION DE LOS REQUERIMIENTOS

SEGN EL TIPO:
Requerimientos funcionales

Describen la funcionalidad o los servicios que se espera que el sistema proveer. Dependen del
tipo de software, del sistema que se desarrollo y de los posibles usuarios.
Cuando se expresan como Requerimientos del usuarios, se definen de forma general.
Cuando se expresan como requerimiento del sistema describen con detalle la funcin de ste, sus
entradas y salidas, excepciones, etc.

CLASIFICACION DE LOS REQUERIMIENTOS

Requerimientos no funcionales

Son los 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.

Muchos requerimientos no funcionales se refieren al

sistema como un todo ms que a rasgos particulares
del mismo.

CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES
Del producto: especifican comportamiento del producto. Ej.:
de desempeo en la rapidez de
ejecucin del sistema, cuanta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para el
sistema sea aceptable, los de portabilidad y de usabilidad.

Organizacionales: se derivan de las polticas y procedimientos existentes en la organizacin del

cliente y del desarrollador. Ej.: estndares en los procesos que deben utilizarse, requerimientos de
implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar.

Externos: cubre todos los requerimientos que se derivan de los factores externos al sistema y de su
proceso de desarrollo. Ej.: requerimientos de interoperabilidad, requerimientos legales,
requerimientos ticos.
Un problema comn con los requerimientos no funcionales es que algunas veces son difciles de
verificar.

CLASIFICACION DE LOS REQUERIMIENTOS

Caractersticas de los requerimientos:
Es importante sealar que los requerimientos pueden servir a
tres propsitos:

Permitir que el desarrollador explique como ha entendido

lo que el cliente pretende del sistema.
Indican a los diseadores que funcionalidades y
caractersticas va a tener el sistema resultante.
Los requerimientos indican al equipo de pruebas que
demostraciones llevar a cabo para convencer al cliente de
que el sistema que se le entrega es de hecho lo que haba
ordenado

CLASIFICACION DE LOS REQUERIMIENTOS

PREGUNTAS
QUE
REQUERIMIENTOS .

DEVEN

RESPONDER

los requerimientos son correctos?. Cliente

y desarrollador deben revisarlos para
asegurarse que no tienen errores.
los requerimientos son consistentes?. Es
decir, los requerimientos planteados son
no conflictivos ni ambiguos?. Dos
requerimientos son inconsistentes cuando
es
imposible
satisfacerlos
simultneamente.

LOS

CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION SEGN A QUIEN VA DIRIGIDO:
Requerimientos de Usuario

Declaraciones en lenguaje natural y en diagramas de los servicios

que se espera que el sistema provea y de las restricciones bajo
las cuales debe operar.
Describen los requerimientos funcionales y no funcionales de tal
forma que sean comprensibles por los usuarios del sistema que
no posean un conocimiento tcnico detallado.
nicamente especifican el comportamiento externo del sistema
y evitan, tanto como sea posible, las caractersticas de diseo del
sistema.

CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION SEGN A QUIEN VA DIRIGIDO:
Requerimientos del sistema:

Establecen con detalle los servicios y restricciones del sistema.

El documento de requerimientos del sistema, algunas veces
denominado especificacin funcional, debe ser preciso.
ste sirve como un contrato entre el comprador del sistema y el
desarrollador del software.
Son descripciones ms detalladas de los requerimientos del
usuario.
Sirven como base para definir el contrato de la especificacin
del sistema y, por lo tanto, debe ser una especificacin
completa y consistente del sistema.
Son utilizados por los ingenieros de software como el punto de
partida para el diseo del sistema.

IMPORTANCIA DE LA DEFINICIN FORMAL DE REQUERIMIENTOS.

En la siguiente tabla se ilustra el conflicto que encontr (Scharer, 1990) cuando los
desarrolladores y los usuarios se limitan a ver el problema desde su particular
punto de vista sin tomar en cuenta la situacin del otro.

COMO VEN LOS DESARROLLADORES A

LOS
COMO VEN LOS USUARIOS A LOS
USUARIOS.

DESARROLLADORES.
Los desarrolladores no comprenden las
Los usuarios no saben lo que quieren

necesidades operacionales.
Los desarrolladores ponen demasiado
Los usuarios no pueden articular lo que
quieren.
nfasis en la tcnica.
Los desarrolladores pretenden decirnos
Los usuarios tienen muchas necesidades
motivadas polticamente.
como hacer nuestro trabajo.
Los desarrolladores no pueden traducir
Los usuarios lo quieren todo bien y ahora
nuestras necesidades claramente

establecidas a un sistema exitoso.

TCNICAS DE VERIFICACION DEL REQUERIMIENTO

WALKTHROUGHS
Walkthrough es una reunin de revisin, donde una persona o
varias examinan el cdigo de otro.
Por lo general, un Walkthrough se convoca cuando un miembro del
Equipo (normalmente un programador) considera que una parte
de su trabajo est completa y puede ser revisada. En este
momento, invita a otros miembros del Equipo para que revisen su
trabajo y le ayuden a detectar errores potenciales. Esta es la labor
fundamental de un walkthrough: la deteccin de errores. Por tanto
debe de evitarse por todos los medios el utilizarlo para otros
propsitos, (como por ejemplo evaluar a los programadores) que
indudablemente invalidaran los resultados

TCNICAS DE VERIFICACION DEL REQUERIMIENTO

WALKTHROUGHS

Su funcin principal no es establecer

ninguna clase de intercomunicacin
entre partes, como parece que
debera de ser el objetivo de una
reunin
al contrario lo que se pretende es
establecer una evaluacin del
trabajo de una persona por parte del
Equipo de Proyecto.

TCNICAS DE VERIFICACION DEL REQUERIMIENTO

WALKTHROUGHS
PARTES INVOLUCRADAS EN UN WALKTHROUGH:
Las personas involucradas en un walkthrough son:

La persona a ser revisada

El revisador o los revisadores

Un moderador

Un secretario,
Una persona puede realizar varias de estas funciones a la misma persona.
DURACIN:
El tiempo mximo de un walkthrough suele estipularse en dos horas, pasado el cual est comprobado
que ya no se obtienen los resultados apetecidos de deteccin de errores.
FASES DE UN WALKTHROUGH:
1.
Planificacin: El moderador es quien organiza la reunin.
2.
Preparacin individual: Cada revisor realiza la revisin.
3.
Reunin del walkthrough: Reunin de mximo 2 horas, donde se muestran los errores al revisado.

TCNICAS DE VERIFICACION DEL REQUERIMIENTO

INSPECCIONES
CONCEPTO
Introducido por Michael Fagan de IBM en 1972, la inspeccin de software es una tcnica para eliminar
defectos lo ms tempranamente posible en el ciclo de vida del Software, siguiendo un plan bien definido
y detallado, para asegurar de que esa un proceso repetible y mejorable.
Las inspecciones se llevan a cabo al final de cada una de las fases de desarrollo: requerimientos,
especificacin, diseo, implementacin, e integracin y testing.
ROLES
Los siguientes roles son utilizados en una inspeccin:
1. Autor: La persona que cre el producto que se inspecciona.
2. Moderador: Este es el lder de la inspeccin. El moderador tiene previsto la inspeccin.
3. Lector: La persona que lee a travs de los documentos, un elemento a la vez.
4. Documentador: La persona que documenta los defectos que se encuentren durante la inspeccin.
5. Inspector: La persona que examina el producto para identificar posibles defectos. El Proceso

TCNICAS DE VERIFICACION DEL REQUERIMIENTO

ETAPAS
Las etapas en el proceso de las inspecciones son:
1.
Reunin de Planificacin: La inspeccin se debe planear con anticipacin por un
moderador.
2.
Informacin general: Se deben describir los antecedentes del producto.
3.
Preparacin: Cada inspector examina el producto para identificar posibles
defectos.
4.
Reunin de inspeccin: Durante esta reunin, el lector lee parte por parte del
producto y los inspectores marcan de los defectos de cada parte.
5.
Repeticin del trabajo y seguimiento: El autor realiza cambios en el producto de
acuerdo a los planes de accin de la reunin de la inspeccin. Tambin, Los
cambios del autor son revisados para asegurarse de que todo est correcto.
El proceso es finalizado por el moderador cuando satisface algunos criterios de
salida predefinidos.

DIFERENCIAS ENTRE INSPECCIONES Y WALKTHROUGH

CONCLUSIONES

Es muy importante realizar procesos de verificacin del requerimiento,

ya que estos, desde las primeras etapas, nos dan una visin clara de
cmo est avanzando el proyecto de acuerdo a los requerimientos de
los usuarios.
Ahora, podemos ver lo necesario que es entender las diferencias de
conceptos entre validacin y verificacin, y aplicar tcnicas como
Comprobacin de escritorio, Walkthroughs e inspeccin para examinar
el avance de las especificaciones, con un bajo riesgo y un bajo costo.