Las inspecciones de software: surgen a partir de la necesidad de producir software de alta

calidad. La garanta de la calidad del software es una actividad de proteccin que se aplica
a lo largo de todo el proceso de ingeniera de software

Segn Pressman, en su libro Ingeniera de Software, un enfoque practico(1998)



La validacin de requisitos: examina la especificacin, para asegurar que todos los
requisitos de software se han establecido de manera precisa, que se han detectado las
inconsistencias, omisiones y errores y que estos han sido corregidos, y que los productos de
trabajo cumplen con los estndares establecidos para el proceso, proyecto y producto. De
igual manera Pressman (1998) acota que La prueba del software es un elemento de un
temas mas amplio que suele denominarse verificacin y validacin

CARACTERSTICAS DE REQUISITOS
Completitud: Significa que no hay omisiones que comprometan la integridad de los
requisitos o No faltan requisitos (propiedad global)No faltan detalles en la especificacin
de cada requisito (propiedad individual)Es una propiedad difcil de determinar (tan slo
podemos alcanzar una aproximacin)

Galves(2006),alreferirseacompletituddiceEscuandoLafuncionalidaddelsistemasatisfacetod
oslosrequisitos,esdecirsehizoloqueelclientepidi.



Deteccin de conflictos e inconsistencias de requisitos
Razones de inconsistencia
Los sistemas de software grandes deben mejorar su actual situacin. Es difcil anticipar los
efectos que el sistema tendr en la organizacin.
Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente
compromiso de cambios en los requerimientos.
Los usuarios finales del sistema y la organizacin que paga por el sistema tienen
requerimientos diferentes.
CARACTERSTICAS DE REQUISITOS
TIPOS DE ESPECIFICACIN: TEXTUAL, NOTACIN GRFICA Y
LENGUAJES DE REPRESENTACIN (LENGUAJE UNIFICADO DE
MODELADO UML Y NOTACIN DE REQUERIMIENTOS DE USUARIO
URN).

Textual.
Tradicionalmente la especificacin de requisitos se ha realizado usando sobre todo
especificaciones textuales en lenguaje natural. Las herramientas de apoyo a la gestin de
requisitos se han enfocado a la manipulacin de trozos de texto. Estos requisitos expresados
textualmente se enlazan formando un grafo de trazabilidad del cual se usa para gestionar los
requisitos y su trazabilidad. En este enfoque, las especificaciones generadas en las otras
actividades del desarrollo de software pueden tambin ser aadidas al grafo de trazabilidad
representndolas como texto.

Notacin grfica.
Incluye todas las notaciones que pueden demostrar el flujo de informacin entre requisitos
apoyndose en diversas imgenes.
Estas notaciones permiten al usuario del sistema tener mayor comprensin del software lo
que hace y como lo hace.
La ms utilizada actualmente es el Lenguaje Unificado de modelado (UML). Otra notacin
que se puede usar es la notacin de requerimientos de usuario (URN).
TIPOS DE ESPECIFICACIN: TEXTUAL, NOTACIN GRFICA Y
LENGUAJES DE REPRESENTACIN (LENGUAJE UNIFICADO DE
MODELADO UML Y NOTACIN DE REQUERIMIENTOS DE USUARIO
URN).

Lenguaje de especificacin (UML)
Es un lenguaje para la especificacin, visualizacin, construccin y documentacin de los
artefactos de un proceso de sistema intensivo. UML, emergi en los aos 90 luego de la
bsqueda de un lenguaje de modelamiento que unificara a la industria. A pesar de que UML
evolucion de varios mtodos orientados al objeto de segunda generacin (en nivel de
notacin), su alcance extiende su uso ms all de sus predecesores.
TIPOS DE ESPECIFICACIN: TEXTUAL, NOTACIN GRFICA Y
LENGUAJES DE REPRESENTACIN (LENGUAJE UNIFICADO DE
MODELADO UML Y NOTACIN DE REQUERIMIENTOS DE USUARIO
URN).

Notacin de requerimientos de usuario URN



ESTANDARES PARA ESCRIBIR REQUERIMIENTOS DE ALTA CALIDAD

Los Requerimientos deben ser:

Completos. Todo lo que el software tiene que hacer est recogido en el conjunto de
requerimientos, es decir, deben describir toda la funcionalidad que el sistema deber
implementar.

No ambiguos. Cada requerimiento debe tener una sola interpretacin.

Debiendo poder expresarse de una manera sencilla, clara y sin ambiguedades usando:
- Lenguaje natural (espaol).
- Lenguajes grficos (UML)
- Lenguajes formales (Notacin Z).

Relevantes. Importancia para el sistema software a implementar.

Traceables. Cada accin de diseo debe corresponderse con algn requerimiento del
cliente (resuelve un problema de este).

Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando mtricas
que faciliten su verificacin.
ESTANDARES PARA ESCRIBIR REQUERIMIENTOS DE ALTA CALIDAD

Los Requerimientos deben ser:

Correctos. Cada requerimiento establecido debe representar algo requerido por el usuario
para el sistema que se construye y ser validado por este.

Consistentes. Ningn requerimiento puede estar en conflicto con otro. Tipos de
inconsistencias:

-Trminos conflictivos: Si dos trminos se usan en contextos diferentes para la misma
cosa.

-Caractersticas en conflicto: Si en dos partes de la ERS se pide que el producto
muestre comportamientos contradictorios.

-Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca
restricciones de tiempo contradictorias
Documento de requisitos

Qu produce la Ingeniera de Requerimientos?
Su producto principal es el DOCUMENTO DE REQUERIMIENTOS. Contiene el conjunto
de requerimientos que debe satisfacer el sistema

El Documento de Requerimientos (DR) es un documento manual o electrnico que describe
y comunica de manera sencilla. Es un escrito oficial de los requisitos del sistema para los
clientes, usuarios finales y desarrolladores de software

Normalmente el documento se divide en dos partes:
- Documento de Definicin de Requerimientos (DDR)
- Documento de Especificacin de Requerimientos (DER)

Nombres:
Especificacin funcional,
Definicin de requisitos,
Especificacin de los requisitos de software

El documento describe:
Los servicios y funciones que el sistema debera proveer.
Las restricciones bajo las cuales el sistema debe operar
Las propiedades generales del sistema, es decir, restricciones sobre las
propiedades emergentes del sistema
Definiciones de otros sistemas con los cuales el sistema se debe integrar.
Informacin acerca del dominio de aplicacin del sistema, por ej. cmo
llevar a cabo tipos particulares de clculos.
Restricciones sobre el proceso usado para desarrollar el sistema
glosario

Documento de requisitos
Usuarios del documento de requisitos
Clientes del sistema
Especifican los requisitos y los leen para
chequear que atienden sus necesidades.
Especifican cambios en los requisitos.
Gerentes
Usan los documentos de requisitos para
planificar una propuesta (oferta) para el sistema
y planificar el proceso de desarrollo.
Ingenieros de sistemas

Usan los requisitos para entender qu sistema
tiene que ser desarrollado.
Ingenieros de prueba de
sistemas

Usan los requisitos para desarrollar pruebas de
validacin para el sistema.
Ing. de mantenimiento
de sistemas
Usan los requisitos para ayudar a entender los
sistemas y las relaciones entre sus partes.
Documento de Especificacin de Requerimientos (DER)
Describe detalladamente los requerimientos contenidos en el DDR.
Est orientado a los desarrolladores.
Tiene un carcter tcnico.
Los requerimientos se describen en un lenguaje o notacin tcnica.
- Ejemplo: UML, SADT, ER

Documento de Definicin de Requerimientos (DDR)
Describe los requerimientos de alto nivel desde la perspectiva de los
clientes y/o usuarios.
Est orientado a los clientes y/o usuarios.
Los requerimientos se describen en lenguaje natural (espaol)

Existen varios estndares y modelos (plantillas o patrones) que ayudan a elaborar el DR.

El estndar IEEE
- Propuesto por el Institute of Electrical and Electronics Engineers (IEEE)
- Agrupa los documentos DDR y DER en un solo documento.
- Es tambin un estndar ANSI

La plantilla Volere.
- Permite documentar cada requerimiento mediante un formato especial.
EL ESTNDAR IEEE-830-1993
Modelo IEEE/ANSI 830-1998
Introduccin
1.1.Propsito del documento de requisitos
1.2.Alcance del proyecto
1.3.Definiciones, acrnimos y abreviaturas
1.4.Resumen del resto del documento
Descripcin General
2.1.Perspectiva del producto
2.2.Funciones del producto
2.3.Caractersticas de los usuarios
2.4.Limitaciones generales
2.5.Suposiciones y dependencias
Requisitos Especficos
3.1.Requisitos funcionales, no funcionales
Apndices
ndice
IEEE Std. 830-1998 [IEEE, 1999b]
1. Introduccin
1.1. Objetivo
1.2. mbito
1.3. Definiciones, acrnimos y abreviaturas
1.4. Referencias
1.5. Descripcin del resto del documento
2. Descripcin general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Caractersticas del usuario
2.4. Limitaciones generales
2.5. Supuestos y dependencias
3. Requisitos especficos
3.1. Requisitos funcionales
3.2. Requisitos de interfaz externa
3.3. Requisitos de ejecucin
3.4. Restricciones de diseo
3.5. Atributos de calidad
3.6. Otros requisitos
Apndices
ndice
3. Requisitos especficos
3.1. Requisitos funcionales
3.1.1. Requisito funcional 1
3.1.1.1. Introduccin
3.1.1.2. Entradas
3.1.1.3. Salidas
3.1.2. Requisito funcional 2
.
3.1.n. Requisito funcional n

3.2. Requisitos de interfaz externa
3.2.1. Interfaces de usuario
3.2.2. Interfaces hardware
3.2.3. Interfaces software
3.2.4. Interfaces de comunicaciones
3.3. Requisitos de ejecucin
3.4. Restricciones de diseo
3.4.1. Acatamiento de estndares
3.4.2. Limitaciones hardware


3.5. Requisitos no funcionales(atributos de
calidad)
3.5.1. Seguridad
3.5.2. Mantenimiento

3.6. Otros requisitos
3.6.1. Base de datos
3.6.2. Operaciones
3.6.3. Adaptacin de situacin

[Durn y Bernrdez, 2002]

Portada
Lista de cambios
ndice
Lista de figuras
Lista de tablas
1. Introduccin
2. Participantes en el proyecto
3. Descripcin del sistema actual
4. Objetivos del sistema
5. Catlogo de requisitos del sistema
5.1 Requisitos de informacin
5.2 Requisitos funcionales
5.2.1 Diagramas de casos de uso
5.2.2 Definicin de actores
5.2.3 Casos de uso del sistema
5.3 Requisitos no funcionales
6. Matriz de rastreabilidad
objetivos/requisitos
7. Glosario de trminos
8. Conflictos pendientes de resolucin
[opcional, pueden ir en un documento
aparte]
Apndices [opcionales]







Plantilla Volere