Universidad Nacional del Altiplano

Escuela de Post grado

Maestría en Informática

“Introducción a la Ingeniería de Software”

Presentado por: Msc. Nestor Huaracha Velasquez

Puno, julio- 2012

1/21
Definición de Requisitos de
Software ....

2
 Definición de Req. de Software (SR).
• El propósito es analizar las definiciones de requisitos de
usuarios en el URD, y producir un conjunto de requisitos de
software lo más completo, consistentes y correctos
posibles.
• El SRD (Doc. de Req. de Soft.) contiene una visión del problema,
desde el punto de vista del desarrollador, y no del usuario.
• Deben usarse prototipos para validar los requisitos (es
recomendable).

RU RS

3
 SR: Entradas / Actividades
Entradas:
• Documento de Requisitos de Usuarios (URD),
última versión;
• El estándar establece otras entradas, pero no las
consideraremos para nuestro desarrollo.

Actividades:
• Construcción del Modelo Lógico.
• Especificación de los Requisitos de Software a
través del SRD.
• Revisiones del SRD.
4
 SR: Actividades de la Fase
Construcción del Modelo Lógico:
– Construcción de un modelo
independiente de la implementación del
sistema requerido por el usuario.
– Puede ser construido por
descomposición “top-down” de la
función principal, inferido del URD, en una
jerarquía de funciones.
– Pueden realizarse Caminatas
(“Walkthroughs”), revisiones e
inspecciones para asegurar que se
cumplen las especificaciones de cada
nivel, antes de descender al siguiente.
– En esta etapa puede reemplazarse
parcialmente por diagramas de casos de
uso.

5
 Actividades de la Fase
Construcción del modelo lógico debe
satisfacer las siguientes reglas:

– Las funciones (o componentes) deben tener

un propósito único. Sus nombres deben tener
una estructura declarativa (qué hacen, en vez de
cómo lo hacen).

– Las funciones deben estar en el nivel

apropiado (de granularidad) en el que aparecen.

– Las interfaces entre módulos o funciones deben

minimizarse.

6
 Actividades de la Fase

Construcción del modelo lógico debe satisfacer las

siguientes reglas:
– Cada función debe descomponerse en no más
de 7 sub-funciones.
– El modelo debe omitir información de
implementación.
– Deben especificarse los atributos de
rendimiento de cada función (capacidad,
velocidad, etc.).
– Se deben identificar las funciones críticas.
– Se deben utilizar herramientas CASE para
construir el modelo lógico (dentro de lo posible).

7
 Ejemplo

Definir los requisitos de usuario y

software de un chat

8
 Actividades de la Fase
Requisitos de Software… Se recomienda identificar los:
– Requisitos funcionales.
– Requisitos de interfaces.
– Requisitos operacionales.
– Requisitos de recursos.
– Requisitos de verificación.
– Requisitos de usabilidad.
– Requisitos de mantención.
– Requisitos de transportabilidad.
– Requisitos de confiabilidad.
– Requisitos de rendimiento.
– Requisitos de documentación.
– Requisitos de escalabilidad.

El estándar establece además requisitos de:

– Requisitos de tests de aceptación.
– Requisitos de seguridad de la información.
– Requisitos de calidad.
9
– Requisitos de seguridad de la operación.
 Actividades de la Fase

Revisiones del SRD:

– Las salidas de esta fase deben ser

revisadas formalmente durante la etapa de
Revisión de Requisitos de Software (SR/R).

– Debiese ser una revisión técnica.

– Los participantes deben ser los usuarios,

personal de operaciones, desarrolladores
y administrador de proyectos.

10
 Clasificación de Req. de Software
• Requisitos Funcionales.
– Especifican qué debe hacer el software. Se derivan del modelo lógico.

• Requisitos de Interfaces (de interacción).

– Especifican hardware, software o elementos de bases de datos con los que el

sistema o sus componentes interactúan o se comunican.

– Deben ser clasificados en requisitos de interfaces de software, hardware y

comunicaciones.

– Pueden utilizarse diagramas de bloques para ilustrar parte de este tipo de

requisitos.

• Requisitos Operacionales.

– Especifican la forma en que correrá el sistema y cómo se comunicará con los

operadores humanos.

– Incluyen todas las interfaces de usuario, interacción humano-computador, y

requisitos logísticos y organizacionales. Por ejemplo, se usará
teclado/mouse?, ¿cuán fácil de usar será el sistema?.
11
 Clasificación de Req. de Software
• Requisitos de Recursos (o uso de recursos).

– Especifican requisitos asociado al uso de los recursos físicos, tales

como: capacidad de procesamiento, memoria principal, espacio en
disco, etc.

• Requisitos de Usabilidad.

– Especifican los requisitos asociados a (las características de) la

interfaz de usuario del sistema.

– Especifican los requisitos asociados a los patrones de interfaz y de

navegación.

• Requisitos de Mantenibilidad.

– Especifica cuán fácil debe ser reparar fallas y adaptar el software a

nuevos requisitos.

– Debiera especificarse en forma cuantitativa, tal como el tiempo

medio para reparar una falla. 12
 Clasificación de Req. de Software
• Requisitos de Transportabilidad (portabilidad).

– Especifican la facilidad para utilizar el sistema en otros ambientes. Incluye

hardware, sistemas operativos o escenarios de trabajo. Incluye el esfuerzo
de realizar el transporte de una plataforma a otra.

• Requisitos de Confiabilidad.

– Especifican los tiempos medios (aceptables) entre fallas.

• Requisitos de Rendimiento.

– Establecen valores numéricos para variables medibles, asociadas a la

capacidad de procesamiento que es percibida por el usuario.

– Pueden ser incluidos en la especificación cuantitativa para cada función, o

especificados en forma independiente. Especificaciones cualitativas no son
aceptables.

– Los atributos de rendimiento deben ser presentados como rangos de

valores: peor caso, valor nominal a ser usado en la planificación; mejor
caso, para indicar potencial de crecimiento. 13
 Clasificación de Req. de Software

• Requisitos de Documentación.

– Especifica documentación adicional a la requerida en el estándar.

• Escalabilidad.

– Especifica la capacidad del sistema para mantener su rendimiento

medio, conforme aumenta el número de usuarios, procesos y/o
solicitud de servicios del sistema.

• La especificación de atributos de los requisitos es igual a la del

URD.

14
 Tipos Req de Soft. Adicionales
• Requisitos de Seguridad de la Información.

– Especifican requisitos para asegurar (proteger) la información que maneja el

sistema, contra amenazas a la confidencialidad, integridad y disponibilidad
tanto de los servicios como de los datos.

• Requisitos de Seguridad de la Operación.

– Especifican requisitos para reducir la posibilidad de daño que puede

producirse debido a una falla del software. Por ej. corrupción de la BD ante
un corte de energía, o la necesidad de apagar el servidor para poder “matar”
threads que han quedado vivos.

• Requisitos de Verificación.

– Especifican las restricciones de cómo el software se verificará.

– Pueden incluir requisitos de simulación, emulación, tests vivos con entradas

simuladas, tests vivos con entradas reales, e interfaz con ambientes de
testeo, sobrecarga o stress por transacciones.

• Requisitos de Tests de Aceptación.

– Especifica las restricciones de cómo se validará el software.

– Impone restricciones al SVVP (Software Validation and Verification Plan), si 15

éste se construye (no es el caso de nuestro proyecto).
 Completitud de Req. de Software
• Principalmente debemos considerar dos aspectos:
– ¿Se han considerado todos los requisitos de usuarios?

– ¿Se ha especificado una actividad para validar cada conjunto posible

de entradas?

• Debemos incluir una matriz de trazado (o matriz de

trazabilidad) en el SRD para probar completitud.

RS0006
RS0001

RS0002

RS0003

RS0004

RS0005

RS0007

RS0008
RU0001 X X X
RU0002 X X
RU0003 X X
RU0004 X

16
 Consistencia de Req. de Software
• Un conjunto de requisitos es consistente si y sólo si ningún
subconjunto de requisitos entra en conflicto.
• Existen muchos tipos de inconsistencias:
– Términos diferentes para nombrar el mismo objeto.
– El mismo término para nombrar diferentes objetos.
– Actividades incompatibles pasando al mismo tiempo.
– Actividades pasando en orden erróneo.

Duplicación de Requisitos
 La duplicación de requisitos debe ser
evitada. Aunque a veces es requerida
para un mejor entendimiento del SRD.

 Cuando ocurran duplicaciones, deben

hacerse referencias cruzadas para
17
mejorar alteraciones.
 Salidas de la Fase

• Documento de requisitos de software (SRD).

• Planes de testeo del sistema (Plan de Pruebas).

• El estándar establece otras salidas, pero nosotros no las

consideraremos en nuestro proyecto.

18