Las inspecciones de software: surgen a partir de la necesidad de producir software de alta calidad. La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software

Según Pressman, en su libro “Ingeniería de Software, un enfoque practico”(1998)”

La validación de requisitos: examina la especificación, 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 estándares 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 verificación y validación”

CARACTERÍSTICAS 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 especificación de cada requisito (propiedad individual)Es una propiedad difícil de determinar (tan sólo podemos alcanzar una aproximación)

Galves(2006),alreferirseacompletituddice“EscuandoLafuncionalidaddelsistemasatisfacetodoslosrequisitos,esdecirsehizoloqueelclientepidió”.

Detección de conflictos e inconsistencias de requisitosRazones de inconsistenciaLos sistemas de software grandes deben mejorar su actual situación. Es difícil anticipar los efectos que el sistema tendrá en la organización.Usuarios diferentes tienen requerimientos y prioridades diferentes. Hay constantemente compromiso de cambios en los requerimientos.Los usuarios finales del sistema y la organización que paga por el sistema tienen requerimientos diferentes.

CARACTERÍSTICAS DE REQUISITOS

TIPOS DE ESPECIFICACIÓN: TEXTUAL, NOTACIÓN GRÁFICA Y LENGUAJES DE REPRESENTACIÓN (LENGUAJE UNIFICADO DE MODELADO UML Y NOTACIÓN DE REQUERIMIENTOS DE USUARIO URN).

Textual.Tradicionalmente la especificación de requisitos se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. Las herramientas de apoyo a la gestión de requisitos se han enfocado a la manipulación 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 también ser añadidas al grafo de trazabilidad representándolas como texto.

Notación gráfica.Incluye todas las notaciones que pueden demostrar el flujo de información entre requisitos apoyándose en diversas imágenes.Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace.La más utilizada actualmente es el Lenguaje Unificado de modelado (UML). Otra notación que se puede usar es la notación de requerimientos de usuario (URN).

TIPOS DE ESPECIFICACIÓN: TEXTUAL, NOTACIÓN GRÁFICA Y LENGUAJES DE REPRESENTACIÓN (LENGUAJE UNIFICADO DE MODELADO UML Y NOTACIÓN DE REQUERIMIENTOS DE USUARIO URN).

Lenguaje de especificación (UML) Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. UML, emergió en los años 90 luego de la búsqueda de un lenguaje de modelamiento que unificara a la industria. A pesar de que UML evolucionó de varios métodos orientados al objeto de segunda generación (en nivel de notación), su alcance extiende su uso más allá de sus predecesores.

TIPOS DE ESPECIFICACIÓN: TEXTUAL, NOTACIÓN GRÁFICA Y LENGUAJES DE REPRESENTACIÓN (LENGUAJE UNIFICADO DE MODELADO UML Y NOTACIÓN DE REQUERIMIENTOS DE USUARIO URN).

Notación 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 derequerimientos, es decir, deben describir toda la funcionalidad que el sistema deberáimplementar.

No ambiguos. Cada requerimiento debe tener una sola interpretación.

Debiendo poder expresarse de una manera sencilla, clara y sin ambiguedades usando:- Lenguaje natural (español).- Lenguajes gráficos (UML)- Lenguajes formales (Notación Z).

Relevantes. Importancia para el sistema software a implementar.

Traceables. Cada acción de diseño debe corresponderse con algún requerimiento delcliente (resuelve un problema de este).

Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando métricasque faciliten su verificación.

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. Ningún requerimiento puede estar en conflicto con otro. Tipos deinconsistencias:

-Términos conflictivos: Si dos términos se usan en contextos diferentes para la misma cosa.

-Características 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 Ingeniería 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 electrónico 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 Definición de Requerimientos (DDR)- Documento de Especificación de Requerimientos (DER)

Nombres: Especificación funcional, Definición de requisitos, Especificación de los requisitos de software

El documento describe: Los servicios y funciones que el sistema debería 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. Información acerca del dominio de aplicación del sistema, por ej. cómo

llevar a cabo tipos particulares de cálculos. Restricciones sobre el proceso usado para desarrollar el sistema glosario

Documento de requisitos

Usuarios del documento de requisitos

Clientes del sistemaEspecifican 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 validación 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 Especificación de Requerimientos (DER)• Describe detalladamente los requerimientos contenidos en el DDR.• Está orientado a los desarrolladores.• Tiene un carácter técnico. • Los requerimientos se describen en un lenguaje o notación técnica.- Ejemplo: UML, SADT, ER

Documento de Definición de Requerimientos (DDR)• Describe los requerimientos de alto nivel desde la perspectiva de losclientes y/o usuarios.• Está orientado a los clientes y/o usuarios.• Los requerimientos se describen en lenguaje natural (español)

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

• El estándar IEEE - Propuesto por el Institute of Electrical and Electronics Engineers (IEEE)- Agrupa los documentos DDR y DER en un solo documento.- Es también un estándar ANSI

• La plantilla Volere.- Permite documentar cada requerimiento mediante un formato especial.

EL ESTÁNDAR IEEE-830-1993

Modelo IEEE/ANSI 830-1998 Introducción

• 1.1.Propósito del documento de requisitos• 1.2.Alcance del proyecto• 1.3.Definiciones, acrónimos y abreviaturas• 1.4.Resumen del resto del documento

Descripción General• 2.1.Perspectiva del producto• 2.2.Funciones del producto• 2.3.Características de los usuarios• 2.4.Limitaciones generales• 2.5.Suposiciones y dependencias

Requisitos Específicos• 3.1.Requisitos funcionales, no funcionales

Apéndices Índice

IEEE Std. 830-1998 [IEEE, 1999b]1. Introducción 1.1. Objetivo 1.2. Ámbito 1.3. Definiciones, acrónimos y abreviaturas 1.4. Referencias 1.5. Descripción del resto del documento2. Descripción general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Características del usuario 2.4. Limitaciones generales 2.5. Supuestos y dependencias3. Requisitos específicos 3.1. Requisitos funcionales 3.2. Requisitos de interfaz externa 3.3. Requisitos de ejecución 3.4. Restricciones de diseño 3.5. Atributos de calidad 3.6. Otros requisitosApéndicesÍndice

3. Requisitos específicos 3.1. Requisitos funcionales 3.1.1. Requisito funcional 1 3.1.1.1. Introducción 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 ejecución 3.4. Restricciones de diseño 3.4.1. Acatamiento de estándares 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. Adaptación de situación

[Durán y Bernárdez, 2002]

PortadaLista de cambiosÍndiceLista de figurasLista de tablas1. Introducción2. Participantes en el proyecto3. Descripción del sistema actual4. Objetivos del sistema5. Catálogo de requisitos del sistema 5.1 Requisitos de información 5.2 Requisitos funcionales 5.2.1 Diagramas de casos de uso 5.2.2 Definición de actores 5.2.3 Casos de uso del sistema 5.3 Requisitos no funcionales6. Matriz de rastreabilidad

objetivos/requisitos7. Glosario de términos8. Conflictos pendientes de resolución [opcional, pueden ir en un documento aparte]Apéndices [opcionales]

Plantilla Volere