ingenieria de requisitos - ingeniería de software

Bases de Datos

Ingeniería de Requisitos

Ingeniería de requisitos

Requerimientos

¿Que es el proceso de Ingeniería de Requisitos?

Puntos clave


!

!


Técnicas de recolección de Información !

REPASOCuestionario: Medio/instrumento de recogida de

información de manera directa o de preparación para una entrevista.

Entrevistas: Intento sistemático de recoger información de otra persona a través de una comunicación interpersonal que se lleva a cabo mediante una conversación estructurarda.


EJERCICIO DE !

COMUNICACIÓN (armado de figuras)


Ejercicio. Captura y Análisis de Requisitos

Instrucciones: !

Elaborar un cuestionario para la captación y análisis de requisitos de un sistema de gestión de ordenes de servicio de una lavandería.


Especificación de requisitos: Ejercicio

Instrucciones: !De acuerdo al proyecto establecido para la captación de requisitos de cada equipo de trabajo, realizar, redactar una primera propuesta de contenido haciendo uso del estandar IEEE 830 para los siguientes puntos:

a) Introducción !b) Objetivo !c) Ámbito !d) Visión Global


Análisis de Requerimientos Herramientas y Técnicas


Estrategia de captación de requisitos



Formato estándar IEE830

Ejercicio: !Elaborar un Diagrama de Contexto para el siguiente ejemplo de sistema de gestión de l i b r o s d e u n a biblioteca


Ejercicio: !I d e n t i fi c a r l o s requisitos funcionales p a r a e l s i g u i en t e ejemplo de sistema de gestión de libros de una biblioteca. Hacer uso del formato de requisitos específicos del estandar IEEE 830 (sección 3)


PETICIÓN DE LIBROS

DEVOLUCIÓN DE LIBROS

ALTAS/BAJAS

GESTIÓN DE

BIBLIOTECA


REQUISITOS ESPECÍFICOS


TAREA Distribución de Libros


REQUERIMIENTOS !

• FUNCIONALES !

• NO FUNCIONALES


Requerimientos Funcionales

Son declaraciones de los servicios y funciones que proveerá el sistema. En algunos casos los requerimientos funcionales de los sistemas también declaran explicitamente lo que el sistema no debe hacer.

Conforman restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

Requerimientos No Funcionales


Definición de acciones fundamentales que debe realizar el software al recibir información, procesarla y producir resultados.

Requisito Funcional IEE830

En ellas se incluye: !♣ Comprobación de validez de las entradas ♣ Secuencia exacta de operaciones ♣ Respuesta a situaciones anormales (desbordamientos,

comunicaciones, recuperación de errores) ♣ Parámetros ♣ Generación de salidas ♣ Relaciones entre entradas y salidas (secuencias de

entradas y salidas, formulas para la conversión de información)

♣ Especificación de los requisitos lógicos para la información que será almacenada en base de datos (tipo de información, requerido)


Rendimiento

Seguridad

Requisito No Funcional IEE830

Fiabilidad

Disponibilidad

Mantenibilidad

Portabilidad

Otros


Especificación de los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que deberá soportar el sistema, etc. !Todos estos requisitos deben ser mesurables. Por ejemplo, indicando “el 95% de las transacciones deben realizarse en menos de 1 segundo”, en lugar de “los operadores no deben esperar a que se complete la transacción”.

Rendimiento

SeguridadEspecificación de elementos que protegerán al software de accesos, usos y sabotajes maliciosos, así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos pueden especificar: !• Empleo de técnicas criptográficas. • Registro de ficheros con “logs” de actividad. • Asignación de determinadas funcionalidades a determinados

módulos. • Restricciones de comunicación entre determinados módulos. •Comprobaciones de integridad de información crítica.


FiabilidadEspecificación de los factores de fiabilidad necesaria del sistema. !Esto se expresa generalmente como el tiempo entre los incidentes permisibles, o el total de incidentes permisible. !Fijan la tasa de fallas para que el sistema sea aceptable.

DisponibilidadEspecificación de los factores de disponibilidad final exigidos al sistema. !Normalmente expresados en % de tiempo en los que el software tiene que mostrar disponibilidad. !O bien, factores humanos de consistencia. Ejemplo: Se debe ver facilmente el texto a una distancia de 30 cm del monitor

Ejemplo: Si se produce algún fallo al usar un servicio externo (autorización de pago) solucionarlo localmente.


Portabilidad

MantenibilidadIdentificación del tipo de mantenimiento necesario del sistema. !Especif icación de quien debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un desarrollador. Especificación de cuando debe realizarse las tareas de mantenimiento. Por ejemplo, generación de estadísticas de acceso semanales y mensuales.

Especificación de atributos que debe presentar el software para facilitar su traslado a otras plataformas o entornos. Pueden incluirse: !• Porcentaje de componentes dependientes del servidor. • Porcentaje de código dependiente del servidor. • Uso de un determinado lenguaje por su portabilidad. • Uso de un determinado compilador o plataforma de desarrollo. • Uso de un determinado sistema operativo.

OtrosCualquier otro requisito que no encaje en ninguna de las secciones anteriores. !Por ejemplo: Requisitos culturales y políticos Requisitos Legales


RF, RNF, MAPA DE

PROCESOS

TAREA: “Tienda el Regalo”


GESTION DE VENTAS

GESTIÓN DE INVENTARIOS

CONSULTA/CONSOLIDACIÓN

VENTAS vs INVENTARIO

TIENDA EL REGALO

Ejercicio: “Tienda el Regalo”

GESTIÓN DE PERFILES/ACCESO

A USUARIOS

CONSEJERO !

CONSEJO

EMPLEADOS ADMINISTRADOR


CLIENTE

Cliente llega a caja y realiza pago de mercancia(s)

Ejercicio: “Tienda el Regalo”

Empleado registra calculo de importe de compra y se registra la

venta de mercancia(s) con el código de producto correcto

EMPLEADO

Empleado emite ticket/factura y se entrega al

cliente documento

El Cliente recibe ticket/factira y la mercancía(s) compradas

FIN

INICIO

Proceso: Ventas

Se da de baja producto en almacén conforme al código que

le corresponde


MODELADO DE CASOS DE USO


ingenieria de requisitos - ingeniería de software

Education