Clase#3 - A&D 2008 - Ingeniería de Requerimientos

Ingeniería de RequerimientosIngeniería de Requerimientos

Análisis & DiseñoMSc. Álvaro Mena Monge

Informática Empresarial – 10 años

AgendaAgenda

La Ingeniería de Requerimientos

Propósitos de la Ingeniería de Requerimientos

Conceptos de requerimientos y stakeholders

Pirámide de los requerimientos

Clasificación de los requerimientos

Características de un buen requerimiento

Especificaciones suplementarias

Artefactos de la Ingeniería de Requerimientos

Trazabilidad (rastreabilidad)


Ingeniería de Ingeniería de requerimientosrequerimientos


Problemática Ing. requerimientosProblemática Ing. requerimientos


Investigación de Standish Group en 352 compañías que reportaban más de 8000 proyectos de software 31% proyectos son cancelados antes de ser completados 53% proyectos cuestan 189% valor estimado Compañías grandes, 9% proyectos cumplen con tiempo y presupuesto Compañías pequeñas, 16% cumplen con el tiempo y presupuesto

establecidos



Causas fallasFactores % respuestasFalta de información del usuario 12.8%

Requerimientos y especificaciones incompletas

12.3%

Requerimientos y especificaciones cambiantes

11.8%

Requerimientos pobres gran problema Entonces

Cómo estimar el costo? Cómo crear un plan de proyecto, asignar recursos, etc.?



Propósitos Ing. requerimientosPropósitos Ing. requerimientos

Establecer y mantener un acuerdo con los clientes y otros afectados acerca de lo que el sistema debería hacer.

Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema.

Definir los límites (delimitar) del sistema. Definir una interfaz de usuario para aquellas

funcionalidades del sistema que lo ameriten


Propósitos Ing. requerimientosPropósitos Ing. requerimientos

Estimación de costos y tiempos del sistema Base para diseñar el sistema, pruebas,

documentación y manuales de documentación y entrenamiento

Proveer fundamentos para la planeación de iteraciones


¿Qué es un requerimiento?¿Qué es un requerimiento?

“Condición o capacidad que el sistema o un componente debe satisfacer”. Puede ser:– Capacidad requerida por un cliente o usuario para resolver

un problema o alcanzar un objetivo– Capacidad que debe poseer un sistema para satisfacer un

contrato, estándar, especificación u otro documento formal

– Una restricción impuesta por un stakeholder Es requerimiento cuando esté escrito


El StakeholderEl Stakeholder

“Persona que es afectada por el sistema que está siendo desarrollado ” Tipos:– Usuarios: usan el sistema– Clientes: solicitan y aprueban el sistema

Se consideran stakeholders– Persona que participa en el desarrollo ( analista de

negocios, diseñadores, programadores, probadores, gestores de proyectos, diseñador gráfico)


El StakeholderEl Stakeholder

Se consideran stakeholders– Persona que brinde conocimiento del sistema ( expertos

del dominio, autores de documentos fuentes para la elicitación)

– Ejecutivos– Personas involucradas en mantenimiento y soporte– Proveedores de reglas y regulaciones


Pirámide de los requerimientosPirámide de los requerimientos



Los diferentes niveles marcan el nivel de detalleRequerimiento TipoLos datos deben ser persistentes

Sistema deberá usar una base de datos relacional

Sistema debe usar la base datos Oracle 9i


Necesidad del stakeholder: describe lo que la aplicación debería hacer para mejorar o reducir el costo de un proceso de negocio, incrementar ganancias o alcanzar regulaciones y otras obligaciones.

Característica: es un servicio que el sistema provee para llenar una o más necesidades del afectado. Formulada por el analista del negocio.

Caso de uso: Descripción del comportamiento del sistema en términos de secuencias de acciones.



Requerimiento suplementario: – Dicta propiedades e impone restricciones en el proyecto o

sistema. Especifica atributos del sistema.– Estas restricciones recaen en los servicios o funciones

ofrecidas por el sistema: restricciones de tiempo, en proceso de desarrollo, estándares, etc.

Caso de prueba: una especificación de entradas de pruebas, ejecución de condiciones y resultados esperados.

Escenario: secuencia específica de acciones; ruta específica a través de un caso de uso.



DocumentosPeticiones de los stakeholdersVisiónEspecificaciones de Casos de UsoEspecificaciones SuplementariasEspecificaciones de Requerimientos de Software (SRS)GlosarioCasos de Prueba

Artefactos de la Ing. de Artefactos de la Ing. de RequerimientosRequerimientos


Documentación de las necesidades implica interpretar diferentes puntos de vista (intereses) de los afectados

Es necesario identificar los afectados.

Peticiones de los afectadosPeticiones de los afectados


Caso: Aplicación escritorio de soporte técnico Administrador de la aplicación:

“Necesito ser capaz de incrementar el número de llamadas de soporte del equipo en un 30%”

Se observa poco detalle en la necesidad

Finanzas “El presupuesto inicial para la implementación del proyecto no puede

exceder los $350 mil” Esta necesidad puede ocasionar conflictos con otras

Una necesidad no indica una solución, describe una necesidad del negocio

Peticiones de los afectadosPeticiones de los afectados


Traducir las necesidades de los afectados en un conjunto de características del sistema

“Necesitamos un aplicación web tal que los clientes puedan ingresar sus propias solicitudes de soporte técnico”

Características del softwareCaracterísticas del software


Necesidades de los Necesidades de los afectadosafectados

ID Necesidad StakeholderSTRQ1 “Necesito notificar al jefe de soporte

cuando ‘una solicitud de soporte’ es iniciada”

Jefe de soporte

STRQ2 “Necesito asignar solicitudes de soporte a un ingeniero de soporte específico”

Jefe de soporte

STRQ3 “Necesito mantener informado al cliente del progreso de una solicitud de soporte”

Cliente (usuario)

Informática Empresarial – 10 añosCaracterísticas del sistemaCaracterísticas del sistema

ID Característica Descripción Mapea con

FEA1 El sistema funcionará orientado al trabajo en flujo

La solicitud de soporte pasará por una serie de etapas y asignaciones

N1, N2, N3

FEA2 Capacidad de notificación por

e-mail

Un sistema de notificación de correo centralizado será utilizado por el flujo de trabajo

N1, N2, N3


Carente de ambigüedad– Interpretarse de una sóla forma× Req1 El sistema no aceptará claves de acceso más grandes de 15

caracteres.– El sistema no deberá aceptar claves más largas de 15 caracteres. Si el

usuario ingresa más de 15 caracteres al digitar su clave, un mensaje de error le indicará al usuario que debe corregirlo

Testeable– Debe poder verificarse si un requerimiento es implementado

correctamente. – Algunas palabras NO se deben emplear– Adjetivos: robusto, seguro, preciso, efectivo, eficiente, expandible,

flexible, mantenible, confiable, adecuado, amigable con el usuario

Características de un buen Características de un buen requerimientorequerimiento


Testeable– Adverbos: rápidamente, de forma segura, a tiempo– Acrónimos: etc., y, o× REQ1 Las búsquedas deberán permitirle al usuario encontrar una

reservación basado en apellidos, fecha, etc.– Los criterios de búsqueda deberían ser listados– Evitar las voces pasivas× El código del aeropuerto deberá ser ingresado por el usuario– El usuario deberá ingresar el código del aeropuerto– Pronombres indefinidos: pocos, muchos, varios, la mayoría, alguien,

cualquiera× El sistema deberá soportar el uso concurrente por varios usuarios.



Claro (Preciso, Simple, Conciso)– No contener información innecesaria

Correcto– Si el req. contiene hechos, los mismos deben ser ciertos– Los precios de renta de los vehículos deberán mostrar los

impuestos aplicables (13 %)

Entendible– Ser gramaticalmente correcto y con un estilo consistente.

Usar convenciones y estándares.



Realista– Debe ser posible su implementación con las restricciones

de tiempo, dinero y recursos disponibles– REQ1 El sistema deberá tener una interface de lenguaje

natural que entienda comandos en Español

Independiente– No debe requerir otro requerimiento para poder

entenderlo

Atómico– Ser traceable de forma simple– No incluir varios requerimientos como uno sólo



Libre de Implementación– No contener información de implementación o de diseño× REQ1 La información de contenido será almacenada en un

archivo de texto

Consistente– No deben existir conflictos entre requerimientos– REQ1 Las fechas deberán desplegarse en el formato mm-

dd-aaaa– REQ2 Las fechas deberán desplegarse en el formato dd-

mm-aaaa



Completos– Debe especificar todas las condiciones en que puede

ocurrir× REQ1 El país destino no necesitará ser desplegado para

vuelos dentro de U.S.A.× REQ2 En los vuelos sobre mar, el sistema deberá desplegar

un país destino



Requerimientos suplementariosRequerimientos suplementarios

Llamados requerimientos arquitectónicos Conocidos como requerimientos no

funcionales Dictan propiedades e impone restricciones en el

proyecto o sistema. Especifica atributos del sistema. Recolectados en el documento Especificaciones

Suplementarias Su elicitación es un tanto retadora


Requerimientos SuplementariosRequerimientos Suplementarios

Usar el enfoque sugerido por Peter Eeles– Crear lista de categorías de los Req. Suplementarios– Crear pregunta para cada categoría– Explicar al cliente el impacto y costo de cada decisión– Capturar la respuesta del cliente a cada pregunta– Asignar prioridad y peso a cada requerimiento


Clasificación Req. SuplementariosClasificación Req. Suplementarios

FURPS+– Functionality, Usability, Reliability, Performance &

Supportability– Restricciones (+): Design, Implementation, Interface &

Physical

Las categorías pueden ser omitidas si no fueran aplicables



Categoría Subcategoría Descripción

Funcionalidad Contiene reqs. funcionales no capturados en los casos de uso (impresión, ayuda y reportes)

La ayuda en línea deberá estar disponible desde el menú en cada página

Usabilidad Accesibilidad Facilidad de acceso y uso

La renta de un vehículo deberá estar disponible con un solo clic desde la página principal

Estética Estética de la UI & el “look and feel”

Los campos de entrada múltiples deberán estar alineados verticalmente




Usabilidad Consistencia de UI Consistencia de la UI

La interfaz de usuario deberá ser consistente con el estándar IBM CUA

Ergonomía Aspectos ergonómicos de la UI. Evitar clics innecesarios o movimientos del mouse.

Facilidad de uso Facilidad de uso y de aprendizaje

El proveedor de servicios deberá ser capaz de aprender a usar el sistema en una hora




Fiabilidad(Reliability)

Disponibilidad Porcentaje de tiempo de disponibilidad del sistema

El sistema deberá estar disponible un 99.93% del tiempo

Robustez Capacidad del sistema para resistir perturbaciones externas (entradas inválidas o falta de recursos)

Para cada entrada inválida, el sistema desplegará un mensaje de error explicando el formato de entrada esperado

Precisión Precisión con que el sistema calcula valores

Las cantidades decimales deberán ser calculadas y almacenadas con precisión de dos decimales




fiabilidad(Reliability)

Recuperación Elegancia de recuperación del sistema ante una falla

Tolerancia a fallas

Sensibilidad del sistema a que alguna de sus partes falle

Seguro Cualquier amenaza a usuarios, datos, componentes del sistema o sistemas interoperantes que se deriven del uso del sistema

Seguridad Nivel de protección en torno al acceso a partes del sistemaUna clave será requerida para acceder a las funcionalidades de administrador

Correcto Cuan libre de defectos el sistema deberá quedarUna vez puesto en producción, el sistema deberá tener cero defectos críticos y no más de 20 defectos menores.




Performance Rendimiento Promedio con que el sistema ejecuta sus tareas

Tiempo de respuesta

Qué tan rápido responderá el sistema a los eventosEl promedio de tiempo de respuesta deberá ser menor que dos segundos

Tiempo de Recuperación

Qué tan rápido se recupera el sistema de una falla.En caso de falla del sistema, un sistema redundante iniciará operaciones en 30 segundosEl tiempo promedio de reparación deberá ser menor que una hora




Performance Tiempo arranque-apagado

El sistema deberá estar disponible en un minuto desde su arranque

Capacidad Número de usuarios que el sistema deberá soportarEl sistema deberá soportar 5,000 usuarios concurrentes

Utilización de recursos

Uso de memoria, espacio en disco, almacenaje de b.d.




Soportabilidad Testeabilidad Cuan fácil realizarle pruebas al sistema

Adaptabilidad Que tan fácil el sistema se adapta a nuevos ambientes

Mantenibilidad Qué tan fácil será localizar errores y repararlos

Compatibilidad Grado de compatibilidad del sistema con versiones previas del sistemaDespués que el sistema entre en producción, las versiones subsecuentes deberán ser compatibles. Todas las transacciones ingresadas en versiones previas deberán estar disponibles en la nueva versión




Soportabilidad Configurabilidad Aspectos de configuración del sistema una vez instalado

Actualizable Qué tan fácil será expandir el sistema con nuevas características

Instalable Facilidad de instalaciónLa instalación de una nueva versión del sistema no requerirá instalación alguna en las estaciones de trabajo

Escalabilidad Que tan fácil el sistema escalará volúmenes de datos y de usuarios




Soportabilidad Portabilidad Facilidad para moverlo a otra plataforma de software o de hardwareUn cambio del motor de base de datos en el futuro no deberá requerir reescritura de lógica de aplicación

Interoperabilidad Reutilización de partes del sistema en otro sistema

Reusabilidad Cooperación con otros sistemas




Soportabilidad Cumplimiento Cómo el sistema acatará estándares

Reemplazable Facilidad para cambiar componentes

Cambiable Facilidad para cambiar funcionalidades

Analizable Facilidad para analizar el sistema

Localización Lenguajes que soportará el sistema

Auditable Facilidad para auditar la operación del sistema



Categoría Descripción

Restricciones de diseño Relacionados con la arquitectura y el diseño del sistema

Reqs. de implementación Lenguajes de programación, sistemas operativos, de b.d., limitaciones de recursos (memoria, espacio de disco), convenciones de desarrollo

Reqs. físicos Requerimientos de hardware para desplegar el sistema

Reqs. de documentación Documentación impresa y digital, documentación en línea

Reqs. legales y licenciamiento

Requerimientos de interfaces

Interfaces de hardware, software y comunicaciones



Mecanismos de la arquitectura Representan soluciones concretas comunes a

problemas frecuentes



Lista de chequeo para levantarlos


Habilidad para rastrear un elemento del proyecto con otros elementos del proyecto, en especial requerimientos

Propósitos:Entender la fuente de los req.Administrar el ámbito del proyectoAdministrar los cambios de req.Estimar el impacto de cambio de req. en el proyectoVerificar que todos los req. son implementadosEstimar el impacto de una falla de una prueba en los

requerimientos

TrazabilidadTrazabilidad


Para un sistema de Máquina de Reciclaje, el documento Visión especifica la sgte. caracterísitica:FEAT10:La máquina de reciclaje permitirá la adición de nuevos tipos de botellas.

Esta característica es rastreada con un caso de uso “Agregar Nuevo Tipo de Botella”:

Este C.U. permite al Operador enseñar a la máquina de reciclaje a reconocer nuevos tipos de botellas.

Así, ayuda a verificar que todas las características son incluidas en las especificaciones de casos de uso y suplementarias.



BibliografíaBibliografía

Zielczynski, Peter. Requirements management using IBM Rational RequisitePro. USA. IBM Press, 20008.

IBM(R) Rational Unified Process

Clase#3 - A&D 2008 - Ingeniería de Requerimientos

Documents

Transcript of Clase#3 - A&D 2008 - Ingeniería de Requerimientos