República Bolivariana de Venezuela

Ministerio del Poder Popular Para la Educación Superior

Universidad Experimental Rafael María Baralt

Altagracia - Municipio Miranda

Edo- Zulia

Unidad III
Análisis y especificación de requisitos.

Nombre:

Michael González.

Profesor:

José Piñero.

Asignatura:

Ingeniería de software II.

 1. Características de requisitos:

 Inspección:

La inspecció n también es conocida como revisió n técnica formal, y es el

punto de vista má s efectivo desde el punto de vista de aseguramiento de
calidad, y es dirigida por los ingenieros de software u otras personas. Para
los ingenieros la inspecció n es un medio efectivo para descubrir errores y
mejorar la calidad del software”. 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.

 Validación:

Preferiblemente deben expresarse de manera cuantitativa, usando

métricas que faciliten su verificació n y validació n. Los requerimientos
deben estar escritos de forma que pueden ser objetivamente verificados: El
problema con estos requerimientos es el uso de términos “vagos” tales
como “los errores deben ser minimizados”.

 Completitud:

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.

 Detección de Conflictos:

Es importante proveer racionalidad en los requerimientos, ya que esto

ayuda al desarrollador a entender el dominio de la aplicació n y el por qué
los requerimientos se encuentran en su forma actual. Esto es importante
para el momento en que los requerimientos tienen que ser cambiados. La
disponibilidad de una racionalidad reduce el riesgo de tener efectos
inesperados.

 Inconsistencia:
 Cada requerimiento debe tener una sola interpretació n. Debiendo poder
expresarse de una manera sencilla, clara y sin ambigü edades usando: -
Lenguaje natural (españ ol). - Lenguajes grá ficos (UML) - Lenguajes
formales (Notació n Z).

2. Tipos de especificación:

 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 el 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 É stas 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).

 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. UML es
usado para la comunicació n. Es decir, un medio para capturar el
conocimiento (semá nticas) respecto a un tema y expresar el conocimiento
(sintaxis) resguardando el tema propó sito de la comunicació n.  Como un
lenguaje para modelamiento, se enfoca en la comprensió n de un tema a
través de la formulació n de un modelo del tema (y su contexto
respectivo).  Cuidando la unificació n, integra las mejores prá cticas de la
ingeniería de la industria tecnoló gica y sistemas de informació n pasando
por todos Los tipos de sistemas y los procesos de ciclo de vida. UML se
aplica para especificar sistemas, puede ser usado para comunicar "qué" se
requiere de un sistema y "có mo" un sistema puede ser realizado. Se aplica
para visualizar sistemas, puede ser usado para describir visualmente un
sistema antes de ser realizado. Puede ser usado para guiar la realizació n de
un sistema similar a los "planos". Asimismo, puede ser usado para capturar
conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo
de vida.

 URN.
Fue una iniciativa de la Internet Engineering Task Force IETF, la rama de
desarrollo de ingeniería y protocolos de Internet, con la premisa de
conseguir una forma universal de identificació n de recursos, para que cada
recurso fuera ú nico y constante. Se trataba de un identificador paralelo al
URL. Una característica importante de este sistema es que trabaja junto
con Uniform Resource Characteristics/Citacion (URC), un sistema para
la descripció n de metadatos. La sintaxis del URN, consta de 3 bloques
separados por dos puntos: el identificador URN, el NID o nombre de la
categoría en la que se incluye el documento (por ejemplo, inet para
documentos de Internet) y el NSS o cadena específica que indica primero la
ruta y a continuació n el documento concreto. URN es una notació n pensada
para la especificació n, aná lisis y validació n de los requisitos de usuario.
URN combina dos vistas complementarias: una para definir los objetivos
del sistema usando el Goal-oriented Requirement Language (GRL) y otra
para definir los escenarios de uso con la notació n Use Case Map (UCM).
3. Estándares para escribir requisitos de alta calidad
En todas las técnicas involucradas descritas en la unidad I de la
ingeniería de requerimientos, las actividades y características 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 informació n 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 implementació n.

• Traducir las necesidades de usuario escritas dentro de las

especificaciones y modelos de requerimientos

• Examinar los requerimientos documentados para asegurar el

conocimiento comú n 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 diseñ o, có digo fuente y pruebas.

• Agrupar los requerimientos segú n rendimiento y actividad de cambio

durante todo el proyecto.

• La iteració n es una clave para el éxito del desarrollo de los

requerimientos.

4. Documento De Requisitos (DRS)

El documento de requerimientos de software, es el lugar donde se da

descripció n a las características y requisitos de un software, producto,
programa o conjunto de programas. Los requisitos se expresan en lenguaje
natural, sin consideraciones ni términos técnicos. La especificació n de
requisitos de software es el resultado del levantamiento de informació n
con el usuario o cliente del producto. Son un método para una
comunicació n má s concisa y clara entre los encargados de desarrollar el
software y el á rea de negocio o clientes que usaran el producto.

Un modelo de có mo elaborar un documento de requerimientos de

software. La plantilla sigue los lineamientos establecidos en el está ndar
IEEE 830, segú n el cual la especificació n de requisitos debe contener la
descripció n de la funcionalidad de la aplicació n, relació n con sistemas
externos y requerimientos no funcionales como de rendimiento,
disponibilidad, tiempos de respuesta, mantenibilidad entre otros.

5. Métricas Modelo de Análisis

La medició n es esencial para cualquier disciplina de ingeniería y la

ingeniería de sistemas no es una excepció n. Las métricas de sistemas se
refieren a un amplio rango de medidas para el sistema de computadoras
dentro del contexto de la planificació n del proyecto de sistemas, las
métricas de calidad pueden ser aplicadas a organizaciones, procesos y
productos los cuales directamente afectan a la estimació n de costos. En este
existen métricas que podemos utilizar para evaluar lo que estamos
haciendo en ingeniería de sistema. Y es lo que veremos má s adelante:

La métrica tiene varios atributos importantes en lo que cabe mencionar:

 Simple y calculable Persuasiva.

 Consistente y Objetiva
 Consistente en sus unidades
 Independiente del lenguaje Eficaz.

 Métricas para Análisis

En esta fase es deseable que las métricas-técnicas proporcionen una

visió n interna a la calidad del modelo de aná lisis. Estas métricas examinan
el modelo de aná lisis con la intenció n de predecir el “tamañ o” del sistema
resultante; es probable que el tamañ o y la complejidad del diseñ o estén
directamente relacionados. 

 La Métrica Bang

Puede aplicarse para desarrollar una indicació n del tamañ o del sistema a
implementar como consecuencia del modelo del aná lisis.

 Métricas de la Calidad de la Especificación

En estas métricas se emplea una lista de características que pueden

emplearse para valorar la calidad del modelo de aná lisis y la
correspondiente especificació n de requisitos.

 Métricas De Prueba
 La mayoría de las métricas para pruebas se concentran en el proceso de
prueba, no en las características técnicas de las pruebas mismas. En
general, los responsables de las pruebas deben fiarse en las métricas de
aná lisis, diseñ o y có digo para que sirvan de guía en el diseñ o y ejecució n de
los casos de prueba.

El esfuerzo de las pruebas también se puede estimar utilizando métricas

obtenidas de las medidas de Halstead. Usando la definició n del volumen de
un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del
software puede calcularse como: NP = 1/ [(n1/2) x (N2/n2)] n1: no de
operadores diferentes n2: no de operados diferentes N2: no total de
Operados Métricas de, Proyecto. En este punto, trataremos de reflejar lo
que es la productividad y los dos tipos fundamentales que tiene que ver
con:

 La Métrica Del Punto De Función (PF)

Se puede utilizar como medio para predecir el tamañ o de un sistema

obtenido a partir de un modelo de aná lisis. Para visualizar esta métrica se
utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las
siguientes medidas clave que son necesarias para el cá lculo de la métrica de
punto defunció n:

 Métricas Basadas en Función

La métrica de punto de funció n (PF) se puede usar como medio para

predecir el tamañ o de un sistema que se va a obtener de un modelo de
aná lisis. Para instruir el empleo de la métrica PF, se considerará una
sencilla representació n del modelo de aná lisis. En donde se representa un
diagrama de flujo de datos, de una funció n de una aplicació n de software
llamada Hogar Seguro.

La funció n administra la interacció n con el usuario, aceptando una

contraseñ a de usuario para activar/ desactivar el sistema y permitiendo
consultas sobre el estado de las zonas de seguridad y varios censores de
seguridad. La funció n muestra una serie de mensajes de
petició n y envía señ ales apropiadas de control a varios componentes del
sistema de seguridad.