2. ir fase de requisitos analisis y diseño oo

1Ingeniera de Requisitos:Desarrollo de Requisitos

wFactura

Febrero 2010

Objetivos Conocer las distintas fuentes de requisitos.

Explicar algunas tcnicas de recoleccin de requisitos.

Entender como se pueden aplicar estas tcnicas para la obtencinde requisitos tanto de alto nivel (requisitos de negocio, features) como de bajo nivel (requisitos de usuario, requisitos funcionales, etc).

Entender los casos de uso como tcnica para recolectar requisitosde usuario.

Conocer la importancia de priorizar los requisitos antes de desarrollarlos.

Aplicar tcnicas de Aseguramiento de la Calidad en los requisitos de software.

2Contenido

Introduccin

Fuentes de requisitos de software.

Planeacin y recomendaciones para la recoleccin de requisitos.

Tcnicas de recoleccin de requisitos.

Anlisis de Requisitos

Especificacin de Requisitos

Validacin y/o Verificacin de Requisitos

Fase de Requisitosen Moprosoft

3Ingeniera de Requisitos: Fundamentos

Introduccin a la Ingeniera de Requisitos

Definicin de Requisito de SW (1)

Una condicin que debe ser cumplida para que el cliente

encuentre ACEPTABLE el producto o servicio proporcionado.

Una condicin o capacidad necesitada por un usuario para

solucionar un problema o lograr un objetivo.

IEEE Standard Glossary of Software Engineering Terminology (1990)

Constituyen la definicin del sistema que se va a construir o mejorar

4Definicin de Requisito de SW (2)

La siguiente definicin reconoce la diversidad de tipos de

requisitos.

Los requisitos son una especificacin de lo que debe estar

implementado. Son descripciones de cmo el sistema debe

comportarse, o una propiedad o atributo del sistema. Puede ser una

restriccin en el proceso de desarrollo del sistema.

Karl Wiegers piensa que:

Un requisito es una propiedad que un producto debe tener para

proveer valor a un stakeholder.

Lo que los Requisitos NO SON! (1)

Las especificaciones de Requisitos no incluyen: Detalles de diseo o implementacin

Informacin de planeacin de proyecto, o informacin de pruebas.

Una solicitud informal de alguien en una reunin, un pasillo o un elevador o una llamada telefnica

Solicitudes de clientes por medio de encuestas, correos electrnicos o buzones de sugerencias

Observaciones o comentarios durante reuniones de ventas o de publicidad

5Lo que los Requisitos NO SON! (2)

Para que sea un requisito: Debe ser solicitado formalmente

Debe ser documentado

Debe ser analizado formalmente para verificar el impacto en el proyecto

Debe ser aprobado

Problemas de Requisitos(1)

La mayor consecuencia de los problemas de requisitos es el RETRABAJO rehacer algo que se pensaba que estaba listo.

El retrabajo puede consumir de 30 a 50% del costo de desarrollo total.

Boehm, B. and Papaccio, P. Understanding and Controlling

Software Costs, IEEE Transactions on Software

Engineering, 1998, vol. 14 no. 10, pp. 1462-1476.

Todo proyecto tiene requisitos !

6Problemas de Requisitos(2)

Algunos de los riesgos de requisitos ms comunes:

Participacin insuficiente del usuario

Requisitos que crecen sutlmente

Requisitos ambiguos

Requisitos Gold plating

Especificacin mnima

Pasar por alto clases de usuarios

Planeacin incorrecta

Beneficios de un procesode IR de buena calidad

Las organizaciones que implementan un buen proceso de IR pueden cosechar mltiples beneficios.

Los posibles beneficios que se podran disfrutar en cuanto ahorro de tiempo y dinero: Menos defectos en los requisitos Reducir el retrabajo Disminucin de propiedades innecesarias Rpido desarrollo Disminucin de la falta de comunicacin Menos caos Estimaciones ms aproximadas Satisfaccin del cliente y del equipo

7Caractersticas deexcelentes requisitos

La mejor manera de checar si la sentencia de unrequisito tiene estas caractersticas es poner a variosstakeholders a revisar cuidadosamente el SRS(documento de especificacin de requisitos). Completo Correcto Factible Necesario Priorizado No ambiguo Verificable Rastreable

Niveles de Requisitos

Wiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.9

8Proceso de Desarrollo de Requerimientos de SW

Ingeniera de Requisitos

Ingeniera de RequisitosIngeniera de RequisitosIngeniera de RequisitosIngeniera de Requisitos

Desarrollo deDesarrollo deDesarrollo deDesarrollo deRequisitosRequisitosRequisitosRequisitos

Administracin de Administracin de Administracin de Administracin de RequisitosRequisitosRequisitosRequisitos

ElicitacinElicitacinElicitacinElicitacin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

9Proceso de Desarrollo de Requisitos

ElicitacinElicitacinElicitacinElicitacin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacin

Deberas utilizar un desarrollo iterativo para los proyectos que

quieres que salgan bien.Martin Fowler

Desarrollo de Requisitos

Descubrimiento y Recoleccin

10





RecoleccinRecoleccinRecoleccinRecoleccin AnlisisAnlisisAnlisisAnlisis EspecificacinEspecificacinEspecificacinEspecificacin ValidacinValidacinValidacinValidacinWiegers, Karl E., Software Requirements, 2nd edition, Microsoft Press, 2003. Pg.13

Fuentes de Requisitos Entrevistas y discusiones con usuarios potenciales

Documentos que describen los productos actuales

SRSs

Reportes de problemas y solicitudes de mejoras para un sistema actual (mesa de servicio)

Encuestas de mercado y cuestionarios de usuarios

Anlisis de escenarios de tareas de usuarios

Modelo de negocio

11

Stakeholders

Los stakeholders son los individuos, grupos, uorganizaciones quines estn activamenteinvolucrados en un proyecto, son afectados por suresultado, o son capaces de influenciar en l.

Por qu son importanteslos requisitos?

Un proceso efectivo de IR se enfoca en la interseccin deintereses de todos los stakeholders.

Analistas

Testers

Legal Staff

Clientes $$Usuarios

DesarrolladoresProject Managers

12

Stakeholders (clases de usuarios) De los stakeholders hay un subconjunto que representa a

los usuarios finales del sistema. Es importante identificar todas las clases distintas de

usuarios. Pues esta es una fuente vital de requisitos, puescada clase tiene necesidades distintas para usarlo. Porejemplo: La frecuencia con la que ellos usan el producto Su experiencia en el dominio de la aplicacin y su expertise en sistemas

de cmputo Las caractersticas que utilizan Las tareas que ejecutan para soportar sus procesos de negocio Sus privilegios de acceso o niveles de seguridad

Clases de usuarios

Una jerarqua de clientes y usuarios(stakeholders)

WiegersWiegers, Karl E., , Karl E., Software RequirementsSoftware Requirements, 2nd edition, Microsoft Press, 2003, 2nd edition, Microsoft Press, 2003

13

Buscando a los usuariosrepresentativos

Todo tipo de proyecto necesita usuarios representativos apropiadospara proveer la voz del cliente.

Cada clase de usuario necesita ser representado.

Un Product Champion es un miembro clave de la comunidad deusuarios a la cual sirve como la interfase principal entre miembros deuna clase de usuarios y el analista de requerimientos del proyecto.

El enfoque de Product Champion provee una forma efectiva deestructurar la relacin cliente-desarrollador.

Ejemplo

Listar al menos cinco clases distintas de stakeholders para el sistema de ATM.

Nombre Representa Rol Champion

Director General Ejecutivo de la compaa Sponsor del proyecto Juan Prez

Equipo de Desarrollo Personas del rea de Sistemas

Sern quienes desarrollarn el software de ATM

Luis Garca

Gerente de Sucursal Persona a cargo de una sucursal del banco

Facilitador para la instalacin del ATM en su sucursal

Pedro Torres

Administrador del ATM Empleado de sucursal delrea de soporte tcnico

Dar mantenimiento al ATM

Hugo Ruiz

Cliente del Banco Persona que tiene una cuenta en el banco

Usuario del ATM. Podr realizar operaciones bancarias con l.

14

Ejercicio

Listar al menos cinco clases distintas de stakeholders para uno de los sistemas que estn desarrollando. Al menos uno debe ser un usuario final (deseable poner dos).

Nombre Representa Rol Champion

Diagrama de Contexto

La descripcin del alcance establece el lmite y conexin entre el sistema que se est desarrollando y todo lo dems en el universo.

Identifica los terminadores fuera del sistema que interfacean con l de alguna manera, tambin como datos, flujos de control entre los terminadores y el sistema.

15

Ejemplo de Diagrama de Contexto (1)

UsuariosUsuarios

SistemasSistemasLegadosLegados

Otras AplicacionesOtras Aplicaciones

El Nuevo SistemaEl Nuevo Sistema

ComunicacionesComunicacionesSoporteSoporte

ReportesReportes

Definicin de Elicitation(Del Merrian Webster On Line Dictionary)

1 : Sacar a relucir (algo latente o potencial)

2 : Provocar o prolongar (como informacin o una respuesta)

16

Recoleccin

El corazn de la ingeniera de requisitos es la recoleccin, el proceso de identificar las necesidades y restricciones de los distintos stakeholders para un sistema de software.

La recoleccin se enfoca en descubrir los requisitos de usuario.

Recomendaciones en la Recoleccin

Usar el vocabulario del dominio de la aplicacin en vezde usar la jerga computacional.

Los clientes deberan entender que una discusin acercade cierta posible funcionalidad no es un compromisopara incluirla en el producto.

Plantear y clarificar cualquier suposicin que el clientepueda tener.

Registar sabiamente toda la informacin obtenida.

17

Escoger entre muchastcnicas de recoleccin

Entrevistas

Cuestionarios

Talleres de Recoleccin de Requisitos

Lluvia de Ideas

Observar como trabajan los usuarios

Prototipos

Casos de uso (Escenarios)

Entrevistas - Preguntas libres

Son preguntas alto nivel, abstractas que pueden preguntarse al inicio de un proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales

Preguntas libres:

Son siempre apropiadas

Ayudan a entender la perspectiva de los afectados

No estn influenciadas por el conocimiento de la solucin

18

Tipos de preguntas libresUsuario

Quin es el cliente? Quin es el usuario? Son sus necesidades diferentes? Cules son sus backgrounds,

capacidades, ambientes? Cul es su funcin? Qu necesita para realizar sus

actividades?

ProductoProductoProductoProducto Qu problemas del negocio podra

resolver o crear este producto? En qu ambiente se usar el

producto? Cules son sus expectativas para el

fcil uso, lo confiable, y el rendimiento del mismo?

ProcesoProcesoProcesoProceso Cul es la razn por la que se

quiere resolver este problema? Cul es el valor de una solucin

exitosa? Cmo usted resuelve el

problema ahora? Cmo piensa que debera ser?

MetaMetaMetaMeta----PreguntasPreguntasPreguntasPreguntas Estoy preguntando demasiado? Son mis preguntas relevantes? Es usted la persona correcta para

resolver estas preguntas? Son sus respuestas requerimientos

(necesidades)? Puedo hacerle ms preguntas

despus? Hay algo ms que yo debera

preguntarle?

Tipos de preguntas comodn Es importante que el analista ponga atencin a lo que un usuario responde en una

entrevista y para ahondar en las respuestas puede apoyarse de preguntas tales como:

Quin?

Cundo?

Dnde?

Por qu?

Cmo? (sta es vital)

La manera en que lo hace es la mejor manera?

Ejemplo: Si el usuario comenta yo ejecut la nmina, se podra indagar mucho ms que slo eso con las preguntas:

Quin ms lo hace?

Cundo o con qu frecuencia lo hace?

Dnde lo hace?

Por qu lo hace?

Cmo lo hace?

Se podra mejorar?

19

Lluvia de Ideas

Reglas para la Lluvia de IdeasReglas para la Lluvia de IdeasReglas para la Lluvia de IdeasReglas para la Lluvia de Ideas Prepare el ambiente de trabajo Diga el objetivo claramente Genere tantas ideas como sea

posible Deje volar la imaginacin No critique ni discuta Mezcle y combine ideas

Ejercicio

Features Versin 1 Versin 2

Realizar una lluvia de ideas (brainstorming) para recolectar lasnecesidades para el sistema elegido que estn desarrollandoactualmente.

20

Workshops de Recoleccin Workshops de grupos colaborativos son una tcnica

altamente efectiva para reunir a usuarios y desarrolladores

Tips de recomendaciones para conducir sesiones de recoleccin efectivas son: Establecer reglas base (iniciar y terminar a tiempo, una

conversacin a la vez, enfocarse en issues no en personas)

No salirse del alcance (usar documento de visin y alcance)

Apuntar ideas o elementos para una consideracin posterior (llevar una lista de issues que son importantes y se pueden discutir despus)

Discusin Timebox (poner lmite de tiempo a cada punto)

Mantener un equipo pequeo e incluir a los participantes correctos

Mantener involucrados a todos (fomentar la participacin de todos los integrantes)

Reduccin de riesgos a travs de prototipos

IKIWISI Ill Know It When I See It

Propsitos:

Clarificar y completar los requerimientos

Explorar alternativas de diseo

Prototipo Horizontal

Forma Final, funciones y tecnologa

Bote lo menos que pueda

Prototipo Vertical (pruebas de concepto)

Validan la factibilidad tecnolgica; exponen los riesgos potenciales

Desechables

Eliminan riesgos de requisitos mal entendidos

Bote todo exceptuando el conocimiento ganado

Evolutivo

Este prototipo se llega a convertir en el producto final

21

Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber Excelente! El Faran estar complacido de saber que han completado la construccin bajo el que han completado la construccin bajo el que han completado la construccin bajo el que han completado la construccin bajo el presupuesto y antes de tiempopresupuesto y antes de tiempopresupuesto y antes de tiempopresupuesto y antes de tiempo

Los prototipos son excelentes pero

Puntos a considerar de los prototipos

No incluir validaciones de entrada de datos exhaustivas, manejo de errores, o documentacin de cdigo en prototipos desechables.

No hacer prototipos para requerimientos que ya estn entendidos, a menos que se quieran para explorar alternativas de diseo.

Es riesgoso usar datos dummy en los prototipos pues los usuarios pueden distraerse al ver datos no reales dentro de los mismos.

Nunca esperar que un prototipo reemplace completamente a un SRS !!!

22

Aplicacin de tcnicas de recoleccin

EXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOREXPERIENCIA DEL DESARROLLADOR

EXPE

RIENC

IA DE

LEX

PERIE

NCIA

DEL

EXPE

RIENC

IA DE

LEX

PERIE

NCIA

DEL

CLIEN

TE/ U

SUAR

IOCL

IENTE

/ USU

ARIO

CLIEN

TE/ U

SUAR

IOCL

IENTE

/ USU

ARIO

BAJOBAJOBAJOBAJO ALTOALTOALTOALTOBAJOBAJOBAJOBAJO

ALTOALTOALTOALTO

ProblemaProblemaProblemaProblema EnredadoEnredadoEnredadoEnredadoLluviaLluviaLluviaLluvia de Ideasde Ideasde Ideasde Ideas

ActuacinActuacinActuacinActuacin de Rolesde Rolesde Rolesde RolesBosquejosBosquejosBosquejosBosquejos

EntrevistasEntrevistasEntrevistasEntrevistasTalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos

AlcanzarlosAlcanzarlosAlcanzarlosAlcanzarlosEntrevistasEntrevistasEntrevistasEntrevistas

InvestigacinInvestigacinInvestigacinInvestigacinBosquejosBosquejosBosquejosBosquejos

TalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos

MadurosMadurosMadurosMadurosAnlisisAnlisisAnlisisAnlisis OrientadoOrientadoOrientadoOrientado a a a a ObjetosObjetosObjetosObjetos

EspecificacinEspecificacinEspecificacinEspecificacin de de de de RequerimientosRequerimientosRequerimientosRequerimientosPrototiposPrototiposPrototiposPrototipos HorizontalesHorizontalesHorizontalesHorizontales

CasosCasosCasosCasos de de de de usousousousoReingenieraReingenieraReingenieraReingeniera de de de de ProcesosProcesosProcesosProcesos del del del del NegocioNegocioNegocioNegocio

TalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientosVendiendoVendiendoVendiendoVendiendo////EnseandoEnseandoEnseandoEnseando

PrototipoPrototipoPrototipoPrototipo EvolutivoEvolutivoEvolutivoEvolutivoEspecificacinEspecificacinEspecificacinEspecificacin de de de de RequerimientosRequerimientosRequerimientosRequerimientos

BosquejosBosquejosBosquejosBosquejosCasosCasosCasosCasos de de de de usousousouso

ReingenieraReingenieraReingenieraReingeniera de de de de ProcesosProcesosProcesosProcesos del del del del NegocioNegocioNegocioNegocioTalleresTalleresTalleresTalleres de de de de RequerimientosRequerimientosRequerimientosRequerimientos

Algunas precaucionesacerca de la recoleccin

Usar Product Champions para validar la entrada de varios usuarios.

El documento de Visin y Alcance puede cambiar despus del proceso de recoleccin.

No incluir informacin acerca de la solucin dentro de los requisitos (no especificar nada que tenga que ver con el diseo ni construccin de la solucin).

23

Dudas o comentarios ?

Entendiendo los requisitos

del Usuario:

Casos de Uso

24

Casos de Uso

Por qu usar un Modelo de Casos de Uso para entender las necesidades de los afectados? Para llegar a un acuerdo con el usuario de lo que el sistema debe hacer

Para identificar quien interactuar con el sistema

Para identificar las interfases que el sistema debe tener

Para ayudar a verificar que no faltan requerimientos

Para verificar que los desarrolladores entienden los requerimientos

Actores y Casos de UsoDefinen los Lmites y las Funciones

Receptor de lallamada

Persona queLlama

AdministradorDe Facturacin

Llamada Internacional

Facturar al cliente

Llamada Local

Cliente

Un sistema telefnico simpleUn sistema telefnico simpleUn sistema telefnico simpleUn sistema telefnico simple

Un modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo haceUn modelo de lo que el sistema hace y para quien lo hace

25

Como Encontrar Actores

Pregntese lo siguiente: Qu grupos de usuarios ayudan al sistema a realizar sus

tareas?

Qu grupos de usuarios se necesitan para ejecutar lasopciones mas obvias del sistema?

Qu grupos de usuarios se requieren para desarrollarlas funciones secundarias tales como mantenimiento yadministracin?

Interactuar el sistema con otro sistema o hardwareexterno?

Como encontrar casos de uso

Para cada actor pregntese lo siguiente: Cules son las tareas primarias que el actor quiere que el

sistema desarrolle? Crear, almacenar, cambiar, remover o leer datos en

el sistema? Tendr el actor que informar al sistema de cambios

sbitos externos? Tendr el actor que estar informado de ciertas

ocurrencias en el sistema? Tendr el actor que desarrollar la inicializacin o

terminacin del sistema? Ponga un nombre a los casos de uso que ha encontrado

26

Modelo del Diagrama de Casos de UsoUna solucin simple para una Mquina de Reciclaje

Operador

Cliente

Administrador

Imprimir Reporte Diario

Cambiar Valores de Fondos

Reciclar Objetos

Mquina de Reciclaje

Agregar Nuevo Tipo de Objeto

Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer Un modelo de lo que el sistema se supone que debe hacer (casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)(casos de uso) y los alrededores (actores)

Ejercicio Identifique Actores para el ATM

27

Ejercicio Identificar Casos de Uso para el ATM


Anlisis

28







Esta etapa dentro del proceso de Desarrollo de Requisitos se enfoca principalmente a analizarlos para: Detectar y resolver conflictos entre requisitos

Clasificar los requisitos de acuerdo al nivel

Separar los requisitos de manera modular (que llegarn a formar parte de componentes de software)

Priorizar los requisitos

Crear el modelo conceptual

29

Anlisis de Requerimientos

Priorizacin de requisitos basada en Importancia y Urgencia

Importante No Importante

Urgente Prioridad Alta No hacer estos !

No Urgente Prioridad Media Prioridad Baja


30


Especificacin






31

Documento de Especificacin de Requisitos de Software (SRS)

Para Moprosoft, este documento debe llevar:1. Introduccin2. Funcionales3. Interfaz con Usuario4. Interfaces con otro Software o Hardware5. Confiabilidad6. Eficiencia7. Mantenimiento8. Portabilidad9. Interoperatividad10. Reusabilidad11. Restricciones de Diseo y Construccin12. Legales y Reglamentarios

Algunas guas para la especificacin de requisitos funcionales

Usar siempre palabras como debe, deber, permitir, podr y NO palabras como podra, debera, tal vez.

Asignar un identificador nico a cada requisito.

Para los Requisitos No Funcionales que son Atributos de Calidad, especificar mtricas de cmo el requisito se debe cumplir y no dejar frases tales como que lo haga rpido, que lo haga bien, entre otras. Mejor cosas como que responda en menos de 30 segundos, que se inserten el 100% de los registros, etc.

JAMS SUPONER O ASUMIR ALGO!!! (Si no se est seguro de algo preguntar al usuario llamndolo por telfono, o preguntndole en persona).

Especificar todo lo ms claro posible pues hay que tomar en cuenta que los que disearn el sistema son otras personas.

Cuidar el no incluir palabras ambiguas, un sntoma sera que dos personas entendieran cosas distintas del requisito.

32

Ejercicio

Liste los problemas que encuentre en la especificacin delsiguiente requisito. Proponga una mejor redaccin de serposible (en caso que sea necesario puede descomponerloen varios requisitos).

El clculo de la nmina puede ejecutarse una vez al mes sin que nadie

tenga que activarla. Este proceso se debera ejecutar lo ms rpido posible

para que el da de la ejecucin antes de la hora de la comida todos los

empleados tengan su sueldo depositado. La cantidad a depositar para cada

empleado es simplemente la resta entre su sueldo asignado y las

deducciones. Adems, la informacin de los empleados incluyendo su sueldo,

no debera poder ser vista por el personal encargado de administrar la base

de datos que no tengan que ver con dicha informacin.

Posible Solucin

RF-1. El sistema deber ejecutar de manera automtica el clculo de lanmina el ltimo da de cada mes natural. Es imprescindible que suejecucin quede lista antes de la 1 pm. Ver RN-1 para el clculo del sueldo.

Ver RNF-1 para polticas de seguridad.

RN-1. El sueldo mensual de un empleado se calcula por medio de lasiguiente frmula:

Sueldo Total = Sueldo_Asignado Total_Deducciones

donde Total_Deducciones se obtiene

RNF-1. nicamente el personal de recursos humanos podr ver y/oactualizar la informacin personal de los empleados. Ni siquiera el personalde bases de datos lo debe poder hacer.

33

Atributos de Calidad (1) Los atributos de calidad son difciles de definir porque los usuarios se

enfocan ms en proporcionar sus requisitos funcionales (de comportamiento).

Una manera de clasificar a los atributos de calidad es con aquellas caractersticas que son evidentes en tiempo de ejecucin de las que no lo son.

Atributos importantes para los usuarios Atributos importantes para los

desarrolladores

DisponibilidadEficienciaIntegridadConfiabilidadEscalabilidadUsabilidad

Fcil de mantenerFcil de evolucionarPortabilidadReusabilidadFcil de probar

Atributos de Calidad (2)

Un usuario no podr responder a preguntas tales como: Cules son tus requisitos de disponibilidad?

Qu tan confiable debe ser el software?

Buscar otro estilo de preguntas relacionndolas con el dominio del problema. Por ejemplo. Qu tan importante es asegurar que ciertos usuarios no puedan ver

cierta informacin? Podra cualquier persona tener acceso a la informacin de los clientes?

Qu tan grave sera que el sistema no estuviera disponible (se cayera) en horas de trabajo en un da entre semana? y qu tan grave sera que se cayera un fin de semana en la madrugada?

34

Especificacin de Atributos de Calidad (Requisitos No Funcionales)

Interfase con el UsuarioIU1. Un usuario entrenado deber ser capaz de registrar una peticin

completa de un producto de un vendedor en un promedio de 4 a 6 minutos.

IU2. Un usuario quien nunca ha utilizado el sistema antes, deber ser capaz de registrar una solicitud de un pedido de manera correcta en un tiempo no mayor a 10 minutos.

Interfases ExternasIE1. El sistema deber ser capaz de comunicarse con el mdulo de RH.

IE2. El sistema interactuar con el sistema de nmina ya existente en la empresa.


Confiabilidad Confiabilidad

CC1. No ms de 5 ejecuciones experimentales de 1000 pueden ser perdidas debido a fallas en el software.

Disponibilidad

CD1. El sistema estar disponible el 99.5 % del tiempo en das de trabajo entre las 6 am y las 12 am, y al menos el 99.95 % del tiempo en das de trabajo entre 4 pm y 6 pm.

Robustez

CR1. Si el editor falla antes que el usuario guarde el archivo, el editor deber ser capaz de recuperar todos los cambios hechos en el archivo editado hasta un minuto antes de la falla, en la prxima vez que se inicie el programa.

Integridad

CI1. Slo usuarios con privilegios de acceso de auditor sern capaces de ver histricos de las transacciones de los clientes.

35


EficienciaE1. Toda pgina web deber ser cargada a lo ms en 15 segundos sobre

una conexin por modem de 50 KBps.

E2. La autorizacin de una peticin de retiro en un ATM no deber tomar ms de 10 segundos.

MantenimientoM1. Un programador deber ser capaz de modificar los reportes existentes

con 20 horas o menos de esfuerzo en desarrollo.

M2. Las llamadas a funciones no debern pasar de 2 niveles de anidamiento.

PortabilidadP1. El mdulo de facturacin deber ser capaz de ejecutarse sobre

cualquier terminal PC con sistema operativo Linux o Windows.


Restricciones de Diseo y ConstruccinRDC1. El sistema deber ser desarrollado sobre la plataforma J2EE la cual

es la infraestructura tecnolgica de la empresa.

RDC2. Todo el mdulo de inventarios deber ser construido utilizando las libreras existentes en la empresa.

Legales y ReglamentariosLR1. El sistema deber implementar las regulaciones del gobierno actual.

LR2. El costo unitario del producto ser de $50 en compras de 100 o ms unidades, y en compras de menos unidades el costo unitario ser de $70.

LR3. Por cada tres retardos que un empleado acumule a lo largo del mes actual, se le descontar un da de sueldo.

36

Trade-Offs de Atributos de Calidad

Tarea

Hacer un documento de especificacin de requisitos parael Sistema ATM. Este documento deber tener al menosun caso de uso y al menos un requisito no funcional encada punto de la norma.

NOTA: Esto debe ser hecho por la persona o personasque jugarn el rol de Analistas en el proyecto deMoprosoft.

37


Validacin






38

Validacin de Requisitos

La fase de validacin es la cuarta y ltima del rea deDesarrollo de Requisitos.

Las actividades de la validacin de requisitosintentan asegurar que: El documento de especificacin de requisitos (SRS) describe las

capacidades y caractersticas del sistema que cumplirn las necesidades de los stakeholders.

Los requisitos estn completos y son de alta calidad.

Todas las representaciones son consistentes con las dems.

Los requisitos proveen una base adecuada para proceder con el diseo y la construccin.

Los requisitos son especificados de acuerdo a los estndares establecidos.

Validaciones y Verificaciones en Moprosoft

Verificacin o

Validacin

Producto Rol Descripcin

Verificacin Especificacin de Requisitos

RE Verificar la claridad de redaccin de la Especificacin de Requisitos y su consistencia con la descripcin del producto y con el estndar de documentacin requerido en el proceso.Adicionalmente revisar que los requisitos sean completos y no ambiguos o contradictorios. Los defectos encontrados se documentan en un Reporte de Verificacin.

Validacin Especificacin de Requisitos

CL,US,RPU

Validar que la especificacin de requisitos cumple con las necesidades y expectativas acordadas. Los defectos encontrados se documentan en un Reporte de Validacin.

Verificacin Plan de Pruebas de Sistema

RE Verificar consistencia del plan de pruebas del sistema con la especificacin de requisitos y con el estndar de documentacin requerido.

Verificacin Manual de Usuario RE Verificar consistencia del manual de usuario con la especificacin de requisitos y con el estndar de documentacin requerido.

39

La calidad es gratis: Inspecciones de Software

Las inspecciones de software son la mejor tcnica que existe para remover defectos antes de llegar a la fase de pruebas. (Inventadas por Michael Fagan a mediados de los 70s).

Para maximizar la calidad del producto se deben realizar ms inspecciones.

Las inspecciones son costosas: consumen tiempo y recursos.

Sin embargo Por cada hora invertida en una inspeccin, se ahorra

alrededor de 10 horas de retrabajo en el testing. Por cada dlar invertido en inspecciones, se ahorran de 3 a

10 dlares en la fase de pruebas.

Inspeccin de Software: Roles (1) Autor

Creador del producto a inspeccionar.

Rol pasivo y no puede llevar otro rol de la inspeccin.

Debe dejar su ego afuera de la inspeccin y tambin ver defectos que otros no ven.

Moderador Lder de la inspeccin.

Planea y coordina las actividades de la inspeccin con el autor.

Distribuye el material a ser inspeccionado a los inspectores das antes de la reunin.

Dirige el proceso de inspeccin y mantiene el enfoque en encontrar defectos en vez de resolver problemas.

Se asegura que el autor realice las modificaciones despus de la inspeccin.

40

Inspeccin de Software: Roles (2)

Lector Debe parafrasear un requisito del SRS a la vez.

Los otros participantes detectan defectos potenciales.

Debe nombrar con sus propias palabras cada requisito, con esto se pueden detectar ambigedades si los otros participantes lo haban entendido de otra manera.

Escritor (apuntador) Usa formatos para registrar los defectos encontrados durante la

reunin de inspeccin.

Inspeccin de Software: Roles (3)

Inspector Es quien encuentra errores, omisiones e inconsistencias en los

productos inspeccionados.

Los inspectores pueden ser:

Autores de productos de trabajo antecesores del producto inspeccionado: (usuarios, cliente, otros analistas).

Personas que trabajarn en base al producto de trabajo inspeccionado: (diseadores, arquitectos, programadores, testers, etc).

Personas que son responsables por productos de trabajo que interfasean al producto inspeccionado.

Tratar de limitar la inspeccin a 6 o menos inspectores.

41

Inspeccin de Software:Criterios de Entrada

El documento cumple el estndar de la plantilla. El documento no tiene faltas de ortografa. El documento ya no tiene errores de formato. Cualquier otro documento referenciado debe estar disponible

para los inspectores. Issues incompletos deben ser marcados como TBD (To Be

Determined). Puntos que no apliquen deben ser explcitamente

mencionados.

Inspeccin de Software:Fases de la Inspeccin (1)

1. Planificacin. Cuando el autor termina su producto de trabajo se forma un grupo de inspeccin y se designa un moderador. ste ltimo asigna roles y planifica los tiempos y recursos necesarios.

2. Overview. Si los inspectores no estn familiarizados se da una vista general del producto a inspeccionar. Es opcional.

3. Preparacin. Los inspectores se preparan individualmente para la evaluacin en la reunin estudiando los productos de trabajo y el material relacionado.

4. Junta de Inspeccin. Los inspectores se renen. El moderador lleva la reunin. Es importante que no dure ms de 2 horas.

5. Retrabajo. El autor corrige todos los defectos encontrados por los inspectores.

6. Seguimiento. El moderador checa las correcciones del autor. Si est satisfecho la inspeccin est completa.

42

Inspeccin de Software:Fases de la Inspeccin (2)

Inspeccin de Software:Criterios de Salida

Todos los defectos encontrados han sido removidos.

Cualquier cambio hecho al producto inspeccionado fue realizado correctamente.

El documento inspeccionado ha sido puesto bajo gestin de la configuracin.

El documento ha sido corregido ortogrficamente.

43

Ejercicio

Lleva a cabo un proceso de inspeccin con el SRS que les ser proporcionado y cumpliendo los tiempos siguientes: Planificacin (5 minutos)

Overview (5 minutos)

Preparacin Individual (10 minutos)

Reunin de Inspeccin (20 minutos)

Retrabajo (5 minutos)

Seguimiento (10 minutos)

Resumen

Introduccin

Fuentes de requisitos de software.

Planeacin y recomendaciones para la recoleccin de requisitos.

Tcnicas de recoleccin de requisitos.


Especificacin de Requisitos

Inspeccin de software para validacin de requisitos

44


2. ir fase de requisitos analisis y diseño oo

Documents

requisitos de software

usuario requisitos

recoleccin de requisitos

requisitos funcionales

obtencinde requisitos

especificaciones de

tcnicas de recoleccin

requisito de sw