República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria

Ciencia y Tecnología
Universidad Nacional Experimental Rafael María Baralt
Programa Nacional de Formación en Informática
Ingeniería Del Software.

Análisis y especificaciones de
requisitos

AUTOR:
Fernández Juan C.I.: 29.586.010
Mención: P.N.F. Informática
Tutor: Eduardo Barazarte

San Francisco, Abril 2020

 ÍNDICE

Pág.

1.1.- características de requerimientos…... … ….. …. . . . … . . .. 2

1.2.- especificación de Requerimiento……………………………...…… 3
1.3.-Técnicas para Escribir Requerimientos de Alta Calidad y
Estándares de Documentación …………………..……………….……………5
1.4.- métricas del modelo………………..………………………………. 6
1.5 DOCUMENTO DE REQUISITOS DEL SISTEMA………….. ………7

1
1.1.- CARACTERISTICAS DE REQUERIMIENTOS

 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”. Los promedios de errores deben de estar cuantificados.

 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

2
 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).

1.2.- Especificación de Requerimiento.

1. Textual

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.

2. Notación Grafica y Lenguajes de Representación (Lenguaje

Unificado de Modelado UML, Notación de Requerimiento de
Usuario URN).

Notación gráfica, Incluye todas las notaciones que pueden demostrar

el flujo de información entre requisitos, apoyándose en diversas

3
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).

3. 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 '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. 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
(software y no - software), dominios (negocios versus software)
y los procesos de ciclo de vida.

UML, es en cuanto a cómo se aplica para especificar sistemas,

puede ser usado para comunicar "qué" se requiere de un
sistema y "cómo" un sistema puede ser realizado. En cuanto a
cómo se aplica para visualizar sistemas, puede ser usado para
describir visualmente un sistema antes de ser realizado. En
cuanto a cómo se aplica para construir sistemas, puede ser
usado para guiar la realización de un sistema similar a los

4
 "planos”. En cuanto a cómo se aplica para documentar
sistemas, puede ser usado para capturar conocimiento respecto
a un sistema a lo largo de todo el proceso de su ciclo de vida.

UML, no es Un lenguaje de programación visual, sino un

lenguaje de modelamiento visual Una herramienta o depósito
de especificación, sino un lenguaje para modelamiento de
especificación. Un proceso, sino que habilita procesos.

Otra notación que se puede usar es la notación de requerimientos

de usuario (URN).

1.3 Técnicas para Escribir Requerimientos de Alta Calidad y Estándares

de Documentación:

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 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).

5
1.4.- METRICAS DEL MODELO

En esta fase, las métricas técnicas proporcionan 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
relacionadas.

Dentro de las métricas del modelo de análisis tenemos:

MÉTRICAS DEL MODELO DE DISEÑO

Se concentran en las características de la arquitectura del programa, con

énfasis en la estructura arquitectónica y en la eficiencia de los módulos.

Estas métricas son de caja negra en el sentido que no requieren ningún

conocimiento del trabajo interno de un módulo en particular del sistema.

MÉTRICAS PARA PRUEBAS

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.

MÉTRICAS DEL MANTENIMIENTO

Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo

software y para el mantenimiento del existente.

El estándar IEEE 982.1-1988 sugiere el índice de madurez del software

(IMS) que proporciona una indicación de la estabilidad de un producto

6
software basada en los cambios que ocurren con cada versión del producto.
Con el IMS se determina la siguiente información:

· MT= Número de módulos en la versión

· Actual Fc = Número de módulos en la versión actual que se han

cambiado

· Fa= Número de módulos en la versión actual que se han añadido

· Fe= Número de módulos en la versión actual que se han eliminado

El índice de madurez del software se calcula de la siguiente manera:

IMS= [MT - (Fc + Fa + Fe)]/MT

A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El

IMS puede emplearse también como métrica para la planificación de las
actividades de mantenimiento del software.

1.5.- DOCUMENTO DE REQUISITOS DEL SISTEMA

Es una descripción completa del comportamiento del sistema que se

va a desarrollar. Incluye un conjunto de casos de uso que describe todas las
interacciones que tendrán los usuarios con el software. Los casos de uso
también son conocidos como requisitos funcionales. Además de los casos de
uso, la ERS también contiene requisitos no funcionales (complementarios).
Los requisitos no funcionales son requisitos que imponen restricciones en el

7
diseño o la implementación, como, por ejemplo, restricciones en el diseño o
estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje

utilizado para su redacción debe ser informal, de forma que sea fácilmente
comprensible para todas las partes involucradas en el desarrollo. Propósito
del documento:

Entregar al usuario información detallada sobre la obtención de

requerimientos.

Funciones del producto

Principalmente la creación, envío y corrección de tareas dentro de un

ramo; además funciones de mensajería.

• Características del usuario

Habrán tres tipos de usuario: el administrador, el académico y el

alumno.

• Problema del usuario

Comunicación defectuosa entre académicos y alumnos.

• Objetivo del usuario

Solucionar su problema utilizando un sistema ágil, cómodo, eficiente y

eficaz

8
 Estructura del documento de requisitos del sistema