Requerimientos

No es que no se pueda encontrar la solucin Es que no se puede ver el problema

Definicin

Requerimiento
Define una propiedad o caracterstica que nuestro sistema debe poseer para resolver el problema que dio origen a su desarrollo.

Definicin IEEE

Una condicin o capacidad requerida por un usuario para resolver un problema o alcanzar un objetivo. Una condicin o capacidad que debe ser poseda por un sistema o componente del sistema para satisfacer un contrato, estndar, especificacin, u otro documento formalmente impuesto. Una representacin documentada de una condicin o capacidad como las descritas en los incisos

Voy a construir algo!!! Algo?

Qu son los requerimientos?

Al proceso de entender ese algo se le denomina Anlisis de requerimientos Por lo general los requerimientos expresan qu se supone debe hacer una aplicacin Por lo comn no intentan expresar cmo lograr estas funciones

Entonces. Qu son?

Una lista de lo que los usuarios necesitan Una lista de lo que el Sistema debe hacer para satisfacer sus necesidades Una lista de que componentes deben ser construidos Una lista de lo que cada componente debe hacer, y como los componentes se relacionan

Sus nombres

Requerimiento (Requirement)

Es una declaracin de necesidad, algo que algn usuario o stakeholder quiere.

Funcin (Function)

Es algo que un sistema o subsistema hacen, presumiblemente porque un requerimiento la ha hecho necesaria.

Funcin del sistema (System function)

Igual que el anterior.

Requerimiento funcional (Functional requirement)

Una contradiccin, una especificacin del sistema y un requerimiento de usuario.

Sus nombres

Limitante (Constraint)

Una restriccin, delimita el rango de soluciones aceptables.

Capacidad (Capability)

En una especificacin de sistema, es una funcin que el sistema puede llevar a cabo, pero nicamente cuando es solicitada por un usuario u otro sistema.

Facilidad (Affordance)

Es un requerimiento que proporciona una opcin al usuario, si el usuario decide utilizarla.

Porqu son esenciales?

Los

requerimientos son la llave para alcanzar el xito. olvidarnos de esto a menudo pagamos el precio. !!! Desastre !!!

Al

Muchos proyectos fallan al no hacer lo que deben de hacer. Si se entregan tarde, hay un mayor costo o una mala calidad.

Por qu importan?

Son cruciales para cualquier proyecto debido a que:

1. 2.

Identifican el alcance de todo el trabajo siguiente. Identifican lo que el usuario quiere.

Sin embargo los desarrolladores tienden a omitirlos con mucha frecuencia.

Permiten disminuir el costo de lo hecho.

Detectar errores en etapas tempranas tiene un menor costo, requiere un menor esfuerzo y un menor tiempo.

Cul es su importancia en el fracaso de los proyectos?

Requerimientos incompletos No involucrar a los usuarios Recursos/calendarizacin insuficiente Expectativas irreales Falta de apoyo de la direccin Cambios en requerimientos Planeacin defectuosa No lo necesito ms tiempo 13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.4%

Fuente: Standish Group 1995 (www.standishgroup.com)

Para qu son?

Mostrar que necesitan los interesados.

Darles a los interesados la oportunidad de decir lo que ellos quieren.

Para representar los diferentes puntos de vista. Para validar el diseo. Para medir progreso. Para la aceptacin del producto de acuerdo a criterios estrictos.

Tipos de los requerimientos

Requerimientos C

Del Cliente Deseos y necesidades del cliente, expresados en un lenguaje claro para el.

Requerimientos D

Del Desarrollador, Detallados, Funcionales Requerimientos completos documentados de manera especfica y ordenada, expresados en lenguaje orientado al desarrollador.

NOTA: Esta en una clasificacin til, aunque no todos los autores la utilizan.

Clasificacin de requerimientos

Requerimientos funcionales

La funcionalidad de la aplicacin

Requerimientos no funcionales

Desempeo

Velocidad, Capacidad, Uso de memoria, Uso de disco

Confiabilidad y disponibilidad Manejo de errores Requerimientos de interfaz Reestricciones

Exactitud Herramientas y lenguajes

Requerimientos inversos

Especificaciones de requerimientos durante las etapas del proyecto.

Los requerimientos del usuario identifican lo que el usuario y los stakeholders quieren, los usuarios normalmente quieren resultados especficos, por lo cual, ellos tienden a escribir sobre capacidades o facilidades que son posteriormente implementadas como funciones del sistema. Otros stakeholders como los administradores o tcnicos tienden a escribir restricciones, aunque los usuarios pudiesen tambin indicarlas.

Fuentes de requerimientos

Stakeholders

Helpdesk o equipo de soporte Capacitadores y asesores Sugerencias de cliente y quejas Mejoras hechas por usuarios Usos involuntarios Viejos diseos y especificaciones Contratos mal escritos Estado del arte (Bibliografa del tema)

Personas / Sistemas

Ambiente de operacin Sistemas similares

Investigaciones e innovacin
Prototipos Nuevas tecnologas

Reportes de errores

Tcnicas para identificar requerimientos IEEE

Talleres estructurados Sesiones de tormentas de ideas Entrevistas Cuestionarios

Observacin de campo
Revisin de la documentacin tcnica Anlisis de mercado Ingeniera inversa Simulaciones

Prototipos

Actividades en la identificacin de requerimientos

Identificacin de los stakeholders

Identificacin de los procesos de negocios

Identificacin de los escenarios

Identificacin objetos participantes

Contexto del desarrollo de los requerimientos

STAKEHOLDERS SPONSORS FUENTES DE INFORMACION

VoBo

PROCESO SUGERIDO

FUENTES DE INFORMACION

PROCESO ACTUAL

REQUERIMIENTOS

+
LISTA DE REQUERIMIENTOS

Solicitan
STAKEHOLDERS

Solicitante
STAKEHOLDER

Estructurando los requerimientos

Porqu estructurarlos?
1.

Un proyecto de tamao medio tpicamente tiene cientos de requerimientos.

2.

stos solo pueden ser totalmente entendidos cuando son organizados lgicamente.
Una estructura buena ayuda a organizar los requerimientos permitiendo ver con mayor facilidad lo que es necesario, a donde pertenece todo, y como los requerimientos se relacionan.

3.

4.

Tambin facilita la comprobacin de errores y omisiones.

La bsqueda de la estructura

La mejor estructura para los requerimientos de usuario sigue el orden natural del uso.

Los requerimientos deben ser anotados en el orden que los usuarios los utilizaran con su trabajo.

Es posible en algunos casos especiales otros tipos de estructuras.

Estructurar en texto

El lenguaje natural es el nico medio que los usuarios y los desarrolladores comparten.

Sin embargo el texto por si solo no muestra como se enlazan las necesidades de los diferentes usuarios. Despus de todo se desea hacer un sistema no un conjunto independiente de funcionalidades.

Necesitas una estructura que organice los requerimientos, que proporcione una gua en la lectura del texto.

Una buena estructura muestra los requerimientos en diferentes niveles de detalle y permite que los lectores concentrarse en una seccin a la vez.

Problemas y soluciones en la estructura de los requerimientos.

Problema Todos los usuarios necesitan entender los requerimientos Solucin Escriba los requerimientos en lenguaje cotidiano

Largas listas de requerimientos son imposibles de entender

Los requerimientos no muestran que va primero Algunos requerimientos pueden aplicarse simultneamente, o en cualquier orden - una secuencia no ocurre necesariamente en ese orden. La secuencia bsica de requerimientos no muestra que hacer si algo sale mal Ms de una secuencia es posible en un uso normal

Elabore una estructura simple de captulos y secciones para agrupar los requerimientos
Organice los captulos y secciones en orden cronolgico para que se puedan describir los escenarios Indique cuando las secciones en la estructura son secuenciales, paralelas, o alternativas Incluya una seccin para cada excepcin, en el lugar en el cual puede ocurrir Describa todas las secuencias, indique las alternativas

Algunos pasos se aplican en varias secuencias

Algunas restricciones aplican a varios requerimientos Los usuarios encuentran difcil obtener un resumen del documento completo

Descrbalos una vez, y refirase a ellos dondequiera que necesario

Si la restriccin aplica a todo el escenario, incorprala ah. Si la restriccin aplica a una seccin, incluya las referencias cruzadas 1. Todas las soluciones anteriores 2. Incluya un diagrama informal simple para soportar el texto 3. Escriba un resumen 4. Encuentre que es lo difcil de encontrar y reestructure el documento

Organizacin de requerimientos en escenarios

Se recomienda organizar los requerimientos del usuario en escenarios operacionales. Cuando se le pregunta a un usuario que se necesita para alcanzar una meta el describe una simple secuencia de actividades. Cada paso identificado puede ser tomado a su vez como una meta especfica, hasta alcanzar una estructura con el suficiente detalle para ubicar los requerimientos en su lugar natural.

Divida el problema en pasos

Escriba metas

Una meta es un simple resultado deseado

Escriba los pasos para alcanzar las metas Identifique las escalas de tiempos

Escriba la meta

Identifique la meta general o de todo el problema.

La forma natural de expresar metas en comenzar con la palabra para

Por ejemplo, la meta para una empresa de transporte de carga podra ser:

para entregar los bienes

Escriba los pasos bsicos

Usuario: Secuencia de pasos meta

Cada paso es, en efecto, un requerimiento (posiblemente de nivel alto) y una submeta que puede usarse para agrupar un conjunto de requerimientos.
Por ejemplo:

para registrar un pago en la cuenta de la compaa, se tiene que obtener los cheques del pago del cliente. para obtener los cheques de pago, se tiene que enviar las facturas a los clientes.

para enviar las facturas, se tiene que calcular lo que se debe

para calcular...

Algunos pasos pueden involucrar realmente un gran trabajo.

Identifique las escalas de tiempos

Puede ser necesario pensar en escalas de tiempo diferentes para describir un problema correctamente.

Para rea de contabilidad, se podra facturar a cada cliente mensualmente, en cuyo caso se coleccionaran todas las rdenes colocadas durante el mes, calculara los detalles de cuenta mensuales, y facturara al cliente.
Para un ejemplo de velero la escala de tiempo probable para una familia que navega el viaje es un da. Un escenario que describe "un da en la vida de" es a menudo eficaz en la obtencin de los requerimientos. Algunos servicios tienen que correr continuamente, como una red telefnica que est disponible a sus suscriptores 24 horas al da. Sin embargo, todava se puede trabajar con escenarios finitos pensando en transacciones manejadas por el servicio del punto de vista del usuario. El suscriptor marca un nmero, se conecta, tiene una conversacin, y cuelga. La conexin es claramente un conjunto de transacciones por si sola, estn los interruptores y cambios, hoy da ninguno con actores humanos.

Evolucin de un escenario

Un primer escenario asume que los pasos forman una secuencia normal de negocios: un flujo claro del primer al ltimo paso. Los usuarios pueden analizar los escenarios y descubrir huecos y errores. Posteriormente se pueden incorporar otras secuencias como las excepciones, cursos alternativos, secuencias paralelas.

Construyendo la estructura para los requerimientos de usuario

Manejo de excepciones

Usualmente tendemos a no considerar a las excepciones a los acontecimientos "normales" en un sistema dentro de los requerimientos. Esto causar probablemente fracasos en la operacin del sistema.

Qu es una excepcin?

Un evento de excepcin es una acontecimiento no deseado que desva al sistema de su operacin normal en el escenario. Puede ser causado por algo interno o externo al sistema.

Un escenario de excepcin define la respuesta deseada a un acontecimiento de excepcin y dirige a un estado seguro. La meta para un escenario de excepcin es manejar sin daos el evento de excepcin.

Ejemplos

Para cobrar un pago demorado (meta de excepcin)

Enviar recordatorio de pago (Actividad de manejo de excepcin) Recibir pago Registrar la llegada del pago Registrar el pago recibido (paso final de la excepcin, se regresa a lo normal)

Metas, escenarios, requerimientos

Las metas y los requerimientos estn estrechamente relacionados, pero no son la misma cosa.

Una requerimiento puede ser obtenido de una meta aadiendo al menos dos informaciones cruciales: quin quiere el resultado, y cual es su importancia para el.
En un documento de requerimiento, parece natural usar el nombre de la meta como un ttulo de seccin, y el requerimiento puede formar entonces el texto de seccin. Se define un escenario de un modo ms abstracto como una secuencia de medidas tomadas por tipos conocidos de usuarios para conseguir un objetivo. Cada paso en un escenario es una actividad enfocada a conseguir una submeta.

Otra forma de escritura

Tambin es factible la utilizacin de otros documentos para la escritura de los escenarios, uno de los ms utilizados es el documento conocido como: Especificacin de caso de uso

Escritura de los requerimientos

Lo que debe hacerse con cada requerimiento

1. 2. 3. 4. 5. 6.

Expresarse de modo adecuado Ser de acceso sencillo Numerarse Acompaarse de las pruebas que lo verifiquen Tomarse en cuenta en el diseo Tomarse en cuenta en el cdigo

7.
8. 9.

Probarse aislado
Probarse junto con los otros requerimientos Validarse con las pruebas despus de construir la aplicacin

El contexto de la escritura de requerimientos en la construccin de un sistema

1.

Escribir requerimientos
1. 2. 3. 4.

Identificar stakeholders Obtener requerimientos Organizar requerimientos Inspeccionar requerimientos

5.

Revisar e integre a la lnea inicial requerimientos (base line)

2. 3.

Especificar el sistema Disear el sistema

4.
5.

Verificar el sistema
Aceptar el sistema

El reto de escribir requerimientos

Cruzar algunos ros

Hay varios grupos de personas que necesitan comunicarse para alcanzar el xito.

Desarrolladores y usuarios Personal y clientes

Asignar suficientes recursos y esfuerzos

Se necesita tener a la mejor persona para cada parte del trabajo.

Tiempo para trabajar en la mejor estructura Menor esfuerzo esperado (5%) Mayor tiempo esperado

El reto de escribir requerimientos

Prepararse para el cambio

Los requerimientos sufren cambios durante el proyecto.

Incluir retroalimentacin de los stakeholders Delimitar el esfuerzo para requerimientos a travs del proyecto Permitir el cambio Tener en cuenta los sentimientos de usuarios

Los requerimientos bien escritos previenen problemas comunes pero serios.

El objetivo bsico es la claridad

Metas de la escritura

Calidad, no perfeccin.

A menudo los requerimientos se declaran mal al principio y hay que trabajar en ellos para averiguar lo que realmente se quiere para volverlos a escribir de modo que estn claros y precisos.

Esboce, luego mejore

Los requerimientos mejoran cuando usted y los usuarios piensan en lo que se quiere, y usted reflexiona sobre como expresar la necesidad tan claramente como sea posible. No hay ninguna necesidad de tratar de poner la expresin perfecta desde la primera vez.

Sintaxis de los requerimientos

El [Sujeto/Sustantivo] va a [verbo] en/cuando/durante [objeto/cantidad] [adverbio] [condicin/objeto]

Accin
Conducir

Qu?
Evaluacin de gua

Cuando?
dentro de 1 hora

Ordenar Funcionar
Calcular

Datos del vuelo Velocidad del viento

Mensaje de error

dentro de 45 minutos cada marco

hasta 60 nudos

Lanzar
Obtener Proveer Sostener Interfuncionar con

WMD
Posicin de lanzamiento Otros sistemas

Sintaxis de los requerimientos

Debe formar una oracin completa (no una extensa lista de palabras revueltas, o lista de siglas). Declara un sujeto y el predicado donde el sujeto es un usuario. Uso consecuente del verbo "para ser verbo:

va a, ir a o deber para mostrar la naturaleza obligatoria deber o poder para mostrar opcionalidad

Tiene un resultado final.

Contiene criterios evaluacin de xito o es verificable por naturaleza.

Componentes de un requerimiento
Estilo tradicional
Tipo de Usuario Tipo de Resultado (verbo): Objeto: Calificador (frase adverbial): El operador del centro de llamadas va a ver detalles de una casa protegida en menos de dos segundos despus de realizar la consulta

Estilo presente

Tipo de Usuario
Tipo de Resultado (verbo): Objeto: Calificador (frase adverbial):

El piloto
controla el ngulo de inclinacin del avin con una mano

Gua para buenos requerimientos

Use oraciones directas simples

Cada requerimiento debera ser una nica oracin activa, tan corta como sea posible - pero no tan corta.

El piloto ser capaz de ver la velocidad del viento

Use un vocabulario limitado

Escriba en un subconjunto simple de palabras, evitando trminos que pueden aturdir a lectores no tcnicos o externos.

La lnea area ser capaz de cambiar los asientos del avin de negocio a uso de flete de vacaciones en menos de 12 horas

No hay ninguna necesidad de usar palabras domingueras como reconfigurar" ni necesidad de usar siglas, abreviaturas, o jerga de la industria. Por otra parte, cuando hay un trmino tcnico que concisamente expresa el sentido deseado hay que usarlo.

Gua para buenos requerimientos

Identifique al usuario en cada requerimiento

Cada requerimiento debera comenzar nombrando a un usuario.

El piloto ser capaz de

Enfquese en los resultados

Cada requerimiento debe tener un nico resultado.

Ver los nubarrones en el radar

Defina criterios verificables

Cada requerimiento debe ser probado, defina los criterios de aceptacin.

Al menos 100 kilmetros antes

Evite escribir de este modo

Evite la ambigedad

Intente escribir clara y explcitamente, pero no lleve esto demasiado lejos o su texto se har aburrido.

el mismo subsistema tambin ser capaz de generar una seal/advertencia del tipo visible o audible para llamar la atencin del copiloto o del piloto

No haga requerimientos mltiples

No escriba requerimientos que contengan conjunciones (y, o, con, tambin) en las sentencias.

La seal luminosa de batera baja se encender cuando el voltaje caiga por debajo de los 3.6 voltios, y los datos actuales de trabajo o los datos de entrada van a ser salvados

Evite escribir de este modo

No incorpore clusulas de excepciones

Esto dificulta las pruebas de requerimientos.

Las puertas de pasajeros frontales se abrirn automticamente cuando el avin se ha parado, menos cuando la rampa trasera se ha desplegado La alarma de incendios siempre sonar cuando se detecta humo, a menos que la alarma est siendo probada o el ingeniero haya suprimido la alarma.

No le de vueltas

Sentencias largas que divagan tienden a confundir.

Siempre que las seales designadas de entrada de un dispositivo especfico se reciben en el orden correcto donde el sistema es capaz de diferenciar al designador, la seal de salida va a cumplir con el marco requerido de la seccin 3.1.5 para indicar el estado de la entrada deseado.

Evite escribir de este modo

No disee el sistema

Los requerimientos especifican la cubierta de los requerimientos, si suministramos demasiado detalle comenzamos a disear el sistema prematuramente.

La antena ser capaz de la recepcin de seales, usando un corazn de cobre con el blindaje de nylon y un escudo de goma endurecido impermeable

No especule

Los requerimientos son un contrato entre cliente y desarrollador, con los usuarios como el tercero interesado. No existen aqu las "listas de deseo" aquellas cosas que alguien probablemente quiere.

Los usuarios normalmente requieren indicacin temprana de intrusin en el sistema.

Evite escribir de este modo

No mezcle requerimientos y diseo

Los requerimientos de usuario forman un modelo completo de lo que los usuarios quieren. Estos tienen que ser organizados coherentemente para encontrar huecos y traslapes. Lo mismo se aplica al diseo del sistema - este forma un modelo completo del sistema propuesto

El usuario ser capaz de ver el nmero de canal actualmente seleccionado que ser mostrado en un panel de LCD tipo suizo de 14pt aprobado para el Estndar de Regulacin Federal 56789 y montado con lavadores de goma a prueba de choques

No mezcle requerimientos y planes

Los planes son esenciales pero no dentro de los requerimientos.

El tipo panel de despliegue de canal LCD, LED o TFT va a ser seleccionado el 15 de Marzo y el primer prototipo de panel va a estar disponible para pruebas al iniciar la fase 3

Evite escribir de este modo

No juegue con requerimientos ambiguos

Algunas construcciones, como el uso de "o" "y a menos que" en requerimientos, permiten que grupos de lectores diferentes puedan entender cosas diferentes de la misma expresin. No las utilice ni deje que se utilicen para dificultar la relacin cliente-ingeniero

Los operadores van a ser capaces de respaldar cualquier disco en una unidad de disco desprendible rpida o cartucho de cinta.

No utilice trminos vagos o no definidos

Muchas palabras usadas cotidianamente para indicar cualidades deseadas son demasiado vagas para ser usadas en los requerimientos, tales como: fcil de usar, verstil, flexible, aproximadamente, perfeccionado, eficiente, alto desempeo, moderno.

La ventana de impresin ser verstil y fcil de usar La lmpara de indicadora de estado correcto ser iluminada cuanto antes despus de completarse la autorevisin del sistema

Evite escribir de este modo

No exprese posibilidades

Las posibilidades son indicadas con trminos como: puede, debe, podra, quizs, deber, poder, a lo mejor, probablemente.

El subsistema de recepcin probablemente debera ser bastante sensible para recibir una seal dentro de un edificio enmarcado por acero.

Evite ilusiones, sea realista

La ingeniera es una actividad para el mundo real, los sistemas o componentes no son perfectos.

La caja de cambios va ser 100% segura en la operacin normal La red va a manejar todos los errores inesperados sin caerse

Especificacin de requerimientos de software ERS

Escribiendo el documento de requerimientos de software

Qu es un documento de requerimientos?

El documento de requerimientos de software es una declaracin escrita de lo que el software har.

NO incluye como el software responde a cada peticin.

Porqu molestarse con el documento?

Si usted no ha anotado que se supone hace la aplicacin, como va a saber que debe desarrollarse? Y Cmo manejar usted las expectativas de sus clientes?

Beneficios del documento

El objetivo principal de un documento de requerimientos debe ser el de servir como un acuerdo entre los desarrolladores y los clientes respecto a lo que la aplicacin har. En muchos casos este acuerdo se hace legalmente obligatorio va un contrato.

Otros beneficios

Los clientes pueden observar desde el inicio si sus necesidades han sido entendidas. Los desarrolladores puede estimar el esfuerzo implicado en la creacin de la aplicacin.

El lder del proyecto de desarrollo tiene una base para un plan de proyecto. El personal de control de calidad tienen una base para probar la aplicacin.

Tengo que escribir el documento?

Usted debe tener un documento de requerimientos si contesta afirmativamente a cualquiera de las siguientes preguntas?.

Para su aplicacin tomar ms de un mes desde la concepcin del proyecto a la puesta en produccin?. Ms de una persona trabajar en la aplicacin?. Ms de un grupo de trabajo usar la aplicacin?.

Quin usa el documento y porque?

Rol en un proyecto de desarrollo de software Lder de Proyecto Razn para usar el documento de requerimientos Delimita el alcance, divide el proyecto en fases Obtiene acuerdos con los expertos de negocio, patrocinadores del proyecto, administra el desarrollo con las calendarizaciones para las fases

Rastrea el progreso del desarrollo

Analista de requerimientos Obtiene y documenta los requerimientos del negocio Verifica la aplicacin contra los requerimientos Desarrollador Control de Calidad Disea y codifica la aplicacin Verifica la aplicacin contra los requerimientos

Especialista de documentacin

Produce la documentacin de usuario

Quin usa el documento y porque?

Rol en un proyecto de desarrollo de software Especialista en soporte de herencia Soporte Gerente de desarrollo Razn para usar el documento de requerimientos Necesidades de integracin de herencia en el proyecto Aprende sobre la aplicacin

Soporta a los usuarios en produccin

Analiza las fases planeadas y se coordina con el desarrollo de otras aplicaciones Rastrea el progreso del desarrollo

Patrocinador del proyecto

Experto del negocio

Proporciona la motivacin para el proyecto

Evala las fases planeadas y sus alcances Confirma que los requerimientos reflejan las necesidades del negocio

Evala las fases planeadas y sus alcances

Principios generales al escribir el documento

Evite trabajo innecesario.

No haga ningn trabajo que cueste mas de lo que gana. Adapte la estructura y el nivel de detalle en su documento de requerimiento a la naturaleza de la aplicacin.

Use iteraciones

Cada iteracin permite incorporar o modificar requerimientos.

Verifique la informacin.

Es muy importante verificar todos los hechos entrevistando a clientes con puntos de vista que se diferencian usuarios y direccin; usuarios en partes diferentes de la organizacin; etc.

Documente cambios en requerimientos

Los requerimientos cambian desde el inicio hasta el final del proyecto. Es necesario actualizar este documento conforme evolucionan los requerimientos.

Documente solicitudes de mejora

A pesar de tener por un contrato congelados los cambios a requerimientos es necesario documentar las solicitudes de mejora. Estas pueden ser lo suficientemente significativas como para tener que renegociar contratos y modificar los requerimientos.

Rastree los requerimientos

El rastreo de requerimientos permite relacionar requerimientos especficos con otra documentacin del proyecto.

Rastreos principales:

Un requerimiento a su origen (rastreo hacia atrs) Un requerimiento hacia otro (Matriz de rastreabilidad) Un requerimiento hacia el diseo, el cdigo, la documentacin de usuario, o plan de proyecto (rastreo hacia adelante)

Rastreo de requerimientos
Mis requerimientos
Informe de inspeccin de requerimientos que incorpora Mis requerimientos Segmento de diseo que incorpora Mis requerimientos Informe de inspeccin de diseo que incorpora Mis requerimientos Cdigo que implementa Mis requerimientos

Informe de inspeccin de cdigo que incorpora Mis requerimientos

Plan de pruebas que incorpora Mis requerimientos Informe de inspeccin del plan de pruebas que incorpora Mis req. Informe de pruebas que incorpora Mis requerimientos

Matriz de rastreabilidad

Requerimiento 1783 1784

Mdulo 1 mostrarNombre() mostrarCuenta()

Mdulo 2 calcularSaldo() mostrarDireccion()

Mdulo 3 obtenerInteres() mostrarNombre()

Rastreo y prueba de requerimientos funcionales

Validada por

Requerimientos funcionales

Prueba de unidad Se aplica a

Implementada por rastreo

Elemento de diseo

Elemento de cdigo
traza

DISEO

Implementacin

Cmo conseguir que otros lean el documento?

El mejor documento de requerimiento no sirve si no es ledo por las personas apropiadas. Tcnicas

Escriba resmenes Haga presentaciones breves Use documentos de inspeccin formales o informales Enfquese en los expertos de negocios Analice de modo especial con administradores Si es posible use prototipos.

Secciones del documento

Parte I Visin general de la aplicacin

Objetivos Procesos de negocios Roles de usuario y responsabilidades Interacciones con otros sistemas Reemplazo de sistemas heredados Consideraciones para la puesta en operacin Terminologa

Parte II Requerimientos funcionales

Declaracin de funcionalidad Alcance Desempeo Usabilidad Concurrencia

Parte III Apndices

Estndar IEE 830-1993

Bibliografa

Ingeniera del Software (Una perspectiva orientada a objetos), Eric . Braude

Writing Better Requirements, Ian Alexander

Writing a Software Requirements Document, Tanya Berezin www.resg.org.uk/DefenceEvent04/191004GWoods.ppt IEEE Std1233 1998 www.boston-spin.org/slides/010-Jun99-talk.pdf