UNIDAD #3 Análisis y Especificación de Requisitos

REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA

UNIVERSIDAD NACIONAL EXPERIMENTAL “RAFAEL MARÍA BARAL”
PROGRAMA NACIONAL DE FORMACIÓN EN INFORMÁTICA
ASIGNATURA: INGENIERÍA DEL SOFTWARE
UNIDAD 3
ANÁLISIS Y ESPIFICACIÓN DE REQUISITOS
Realizado por:
Luis Escorcia
C.I.: V.-27.104.669
Tramo: Trimestre 3-1
Profesor: Barazarte Eduador
San francisco, abril de 2020

ESQUEMA
CONTENIDO: UNIDAD 3 ANÁLISIS Y ESPIFICACÍÓN DE REQUISITOS

1.- Características de Requisitos:
 Inspección
 Validación
 Completitud
 Detección de Conflictos e Inconsistencias de Requisitos
2.- Tipos de Especificación:
 Textual
 Notación
 Gráfica y Lenguaje de Representación (Lenguaje Unificado del
Modelado UML y Notación de Requerimientos de Usuario URN).
3.- Estándares para escribir Requisitos de Alta Calidad
4.- Documentación de Requisitos
5.- Métricas de Modelado de Análisis.
DESARROLLO
TEMA: UNIDAD 3 ANÁLISIS Y ESPIFICACÍÓN DE REQUISITOS

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”. 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 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, 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 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 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 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).
 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 "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).
Técnicas para escribir requerimientos 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.
Documento de Requisitos (DRS):

El resultado del proceso de definición de requerimientos es un
Documento de Requerimientos elaborado por el usuario, que servirá como
base para el análisis y diseño del sistema de información. Para la
elaboración del documento se presenta a continuaciones definiciones, pasos
y características propias de un requerimiento.
Usos:
Comunicar de manera precisa los requerimientos, objetivos y
presunciones del dominio. Contrato – legal, documento interno o a modo de
memorando. Base para estimación (tamaño, costo, tiempo) y planificación de
proyecto. Base para evaluación de producto final – verificación y validación –
Debería tener suficiente información para decidir si el producto final es
aceptable (satisface los requerimientos). Base para el control de cambios –
Requerimientos cambian, software evoluciona, el entorno evoluciona.
Importancia:
En este documento de especificación de requisitos se plasma lo que el
sistema es esencia, y su importancia radica en evitar el malentendido de
determinadas situaciones, ya que el cliente participa activamente en la
elaboración del documento. Basándose en estos requisitos, el ingeniero de
software procederá al modelado de la futura aplicación. Este documento es
de mucha utilidad en el futuro ya que permite a los usuarios aprender el
funcionamiento del sistema en un nivel básico.
Métricas Modelo de Análisis:
Métricas
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.
Criterios-Atributos que debe tener toda métrica para poder ser

aceptable. Métricas para: Análisis Diseño Codificación Prueba de Proyecto
orientadas a (tamaño y funcionalidad) Atributos de una Métrica
La métrica tiene varios atributos importantes en lo que cabe mencionar:

A. Simple y calculable Persuasiva.
B. Consistente y Objetiva
C. Consistente en sus unidades
D. 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.
REFERENCIAS BIBLIOGRÁFICAS
 https://es.scribd.com/document/412651837/Analisis-y-Especificacion-
de-Requisitos-pdf

UNIDAD #3 Análisis y Especificación de Requisitos

Cargado por

Copyright:

Formatos disponibles

UNIDAD #3 Análisis y Especificación de Requisitos

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UNIDAD #3 Análisis y Especificación de Requisitos

Cargado por

Copyright:

Formatos disponibles

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN UNIVERSITARIA

San francisco, abril de 2020

CONTENIDO: UNIDAD 3 ANÁLISIS Y ESPIFICACÍÓN DE REQUISITOS

TEMA: UNIDAD 3 ANÁLISIS Y ESPIFICACÍÓN DE REQUISITOS

 Inspección: La inspección también es conocida como revisión técnica

 Validación: Preferiblemente deben expresarse de manera

 Completitud: Todo lo que el software tiene que hacer está recogido

 Detección de Conflictos: Es importante proveer racionalidad en los

2.- Tipos de Especificación: Textual, Notación gráfica y Lenguajes de

 Textual: Tradicionalmente la especificación de requisitos se ha

 Notación Grafica y Lenguajes de Representación (Lenguaje Unificado

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

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

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

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

Documento de Requisitos (DRS):

Métricas Modelo de Análisis:

Criterios-Atributos que debe tener toda métrica para poder ser

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

Métricas para Análisis:

También podría gustarte