PRUEBAS DE SOFTWARE

VERIFICACION DEL REQUERIMIENTO

INTEGRANTES
:
1. HUAMANI GUILLEN,
YEFFER
2. HERNANDEZ RAMIRES,
FRANK
3. MATTA COMENA, CARLOS
4. POMASONCCO
GARAMENDI VLADIMR
5. QUISPE DONAYRE,
MANUEL
VERIFICACION DEL REQUERIMIENTO

REQUERIMIENTO:

v
Es una característica del sistema o una descripción
de algo que el sistema es capaz de hacer con el
objetivo de satisfacer el propósito del sistema.
v
Los requerimientos identifican el qué del sistema,
mientras que el diseño establece el cómo del
sistema.
Atributos que debe cumplir un requerimiento antes de entregar
al equipo de desarrollo
CARACTERÍSTICAS

Ø
CORRECTOS: Tanto el cliente como el desarrollador
deben revisar los requerimientos para asegurar que
no tienen errores.
Las características de Ø
INCONSISTENTES: Dos requerimientos son
inconsistentes cuando es imposible satisfacerlos
los requerimientos simultáneamente.
mencionados en el Ø
COMPLETOS: El conjunto de requerimientos está
completo si todos los estados posibles, cambios de
estándar de estado, entradas, productos y restricciones están
descritos en alguno de los requerimientos.
Especificación de Ø
REALISTAS: Todos los requerimientos deben ser
requerimientos revisados para asegurar que son posibles.

IEEE830 los explica

Shari Lawrence
 VERIFICACIÓN DE REQUERIMIENTOS


La verificación formal es una
rigurosa demostración matemática
de la concordancia del código fuente
con sus especificaciones.

La validación es la evaluación 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 ANÁLISIS DE REQUERIMIENTOS

1. Obtener información por diferentes medios de lo que los

usuarios desean y dejar escritas esas necesidades
•
Los requerimientos de un
sistema de software, cuando se 2. Clasificar esas necesidades para poder estructurar los
ven en su conjunto son extensos requerimientos o necesidades del sistema.
y detallados, y además
contienen múltiples relaciones 3. Identificar los niveles de jerarquía del sistema y empezar a
entre si. alojar los requerimientos en el nivel que les corresponda.
•
Esto se logra mediante la 4. Especificar completamente cada necesidad, sin ahorrar tiempo
clasificación, estructuración y
organización de todo lo que el y espacio en su descripción.
sistema debe de hacer.
COMO REALIZAR EL ANÁLISIS 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 comunicación entre
todos quienes participan en el proceso de
levantamiento de los requerimientos
 COMO OBTENER INFORMACIÓN
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.

v
Si los requerimientos se enfocan a describir las necesidades del usuario,
entonces es lógico que para recabarlos haya que obtener la información de
primera mano. Esto es, mediante entrevistas con el usuario o recabando
documentación que describa la manera que el usuario desea que funcione el
sistema de software.

v
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 documentación original del usuario, así como cada revisión o cambio que
se haga a esta documentación. 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 INFORMACIÓN

LA ENTREVISTA
 La entrevista es una forma de recoger información
de otra persona a través de una comunicación
interpersonal que se lleva a cabo por medio de una
conversación estructurada .
 

Las entrevistas sirven para obtener una comprensión

general de lo que hacen los futuros usuarios del
sistema, cómo podrían 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 INFORMACIÓN

FASES DE LA ENTREVISTA

Apertura: Presentarse e informar al entrevistado sobre la

razón de la entrevista.

Preparación: El entrevistador debe documentarse e

investigar la situación de la organización, analizando los
documentos de la empresa disponible.
 
 COMO OBTENER INFORMACIÓN

FASES DE LA ENTREVISTA

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

un acuerdo sobre como se va a registrar la información
obtenida.
Terminación: Se termina recapitulando la entrevista
agradeciendo el esfuerzo y dejando abierta la posibilidad de
volver a contactar para aclarar conceptos o bien citándole
para otra entrevista.

Las entrevistas con los involucrados con el sistema son parte de la mayoría de los procesos de
la ingeniería de requerimientos. En estas entrevistas, el equipo de la ingeniería 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 INFORMACIÓN

TIPOS DE ENTREVISTA:
v
ENTREVISTAS CERRADAS:
donde los entrevistados responden a un
conjunto predefinido de preguntas.
 COMO OBTENER INFORMACIÓN

TIPOS DE ENTREVISTA:
v
ENTREVISTAS ABIERTAS:
donde no hay un programa predefinido. El
equipo de la ingeniería de requerimientos
examina una serie de cuestiones con los
involucrados con el sistema y, por lo tanto,
desarrolla una mejor comprensión de sus
necesidades.
 COMO OBTENER INFORMACIÓN

CARACTERISTICAS DE LOS ENTREVISTADORES:

•
No tienen prejuicios, evitan ideas preconcebidas sobre los
requerimientos y están dispuestos a escuchar a los
entrevistados. Si el entrevistado propone requerimientos
sorprendentes, están dispuestos a cambiar su opinión 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 información útil. Para la mayoría de la gente es
mucho más fácil hablar de algo en particular que en términos
generales.
 COMO OBTENER INFORMACIÓN

EL ENTREVISTADO PUEDE PRESENTAR:

•
Pasividad, inhibicion
•
 No aceptacion
•
 Rechazo
•
 Agresividad
 
EL ENTREVISTADOR DEBE POSEER:
 
•
Trato cordial
•
 Conocimiento de tecnicas de comunicación
•
 Actitud para escuchar sin prejuicios
•
 Experiencia práctica
•
 Interés por el tema
 DOCUMENTOS DE REQUERIMIENTOS

Existen dos documentos que emanan del análisis de

requerimientos:

DEFINICIÓN DE REQUERIMIENTOS:

ü
Es un documento que debe escribirse en términos 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

ESPECIFICACIÓN DE REQUERIMIENTOS:
ü
Documento que reitera la definición de los
requerimientos en los términos técnicos apropiados
para el desarrollador del diseño de un sistema.
ü
Es la contrapartida técnica al documento de definición
de requerimientos y es escrito por los analistas de
requerimientos.

A veces un único documento puede servir para ambos

propósitos, lo que lleva a un entendimiento común entre
clientes, analistas de requerimientos y diseñadores, 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 definición y aquellos documentos en la especificación.
 CLASIFICACION DE LOS REQUERIMIENTOS

Según el Tipo los requerimientos se clasifican

Según a quien van dirigidos se clasifican
en:
en:
Ø
Requerimientos funcionales. Ø
Requerimientos del Usuario.
Ø
Requerimientos no funcionales. Ø
Requerimientos del Sistema.
 CLASIFICACION DE LOS REQUERIMIENTOS

SEGÚN 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 función 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 específicas 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 más que a rasgos particulares
del mismo.
 CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION DE LOS REQUERIMIENTOS NO FUNCIONALES

Ø
Del producto: especifican comportamiento del producto. Ej.: de desempeño en la rapidez de
ejecución 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 políticas y procedimientos existentes en la organización del
cliente y del desarrollador. Ej.: estándares en los procesos que deben utilizarse, requerimientos de
implementación como los lenguajes de programación o el método de diseño 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 común con los requerimientos no funcionales es que algunas veces son difíciles de
verificar.
 CLASIFICACION DE LOS REQUERIMIENTOS

Características de los requerimientos:

Es importante señalar que los requerimientos pueden servir a

tres propósitos:
ü
Permitir que el desarrollador explique como ha entendido
lo que el cliente pretende del sistema.
ü
Indican a los diseñadores que funcionalidades y
características 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 había
ordenado
 CLASIFICACION DE LOS REQUERIMIENTOS
Ø
PREGUNTAS QUE DEVEN RESPONDER LOS
REQUERIMIENTOS .

Ø
¿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
simultáneamente.
 CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION SEGÚN 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 técnico detallado.
•
Únicamente especifican el comportamiento externo del sistema
y evitan, tanto como sea posible, las características de diseño del
sistema.
 CLASIFICACION DE LOS REQUERIMIENTOS

CLASIFICACION SEGÚN 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 especificación funcional, debe ser preciso.
•
Éste sirve como un contrato entre el comprador del sistema y el
desarrollador del software.
•
Son descripciones más detalladas de los requerimientos del
usuario.
•
Sirven como base para definir el contrato de la especificación
del sistema y, por lo tanto, debe ser una especificación
completa y consistente del sistema.
•
Son utilizados por los ingenieros de software como el punto de
partida para el diseño del sistema.
 IMPORTANCIA DE LA DEFINICIÓN 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 situación del otro.

COMO VEN LOS DESARROLLADORES A
LOS
USUARIOS.  
Los usuarios no saben lo que quieren  
   
Los usuarios no pueden articular lo que  
quieren.  
Los usuarios tienen muchas necesidades  
motivadas políticamente.  
Los usuarios lo quieren todo bien y ahora   Los desarrolladores no pueden traducir
   
   
COMO VEN LOS USUARIOS A LOS
DESARROLLADORES.
Los desarrolladores no comprenden las
necesidades operacionales.
Los desarrolladores ponen demasiado
énfasis en la técnica.
Los desarrolladores pretenden decirnos
como hacer nuestro trabajo.
nuestras necesidades claramente
establecidas a un sistema exitoso.
 TÉCNICAS DE VERIFICACION DEL REQUERIMIENTO

WALKTHROUGHS

Walkthrough es una reunión de revisión, donde una persona o

varias examinan el código 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 detección de errores. Por tanto
debe de evitarse por todos los medios el utilizarlo para otros
propósitos, (como por ejemplo evaluar a los programadores) que
indudablemente invalidarían los resultados
 TÉCNICAS DE VERIFICACION DEL REQUERIMIENTO

WALKTHROUGHS
•
Su función principal no es establecer
ninguna clase de intercomunicación
entre partes, como parece que
debería de ser el objetivo de una
reunión
•
al contrario lo que se pretende es
establecer una evaluación del
trabajo de una persona por parte del
Equipo de Proyecto.
 TÉCNICAS 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.
DURACIÓN:
El tiempo máximo de un walkthrough suele estipularse en dos horas, pasado el cual está comprobado
que ya no se obtienen los resultados apetecidos de detección de errores.
FASES DE UN WALKTHROUGH:
1. Planificación: El moderador es quien organiza la reunión.
2. Preparación individual: Cada revisor realiza la revisión.
3. Reunión del walkthrough: Reunión de máximo 2 horas, donde se muestran los errores al revisado.
 TÉCNICAS DE VERIFICACION DEL REQUERIMIENTO

INSPECCIONES
CONCEPTO
Introducido por Michael Fagan de IBM en 1972, la inspección de software es una técnica para eliminar
defectos lo más 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,
especificación, diseño, implementación, e integración y testing.

ROLES
Los siguientes roles son utilizados en una inspección:
1. Autor: La persona que creó el producto que se inspecciona.
2. Moderador: Este es el líder de la inspección. El moderador tiene previsto la inspección.
3. Lector: La persona que lee a través de los documentos, un elemento a la vez.
4. Documentador: La persona que documenta los defectos que se encuentren durante la inspección.
5. Inspector: La persona que examina el producto para identificar posibles defectos. El Proceso
 TÉCNICAS DE VERIFICACION DEL REQUERIMIENTO

ETAPAS

Las etapas en el proceso de las inspecciones son:

1. Reunión de Planificación: La inspección se debe planear con anticipación por un
moderador.
2. Información general: Se deben describir los antecedentes del producto.
3. Preparación: Cada inspector examina el producto para identificar posibles
defectos.
4. Reunión de inspección: Durante esta reunión, el lector lee parte por parte del
producto y los inspectores marcan de los defectos de cada parte.
5. Repetición del trabajo y seguimiento: El autor realiza cambios en el producto de
acuerdo a los planes de acción de la reunión de la inspección. También, 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 verificación del requerimiento,
ya que estos, desde las primeras etapas, nos dan una visión clara de
cómo 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 validación y verificación, y aplicar técnicas como
Comprobación de escritorio, Walkthroughs e inspección para examinar
el avance de las especificaciones, con un bajo riesgo y un bajo costo.