Unidad 3: Analisis y Especificació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 lenguajes de
representación (Lenguaje Unificado de Modelado UML y Notación de
Requerimientos de Usuario URN).
3. Estándares para escribir requisitos de alta calidad.
4. Documento de Requisitos (DRS).
5. Métricas de modelado de Análisis.
1. INTRODUCCION.
La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo
que quiere el cliente, analizando necesidades, confirmando su viabilidad,
negociando una solución razonable, especificando la solución sin ambigüedad,
validando la especificación y gestionando los requisitos para que se
transformen en un sistema realmente operacional. Los requerimientos para un
sistema de software determinan lo que hará el sistema y definen las
restricciones de su operación e implementación.
El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos:
identificación de requisitos, Análisis de requisitos y negociación, Especificación
de requisitos, Modelado del sistema, Validación y gestión de requisitos.

El propósito de la siguiente producción escrita, es desarrollar más a fondo

aspectos que tienen como objetivo primordial finiquitar los detalles finales para
el acabado de un sistema software previamente modelado, la
inspección,validación, completitud, detección de conflictos, inconsistencia de
requerimientos, así como también la determinación de requerimientos,
creación e importancia, Finalizando Así con las métricas para la ingeniería de
requisitos.

Análisis de requisitos

 Se denomina análisis a la distinción y separación de las partes de un todo

hasta llegar a conocer sus principios o elementos [RAE, 2001].

 Esta actividad es parte del subproceso de aseguramiento de la calidad.

 Tiene como objetivo principal detectar conflictos en los requisitos

obtenidos, normalmente mediante técnicas de modelado conceptual y de
prototipo de interfaz de usuario.

 Los modelos generados son también una importante herramienta de

comunicación con diseñadores y programadores.

2. Resúmen. (ESP.)

3. Abstract. (ING.)

4. Palabras Cláves.

Análisis y Especificación de Requisitos. Características de requisitos:

inspección, validación, completitud, detección de conflictos e inconsistencias
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). Estándares para escribir requisitos de alta
calidad. Documento de Requisitos (DRS). Métricas de modelado de Análisis.
 5. Contenido

Características de requisitos: inspección, validación,

completitud, detección de conflictos e inconsistencias de
requisitos.

INSPECCIÓN

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

(1998)”

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

de vista mas 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” (p.165).

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 .

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

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

El Lenguaje de Modelado Unificado (UML) es “un lenguaje estándar para

escribir diseños de software. El UML puede usarse para visualizar, especificar,
construir y documentar los artefactos de un sistema de software intensivo”
[Boo05]. Los ingenieros de software crean diagramas de UML para ayudar a los
desarrolladores de software a construir el software. Si usted entiende el
vocabulario del UML (los elementos pictóricos de los diagramas y su
significado) puede comprender y especificar con mucha más facilidad un
sistema, y explicar su diseño a otros.

DIAGRAMAS DE CLASE

Para modelar clases, incluidos sus atributos, operaciones, relaciones y

asociaciones con otras clases, el UML proporciona un diagrama de clase, que
aporta una visión estática o de estructura de un sistema, sin mostrar la
naturaleza dinámica de las comunicaciones entre los objetos de las clases.

Los elementos principales de un diagrama de clase son cajas, que son los
iconos utilizados para representar clases e interfaces. Cada caja se divide en
partes horizontales. La parte superior contiene el nombre de la clase. La
sección media menciona sus atributos.

Atributo

Un atributo es algo que un objeto de dicha clase conoce o puede proporcionar

todo el tiempo. Por lo general, los atributos se implementan como campos de la
clase, pero no necesitan serlo. Podrían ser valores que la clase puede calcular a
partir de sus variables o valores instancia y que puede obtener de otros objetos
de los cuales está compuesto.

Cada atributo puede tener un nombre, un tipo y un nivel de visibilidad. El tipo y

la visibilidad son opcionales. El tipo sigue al nombre y se separa de él mediante
dos puntos. La visibilidad se indica mediante un –, #, ~ o + precedente, que
indica, respectivamente, visibilidad privada, protegida, paquete o pública. En la
figura A1.1, todos los atributos tienen visibilidad privada, como se indica
mediante el signo menos que los antecede (–). También es posible especificar
que un atributo es estático o de clase, subrayándolo. Cada operación puede
desplegarse con un nivel de visibilidad, parámetros con nombres y tipos, y un
tipo de retorno.

Una clase abstracta o un método abstracto se indica con el uso de cursivas en

el nombre del diagrama de clase.
Una asociación entre dos clases significa que existe una relación estructural
entre ellas. Las asociaciones se representan mediante líneas sólidas. Una
asociación tiene muchas partes opcionales. Puede etiquetarse, así como cada
una de sus terminaciones, para indicar el papel de cada clase en la asociación.

Las flechas en cualquiera o en ambos lados de una línea de asociación indican

navegabilidad. Además, cada extremo de la línea de asociación puede tener un
valor de multiplicidad desplegado.

Una asociación también puede conectar una clase consigo misma, mediante un
bucle. Tal asociación indica la conexión de un objeto de la clase con otros
objetos de la misma clase.

Una asociación con una flecha en un extremo indica navegabilidad en un

sentido.

La flecha significa que, desde una clase, es posible acceder con facilidad a la
segunda clase asociada hacia la que apunta la asociación; sin embargo, desde
la segunda clase, no necesariamente puede acceder con facilidad a la primera
clase. Otra forma de pensar en esto es que la primera clase está al tanto de la
segunda, pero el segundo objeto de clase no necesariamente está
directamente al tanto de la primera clase. Una asociación sin flechas por lo
general indica una asociación de dos vías, pero también simplemente podría
significar que la navegabilidad no es importante y, por tanto, que queda fuera.

Una relación de dependencia representa otra conexión entre clases y se indica

mediante una línea punteada (con flechas opcionales en los extremos y con
etiquetas opcionales). Una clase depende de otra si los cambios en la segunda
clase pueden requerir cambios en la primera. Una asociación de una clase con
otra automáticamente indica una dependencia. No se necesitan líneas
punteadas entre clases si ya existe una asociación entre ellas. Sin embargo,
para una relación transitoria (es decir, una clase que no mantiene alguna
conexión de largo plazo con otra, sino que usa dicha clase de manera
ocasional), debe dibujarse una línea punteada desde la primera clase hasta la
segunda.

La multiplicidad de un extremo de una asociación significa el número de

objetos de dicha clase que se asocia con la otra clase. Una multiplicidad se
especifica mediante un entero no negativo o mediante un rango de enteros.
Una multiplicidad especificada por “0..1” significa que existen 0 o 1 objetos en
dicho extremo de la asociación.

Si un extremo de una asociación tiene multiplicidad mayor que 1, entonces los

objetos de la clase a la que se refiere en dicho extremo de la asociación
probablemente se almacenan en una colección, como un conjunto o lista
ordenada. También podría incluirse dicha clase colección en sí misma en el
diagrama UML, pero tal clase por lo general queda fuera y se supone, de
manera implícita, que está ahí debido a la multiplicidad de la asociación.
Una agregación es un tipo especial de asociación que se indica mediante un
diamante hueco en un extremo del ícono. Ello indica una relación
“entero/parte”, en la que la clase a la que apunta la flecha se considera como
una “parte” de la clase en el extremo diamante de la asociación. Una
composición es una agregación que indica fuerte propiedad de las partes. En
una composición, las partes viven y mueren con el propietario porque no tienen
papel en el sistema de software independiente del propietario.

DOCUMENTOS DE REQUISITOS.

Documentos de Requerimientos de Software: Creación, Usos

e Importancia.

2.- Documentos de Requerimientos de Software: Creación, Usos e Importancia.

Creación: 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 y herramientas para la ingeniería de Requisitos.

 Una métrica es un instrumento que cuantifica un criterio.

 Una estructura de proyecto que sirve de guía al equipo de trabajo e
involucra a los usuarios y a los puestos directivos en su desarrollo y en
sus puntos decisivos.
 Un conjunto de productos finales a desarrollar.
 Las diferentes responsabilidades y funciones de los miembros del equipo
de proyecto y de los usuarios.
  Una serie de técnicas que ayudan a llevar a cabo los pasos anteriores.
Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y
esfuerzo humano requerido por medio de las mediciones de software que se
utilizan para recolectar los datos cualitativos acerca del software y sus
procesos para aumentar su calidad.

Las Métricas.
En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender
tanto el proceso técnico que se utiliza para desarrollar un producto, como el
propio producto. El proceso para intentar mejorarlo, el producto se mide para
intentar aumentar su calidad.
El principio, podría parecer que la necesidad de la medición e s algo evidente.
Después de todo es lo que nos permite cuantificar y por consiguiente gestionar
de forma más efectiva. Pero la realidad puede ser muy deferente.
Frecuentemente la medición con lleva una gran controversia y discusión.
La medición es muy común en el mundo de la ingeniería. Medimos potencia de
consumo, pesos, dimensiones físicas, temperaturas, voltajes, señales de ruidos
por mencionar algunos aspectos.
Desgraciadamente la medición se aleja de lo común en el mundo de la
ingeniería del software.
Encontramos dificultades en ponernos de acuerdo sobre que medir y como va
evaluar las medidas. Hay varias razones para medir un producto.
1. Para indicar la calidad del producto.
2. Para evaluar la productividad de la gente que desarrolla el producto.
3. Par evaluar los beneficios en términos de productividad y de calidad,
derivados del uso de nuevos métodos y herramientas de la ingeniería de
software.
4. Para establecer una línea de base para la estimación
5. Para ayudar a justificar el uso de nuevas herramientas o de formación
adicional.
Las mediciones del mundo físico pueden englobarse en dos categorías:
medidas directas y medidas indirectas. Medidas Directas. En el proceso de
ingeniería se encuentran el costo, y el esfuerzo aplicado, las líneas de código
producidas, velocidad de ejecución, el tamaño de memoria y los defectos
observados en un determinado periodo de tiempo.
Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de mantenimiento, etc.
MÉTRICAS DEL SOFTWARE.
Son las que están relacionadas con el desarrollo del software como
funcionalidad, complejidad, eficiencia.
MÉTRICAS TÉCNICAS: Se centran en las características de software por
ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del
sistema, el cómo está hecho.
MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el
software a los requisitos implícitos y explícitos del cliente. Es decir cómo voy a
medir para que mi sistema se adapte a los requisitos que me pide el cliente.
MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la
ingeniería del software. Es decir que tan productivo va a ser el software que
voy a diseñar.
MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información
sobre la forma que la gente desarrolla el software de computadoras y sobre
todo el punto de vista humano de la efectividad de las herramientas y
métodos. Son las medidas que voy a hacer de mi personal que va hará el
sistema.
MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en qué tiempo voy a
terminar el software y cuantas personas voy a necesitar. Son medidas directas
al software y el proceso por el cual se desarrolla, si una organización de
software mantiene registros sencillos.
MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y
del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las
métricas orientadas a la función se centran en la funcionalidad o utilidad del
programa.
Las métricas orientadas a la función fueron el principio propuestas por Albercht
quien sugirió un acercamiento a la medida de la productividad denominado
método del punto de función. Los puntos de función que obtienen utilizando
una función empírica basando en medidas cuantitativas del dominio de
información del software y valoraciones subjetivos de la complejidad del
software.
1 - Inicio del Plan: Determina el arranque formal del plan de sistemas, con el
apoyo del nivel más alto de la organización.
2 - Definición y Organización: Detalla y concreta la descripción del PSI
asignando un calendario y recursos humanos al mismo
3 - Estudio información relevante: Se analiza información de interés para el
correcto desarrollo del plan de sistemas
4 - Identificación Requisitos: Obtiene la especificación de requisitos que deben
tener los sistemas de información analizados por el plan de sistemas.
5 - Estudio S.I. Actuales: Obtiene una valoración de la situación actual.
6 - Diseño modelo: Identifica y define los S.I. Que van a dar soporte a los
procesos afectados por el Plan de Sistemas de Información
7 - Arquitectura tecnológica: Se propone la arquitectura tecnológica que dé
soporte al modelo de información y sistemas de información.
8 - Definición plan: Se elabora y detalla el plan de sistemas de información:
definición de proyectos, actividades, calendario y recursos para implementar
los sistemas de información e infraestructura tecnológica
9 - Revisión y aprobación: Se somete el plan a la revisión última y aprobación
de la dirección.
10 – documentación: Catálogo de requisitos
Arquitectura de información
Modelo de información
Modelo de sistemas de información
Arquitectura tecnológica
Plan de acción
Plan de proyectos
Plan de mantenimiento.
Fases de la métrica:
a) METRICAS COMO PLANEACION DE SISTEMAS
b) LOS OBJETIVOS PRINCIPALES DE LAS MÉTRICAS
 Comprender mejor la calidad del producto.
 Estimar la efectividad del proceso.
 Mejorar la calidad del trabajo realizado en el nivel del proyecto.
c) DESVENTAJAS DE LAS METRICAS
Uno de los problemas que tienen las métricas es que no existe un esquema de
criterios generalmente aceptado (un estándar). Como no hay acuerdo en los
criterios involucrados, abundan las propuestas de métricas que abordan la
calidad con criterios propios.
Otro problema de las métricas es que no proporcionan información por sí solas
y a veces en vez de claridad aportan confusión a la contraparte del modelador
dentro del proceso. Esto se debe a que muchas métricas no guardan relación
con los intereses de las partes, y el indicador de la calidad de un esquema se
construye generalmente con todas ellas.
CARACTERISTICAS DE LAS METRICAS
Localización: La localización es una característica del software que indica la
forma que se concentra la información dentro de un programa.
Encapsulamiento: define el encapsulamiento como “el empaquetamiento (o
enlazado) de una colección de elementos. Entre los ejemplos de
encapsulamiento de bajo nivel (software convencional) se cuentan los registros
y matrices, y los subprogramas (por ejemplo, procedimientos, funciones,
subrutinas y párrafos) son mecanismos de nivel medio para el
encapsulamiento”. El encapsulamiento influye en las métricas cambiando el
objetivo de la medida, que pasa de ser un único módulo a ser un paquete de
datos (atributos) y de módulos de procesamiento (operaciones). Además, el
encapsulamiento impulsa a la medida hasta un nivel de abstracción más
elevado.
Ocultamiento de información: El ocultamiento de información suprime los
detalles operativos de un componente de un programa. Tan sólo se proporciona
la información necesaria para acceder a ese componente o a aquellos otros
componentes que deseen acceder a él.
Herencia: La herencia es un mecanismo que hace posible que los compromisos
de un objeto se difundan a otros objetos. La herencia se produce a lo largo de
todos los niveles de la jerarquía de clases
Abstracción: La abstracción es un mecanismo que permite al diseñador
centrarse en los detalles esenciales de algún componente de un programa
(tanto si es un dato como si es un proceso) sin preocuparse por los detalles de
nivel inferior.

6. Finalidad.

7. Conclusión.