-
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
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
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
Desarrollo de Requisitos
Anlisis
-
28
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
RecoleccinRecoleccinRecoleccinRecoleccin
AnlisisAnlisisAnlisisAnlisis
EspecificacinEspecificacinEspecificacinEspecificacin
ValidacinValidacinValidacinValidacinWiegers, Karl E., Software
Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
Anlisis de Requisitos
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
Dudas o comentarios ?
-
30
Desarrollo de Requisitos
Especificacin
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
RecoleccinRecoleccinRecoleccinRecoleccin
AnlisisAnlisisAnlisisAnlisis
EspecificacinEspecificacinEspecificacinEspecificacin
ValidacinValidacinValidacinValidacinWiegers, Karl E., Software
Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
-
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.
Especificacin de Atributos de Calidad (Requisitos No
Funcionales)
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
Especificacin de Atributos de Calidad (Requisitos No
Funcionales)
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.
Especificacin de Atributos de Calidad (Requisitos No
Funcionales)
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
Desarrollo de Requisitos
Validacin
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
RecoleccinRecoleccinRecoleccinRecoleccin
AnlisisAnlisisAnlisisAnlisis
EspecificacinEspecificacinEspecificacinEspecificacin
ValidacinValidacinValidacinValidacinWiegers, Karl E., Software
Requirements, 2nd edition, Microsoft Press, 2003. Pg.13
-
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.
Anlisis de Requisitos
Especificacin de Requisitos
Inspeccin de software para validacin de requisitos
-
44
Dudas o comentarios ?