Facultad de Ingeniera EAP.

Ingeniera de Sistemas

Ing. CIP. Eddy Ivn Quispe Soto

Requisitos del Software

Importancia de los requisitos

Qu porcentaje de proyectos concluyen con xito? Un estudio realizado por Standish Group analiz el desarrollo de 8000 proyectos de software, realizados por 350 empresas diferentes y concluy que slo el 16% de los proyectos de software se realizan con xito. El estudio identific como principales causas de los problemas: Requisitos deficientes La planificacin de agendas y estimaciones de costes no se realizaron en base a los requisitos Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto

Requisitos del Software

Importancia de los requisitos

Qu porcentaje de proyectos concluyen con xito?

Los criterios para determinar el xito de un proyecto

son:

Sin desviaciones en las fechas previstas. Sin desviaciones en los costes estimados. Que el producto final cubra las expectativas y necesidades del
cliente. Que funcione correctamente.

Requisitos del Software

Importancia de los requisitos

Porqu fracasan los proyectos?

Requisitos del Software

Estadsticas de problemas de los proyectos con relacin a requerimientos
Fuente: Clive Finkelstein.

Requisitos del Software

Requisitos del Software

Importancia de los requisitos

Sus defectos repercuten en todas las fases

REQUISITOS

Estimacin

Planificacin

Diseo

Construccin

V&V

Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute en todas las fases del proyecto. Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar algo que no se conoce. Planificacin No se puede confiar en la planificacin para el desarrollo de algo que no se sabe bien como es. Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en restricciones o futuras evoluciones, producen arquitecturas que ms tarde se confirmarn como errneas y sern modificadas.

Requisitos del Software

Importancia de los requisitos

Sus defectos repercuten en todas las fases

REQUISITOS

Estimacin

Planificacin

Diseo

Construccin

V&V

Construccin: Las deficiencias en los requisitos obligan a

programar en ciclos de prueba y error que derrochan horas y paciencia de programacin sobre patrones de recodificacin continua y programacin heroica. Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen errores de bulto, o peor an, no estn reflejadas en una especificacin de requisitos, no ser posible validar el producto con el cliente.

Requisitos del Software

Importancia de los requisitos

Los defectos comunes en los requisitos y sus consecuencias.

Implicacin insuficiente del cliente Requisitos crecientes y cambiantes Requisitos ambiguos Problemas en la validacin del producto obtenido Degradacin de la estructura y arquitectura del producto Prdida de tiempo en re-codificacin

Requisitos innecesarios Requisitos mnimos (insuficientes)

Requisitos mnimos (insuficientes) Omisin de las necesidades de grupos de usuarios

Trabajo innecesario Problemas en la validacin del producto obtenido

Error en la estimacin y planificacin Usuarios insatisfechos

Requisitos del Software

Importancia de los requisitos

Los defectos comunes en los requisitos y sus consecuencias.

Implicacin insuficiente del cliente Algunos clientes no comprenden la importancia de trabajar con rigor en la obtencin de los requisitos, para garantizar la calidad de los resultados. Tambin es frecuente que los desarrolladores prefieran comenzar a trabajar en la construccin del sistema, porque les resulta ms atractivo que reunirse con el cliente. Hay situaciones en las que resulta difcil encontrar representantes del cliente que conozcan a fondo el problema, o que por tratarse de un sistema o negocio nuevo, nadie en el entorno del cliente tenga claras todas las funcionalidades que se necesitan.

Requisitos del Software

Importancia de los requisitos

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos crecientes y cambiantes Independientemente del punto del ciclo de vida en que nos encontremos, el sistema cambiar y la tendencia al cambio persistir a lo largo de todo el ciclo de vida Software Configuration Management, Prentice-Hall, 1980. Es normal que los requisitos evolucionen durante el desarrollo del sistema, pero los cambios deben partir de una descripcin inicial correcta, y gestionarse convenientemente, midiendo su impacto en la planificacin del proyecto, y consensundolo con todos los participantes.

La evolucin de los requisitos durante el desarrollo de los proyectos puede incrementar o modificar funcionalidades ya implementadas, desbordando los costes y agendas planificados.

Requisitos del Software

Importancia de los requisitos

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos innecesarios Es frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que no figuran en la especificacin de requisitos, con la suposicin de que los usuarios lo agradecern. Muchas veces los usuarios no les encuentran utilidad y quedan finalmente programadas pero sin uso, suponiendo un coste de desarrollo innecesario. Las sugerencias y posibilidades aportadas por el equipo de desarrollo pueden descubrir mejoras importantes para el cliente o los usuarios, pero no deben implementarse sin consultarlas y validarlas previamente. Desde el punto de vista del equipo de desarrollo la mejor perspectiva es respetar la sencillez y funcionalidad, y no ir ms all de los requisitos, sin la aprobacin del cliente. Tambin es frecuente que el cliente pida funcionalidades que a primera vista pueden parecer necesarias, pero que en realidad no aaden funcionalidad al producto, y que sin embargo suponen un esfuerzo importante de desarrollo. Identificar estas funcionalidades, y pensar dos veces si realmente se necesitan puede ahorrar trabajo innecesario

Requisitos del software

Importancia de los requisitos

Beneficios de los buenos requisitos.

Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que
debe realizarse. Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el proyecto que el sistema no era lo que se peda. se emplearn para su validacin. Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su peticin no est documentada y validada por l. y competencias, equipos y tiempo) Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un margen de error; por esta razn disponer de la mayor informacin posible reduce el error.

Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que

Base objetiva para la estimacin de recursos (coste, personal en nmero

Requisitos del Software

Importancia de los requisitos

Beneficios de los buenos requisitos.

Concrecin

etc.) Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento. en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y malentendidos. Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de partes ya desarrolladas, etc.

de los atributos de calidad (ergonoma, mantenibilidad,

Eficiencia

Un requisito es
Requisitos son una especificacin de lo que debera ser implementado. [] -- Ian Sommerville & Pete Sawyer Una condicin o capacidad necesaria para un usuario para solucionar un problema o alcanzar un objetivo [] [IEEE Std 610.12, IEEE Standard Glossary of Software Engineering Terminology]

una especificacin que el sistema o producto debe cumplir

Lo que un usuario quiere no es necesariamente lo que necesita!

Los Requisitos son ... El principal criterio de xito del equipo de proyecto La base de las tareas del equipo de proyecto La base para el diseo, codificacin y las pruebas

Requisitos del Software

Ingeniera de requisitos
Ingeniera de requisitos

Procesos

mbitos

Obtencin

Anlisis

Especif.

V&V

Gestin

Sistema

Software

La ingeniera del software y la ingeniera de requisitos son ingenieras muy recientes. En la actualidad acaba de cerrarse la versin 1.0 de SWEBOK, que constituye el esfuerzo ms serio y consensuado hasta la fecha para definir las reas de conocimiento que la integran. En este estado de cosas no es extrao encontrar que, diferentes autores clasifican o presentan los conceptos clave de forma diferente, si bien los conceptos bsicos siempre son los mismos: Obtencin, anlisis, especificacin, validacin y verificacin y gestin. As por ejemplo, Karl Wiegers centra su inters clasificatorio en la diferencia entre el desarrollo de lo requisitos y su posterior gestin. SWEBOK plantea una representacin esquemtica plana (no distingue entre gestin y desarrollo) y centra su inters slo en los requisitos del software. IEEE carga el peso de la clasificacin en la diferencia entre requisitos del sistema y del software. Nuestro punto de vista contempla las 5 reas clave, que se trabajan tanto en el mbito de los requisitos del sistema como en los requisitos del software.

Requisitos del Software

IEEE
Ingeniera de requisito Proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definicin del sistema hw/sw.

Requisito Condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo. Condicin o facilidad que debe proporcionar un sistema o algunos de sus subsistemas para satisfacer un contrato, norma, especificacin o cualquier otra condicin impuesta formalmente a travs de un documento.

Requisitos del Software

Ingeniera de requisitos
Obtener informacin Registro y contrastacin Controlar las modificaciones Registrar cambios, estudiar su impacto, actualizar documentacin

Obtener informacin

Clasificarla, localizar inconsistencias, dar prioridades, pasar a requisitos

Escribir los requisitos

Comprobar que son formalmente correctos y lo que el cliente quiere

OBTENCIN

ANLISIS

ESPECIFICACIN

VERIFICACIN & VALIDACIN

GESTIN

Obtencin (elicitacion) El primer paso consiste en conocer y comprender las necesidades y problemas del cliente. En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y, en funcin de las caractersticas del entorno y del proyecto se emplean las tcnicas ms apropiadas para la identificacin de las necesidades que deben satisfacerse. Anlisis Una vez obtenida la informacin necesaria del entorno, es necesario sintetizarla, darle prioridades, analizar posibles contradicciones o conflictos, descomponer el sistema y distribuir las necesidades de cada parte, delimitar los lmites del sistema y definir su interaccin con el entorno.

Requisitos del Software

Ingeniera de requisitos
Especificacin Cuando ya se conoce el entorno del cliente y sus necesidades, es necesario plasmarlas en forma de requisitos en los documentos que sirven de base de entendimiento y acuerdo entre cliente y desarrollador, y que establecern tanto la gua desarrollo como los criterios de validacin del producto final. Documentar los requisitos es la condicin ms importante para gestionarlos correctamente. Verificacin y validacin Los requisitos deben ser formal y tcnicamente correctos (verificacin), y satisfacer las necesidades del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validacin). El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico que los diferencia es que verificacin se refiere a la calidad formal, en este caso de los documentos de requisitos (no son ambiguos, no son incompletos, son posibles, verificables, etc.) y validacin comprende la adecuacin en el entorno de produccin, en el caso de la documentacin de requisitos, la conformidad por parte del cliente de que reflejan lo que l quiere.

Gestin
Los requisitos cambiarn durante el desarrollo del sistema, y es necesario poder trazar en cada cambio todas las partes afectadas, as como poder medir el impacto que cada modificacin implica en la planificacin del proyecto.

Requisitos del Software

Descripcin del sistema

Propsito de la descripcin del sistema

El desarrollo de la Descripcin del Sistema proporciona una actividad de anlisis y un documento que tiene la funcin de enlace entre las necesidades del usuario, y las especificaciones tcnicas del desarrollo.

La Descripcin del sistema proporciona:

La descripcin de las necesidades operacionales del usuario sin entrar en detalles

tcnicos.

La documentacin de las caractersticas del sistema y las necesidades operacionales El documento que recoge los deseos del usuario, sin requerir una cuantificacin

del usuario, de forma que puedan ser verificadas sin requerir conocimientos tcnicos. medible. Por ejemplo, el usuario puede indicar que desea que los tiempos de respuesta de las consultas sean rpidos, y las razones de su deseo, sin necesidad de cuantificar esos trminos. Ms adelante, el desarrollo y anlisis de los requisitos del sistema, el analista concretar y cuantificar esos deseos. de solucin, y las restricciones que deben respetarse.

El documento en el que, comprador y suministrador, reflejan las posibles estrategias

Requisitos del Software

Conceptos clave
Independientemente de las tcnicas o procesos que se apliquen para realizar las diferentes tareas relacionadas con el rea de requisitos, son cinco los objetivos que hay que cubrir:

ANALIZAR EL PROBLEMA COMPRENDER LAS NECESIDADES DE LOS USUARIOS DEFINIR EL SISTEMA DESARROLLAR LOS REQUISITOS DEL SOFTWARE GESTIONAR LOS REQUISITOS

Analizar el problema

Comprender las necesidades de los usuarios

Definir el sistema

Desarrollar los requisitos del software

Gestionar los requisitos

Requisitos del Software

Conceptos clave

Analizar el problema
Consiste en comprender los problemas reales de los usuarios, y proponer soluciones que cubran sus necesidades. El objetivo del anlisis es conseguir la mayor comprensin posible antes de que empiece el desarrollo. El analista de requisitos es en realidad un solucionador de problemas. Durante el anlisis debe comprender las necesidades de los usuarios, y proponer soluciones. En esta tarea es necesario explorar y comprender el entorno del cliente. Al realizar el anlisis hay que Evitar la tendencia frecuente a los prejuicios creyendo que ya conocemos las necesidades del cliente, y que su principal problema en realidad es que no entiende cul es su problema. Tener en cuenta que siempre hay varias maneras de abordar un problema, y que en ocasiones, cambiar la perspectiva del usuario puede generar la solucin ms eficiente y rentable, aunque no siempre es posible. Comenzar el anlisis sin ideas preconcebidas y teniendo presente el objetivo: conseguir la mayor comprensin posible del problema. El anlisis del problema comprende 1.2.3.4.Identificacin del problema. Identificacin de las partes implicadas. Delimitacin de la solucin. Identificacin de las restricciones.

Requisitos del Software

Conceptos clave

Comprender las necesidades de los usuarios

La obtencin de los requisitos es sin duda la parte ms difcil del desarrollo de un sistema, y en la actualidad es la principal causa de problemas. En el apartado Obtencin de requisitos desarrolla de forma exclusiva este punto.

Definir el sistema
La descripcin del sistema marca el punto intermedio entre el anlisis del problema, y la descripcin detallada de los requisitos del software. Es el documento que ofrece una visin general, y ofrece la idea global del sistema en su conjunto. Marca una pausa antes de seguir avanzando hacia los detalles, para evitar que los rboles nos impidan ver el bosque.
El resultado de esta fase es el documento de Definicin del sistema, frecuentemente llamado tambin ConOps (Concept of Operations).

Requisitos del Software

Conceptos clave Definir el sistema
La descripcin del sistema el resultado del anlisis conceptual, y debe contener toda la informacin necesaria para describir las necesidades de los usuarios, expectativas, entorno operativo, procesos y caractersticas del sistema que se ha ideado para darles solucin. Los elementos esenciales de la descripcin del sistema son:

Descripcin del sistema o de la situacin actual. Descripcin de las necesidades que han motivado el desarrollo de un sistema nuevo, o de la necesidad de modificar el actual. Modos de operacin propuestos para el nuevo sistema. Tipos de usuarios y caractersticas. Funcionalidades propuestas. Restricciones que debe respetar el sistema.

Por Definir el sistema no consideramos slo la redaccin por el ingeniero de requisitos. Tambin comprende la verificacin y validacin del documento. Por verificacin se entiende la supervisin del documento para garantizar que resulta formalmente correcto. Validacin implica la conformidad de las partes afectadas por el sistema (usuarios, clientes, etc.).

Requisitos del Software

Conceptos clave

Desarrollar los requisitos del software

Tras analizar los problemas y necesidades de los usuarios, conocer las limitaciones que tener en cuenta, y haber sintetizado en la descripcin del sistema la visin global de la solucin que se pretende construir, es el momento de profundizar en los detalles. El nivel de precisin que se debe alcanzar en la descripcin de los requisitos del software, depende de varios factores, incluyendo el contexto de la aplicacin, los conocimientos del equipo de desarrollo, as como su experiencia en desarrollos similares. Los requisitos del software tambin deben verificarse y validarse, para garantizar, por un lado, que son formalmente correctos, y por otro que dan respuesta a las necesidades de todas las partes implicadas.

Requisitos del Software

Obtencin de los requisitos

Problemas frecuentes en la obtencin de requisitos

Los problemas ms frecuentes pertenecen a 3 categoras:

Delimitacin confusa del mbito del sistema. Comprensin Inestabilidad

Problema: delimitacin confusa del mbito del sistema

Antes de entrar en la obtencin de requisitos con detalle es necesario conocer cules son los objetivos y los lmites del sistema. Si no controlamos los lmites y objetivos esperados del sistema, el sistema nos controlar a nosotros Los contextos que es necesario conocer para centrar apropiadamente el sistema en su entorno son:

Organizacin Entorno Proyecto

Requisitos del Software

Obtencin de los requisitos
Problema: delimitacin confusa del mbito del sistema
Para evitarlo deben analizarse y conocerse los tres mbitos sealados ORGANIZACIN Para llevar a cabo la obtencin de requisitos es preciso conocer y comprender la organizacin en la que trabajar el sistema, y los objetivos que se pretenden conseguir. ENTORNO Los factores del entorno del sistema influyen de forma determinante en el proceso de obtencin de requisitos. Los ms importantes son: Restricciones: de hardware, sobre el software o sobre los procesos de desarrollo. Madurez de los procesos del entorno de operacin. Grado de certidumbre de los interfaces con otros sistemas. PROYECTO El contexto en el que se desarrolla el proyecto tambin afecta a los procesos de obtencin de requisitos, que deber adecuar los mtodos y tcnicas de obtencin a las caractersticas del proyecto: Caractersticas especficas de cada grupo de agentes implicados en el proyecto (usuarios, cliente, desarrolladores, normativas, etc.) Restricciones impuestas por las partes implicadas en la obtencin de los requisitos (agenda, coste, parmetros de calidad deseados, etc.)

Requisitos del Software

Obtencin de los requisitos
Problema: comprensin
El 56% de los errores deslizados en los sistemas desarrollados se deben a deficiencias en la comunicacin usuario analista durante la obtencin de los requisitos, y este tipo de errores son los ms caros de corregir porque llegan a consumir hasta el 82% del tiempo de desarrollo[1]. Los problemas de comprensin producen requisitos incompletos, con ambigedades, inconsistentes; y en definitiva incorrectos, porque no definen las necesidades reales de los usuarios. Estos problemas se pueden agrupar en tres categoras:

Dar por supuesto lo desconocido. Lenguaje. Informacin desestructurada.

Problema: inestabilidad
Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio del sistema. La solucin para evitar problemas radica en el proceso de gestin de requisitos.

[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for Requirements Definition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on System Sciences, p. 201-209. IEEE Computer Society, January 1990

Requisitos del Software

Obtencin de los requisitos

Tcnicas de obtencin de requisitos

ENTREVISTAS
Reuniones JAD, cuestionarios reuniones de grupo entrevista, lluvia de ideas

ESCENARIOS

Casos de uso, tarjetas CRC diagramas de flujo, escenarios

TCNICAS
PROTOTIPOS
Prototipos rpidos prototipos evolutivos

OBSERVACIN

Introspeccin anlisis de protocolo documentacin, otros sistemas

Requisitos del Software

Clasificacin de los requisitos
REQUISITO FUNCIONALES RESTRICCIN

REQUISITO TIPOS DE REQUISITOS NO FUNCIONALES RESTRICCIN

REQUISITO DE INTERFAZ RESTRICCIN

Requisitos funcionales
Definen el comportamiento del sistema. Describen las tareas que el sistema debe realizar.

Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad, insuficiencia de detalle o ambigedad, y el exceso de detalle con precisiones o descripciones innecesarias o redundantes.

Describen los servicios o funciones del sistema.

Requisitos del Software

Clasificacin de los requisitos

Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:

Tiempos de respuesta. Caractersticas de usabilidad. Facilidad de mantenimiento. etc.

Describen las restricciones del sistema o del proceso de desarrollo: Niveles de servicio, interfaz, atributos de calidad, etc. En general, los requisitos no funcionales son ms difciles de cuantificar.

Requisitos de interfaz
Definen las interacciones del sistema con su entorno:

Usuarios Otros sistemas

Requisitos del Software

Levantamiento de Requisitos
Definicin de requisitos Expresa en lenguaje natural o con diagramas los servicios y restricciones operacionales del sistema. Se genera con la informacin proporcionada por el cliente.
Especificacin de Requisitos Documento estructurado que describe con detalle los servicios del sistema. A veces llamado especificacin funcional. Escrito como contrato con el cliente. Especificacin de software Escrito para los diseadores. diseo y desarrollo del sistema.

Sirve de base para el

ANEXO DOCUMENTACIN DE REQUISITOS

Requisitos del Software

Propiedades de la documentacin
Completos Conocemos No Conocemos
Entrevistas y revisiones

A Entendemos
Este bloque pertenece a los requisitos que conocemos y sabemos que son aplicables al problema

B
Este bloque pertenece a los requisitos que conocemos pero no conocemos, es decir que sabemos que existen pero no hemos realizado su anlisis.

Prototipado

Prototipado y casos de uso

C No Entendemos
Este bloque pertenece a los requisitos que sabemos que son aplicables al problema pero que no entendemos

D
Este bloque pertenece a los requisitos que no conocemos y tampoco sabemos que no conocemos

Requisitos del Software

Propiedades de la documentacin
Correcta
Una especificacin de requisitos de software es correcta si, y solo si todos y cada uno de los requisitos indicados son los que debe cubrir el software del sistema. No hay ninguna herramienta que pueda garantizar la correccin. Una SRS debe compararse con las especificaciones de rango superior del proyecto (Descripcin del sistema, documentacin referenciada, etc.) para comprobar que cumple sus indicciones. Tambin es recomendable que la parte cliente determine si la especificacin de requisitos de software refleja sus necesidades actuales
Necesidades del Usuario

A B C
Requisitos
Especificados

B
Revisin y aprobacin

Requisitos Correctos

Requisitos del Software

Propiedades de la documentacin
Consistente
El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia con documentos superiores (ej. descripcin del sistema). La ausencia de esta congruencia supondra un problema de correccin y no de consistencia. Una documentacin es internamente consistente si, y solo si, no se establecen conflictos entre requisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son: Conflictos

Objetos

Lgicos

Trminos
RF 10 Informe A cierre de caja RF 50 Informe A cierre diario de operaciones

C=A+B

C=A*B

Requisitos del Software

Propiedades de la documentacin Modificable
Un documento de requisitos es modificable si, y slo si su estilo y estructura permiten que puedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, de forma fcil, completa y consistente. La modificabilidad generalmente requiere en la documentacin: Que tenga una organizacin coherente y fcil, con una tabla de contenidos y un ndice.. Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares del documento) Exprese cada requisito por separado, mejor que mezclados con otros requisitos. La redundancia, por s misma no es un error, pero puede acarrearlos. En ocasiones la redundancia puede hacer un SRS ms legible, pero puede generar errores al actualizar el documento, y generar inconsistencias si slo se actualiza una de las apariciones, olvidando la otra.

Requisitos del Software

Propiedades de la documentacin Trazable
Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita su referencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentacin. Se recomiendan los dos tipos siguientes de trazabilidad: Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuente del requisito. Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tener un nombre o referencia nica. La trazabilidad remota es importante cuando el producto de software entra en la fase de operacin y mantenimiento. Al modificar el diseo y el cdigo es esencial poder determinar todos los requisitos que quedan afectados por una modificacin

Conclusiones
Los requisitos contienen demasiados errores Muchos de estos errores no se detectan al principio. Muchos de estos errores podran ser detectados al principio. No detectar estos errores incrementar los costes (tiempo, dinero) de forma exponencial Recuerde siempre el efecto bola de nieve Los requisitos son un CONTRATO La satisfaccin de los clientes se considera la mejor mtrica de la calidad de un sistema. Si un analista hace exactamente lo que el cliente le indica y el sistema no satisface realmente las necesidades con toda seguridad NO es responsabilidad del cliente

Facultad de Ingeniera EAP. Ingeniera de Sistemas

Ing. CIP. Eddy Ivn Quispe Soto