SlideShare una empresa de Scribd logo
Análisis de Requisitos Curso 2008-09 Juan Carlos González Moreno
Introducción Ingeniería de Requisitos.  Modelos de Ciclo de Vida. Proceso de desarrollo. Metodologías de desarrollo. Cliente y usuario.
Ingeniería de Requisitos Los requisitos del sistema  definen lo que tiene que hacer el sistema y las circunstancias bajo las que debe operar .  Tipos: Generales:   Indican a “grosso modo” el objetivo del sistema. Ej:  El sistema registra libros, periódicos, revistas y vídeos. Funcionales:   Definen parte de la funcionalidad del sistema. Ej:  El sistema permitirá buscar un libro por título, autor o ISBN. De Implementación:  Indican como se construirá el sistema. Ej:  La visualización se realizará utilizando el navegador Firefox. De Rendimiento:  Especifica atributos de espacio y/o tiempo. Ej:  El sistema soportara un mínimo de 30 transacciones/segundo. De Usabilidad:  Indican el uso aceptable del sistema. Ej:  Las utilidades se tienen que poder demostrar en < de 15 mn.
Ingeniería de Requisitos La ingeniería de requisitos es  el conjunto de actividades implicadas en descubrir, documentar y mantener un conjunto de requisitos .  Un proceso de ingeniería de requisitos es un  conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema.  El proceso define las actividades a realizar, su secuencia, entradas y salidas de cada actividad, etc. La gestión de requisitos es una  actividad encargada de gestionar los cambios en los requisitos del sistema . La gestión implica el control de cambios y el impacto de los mismos.
Ingeniería de Requisitos Observaciones: El coste de la fase de requisitos: 10-15 % del total Corregir un requisito es 100 veces más caro que un error de programación Los sistemas complejos conllevan miles de requisitos, por lo que es preciso un proceso y herramientas Fallar en los requisitos es fallar en todo el proceso Cuando se habla de requisitos no funcionales se está hablando de atributos de calidad del producto
Documento de Requisitos
Proceso de Requisitos
Gestión de Requisitos
Captura de Requisitos Es un proceso en el cual  los datos son extraídos de las personas pudiendo variar, dependiendo de la persona consultada . La Ingeniería de Requisitos ha trabajado arduamente para tratar de desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y segura: Introspección:   Esta técnica recomienda que el ingeniero de requisitos se  ponga en el lugar del cliente  y trate de imaginar como desearía él el Sistema. Entrevistas:   Existen diferentes tipos de entrevistas recomendadas, entre las que po demos mencionar: Entrevistas de Cuestionarios Entrevistas de final abierto Entrevistas en grupos de desarrollo Discusiones
Captura de Requisitos Entrevistas de Cuestionarios.- Este tipo de entrevistas recomienda que se genere un  cuestionario de preguntas , el cual será aplicado al cliente para comenzar la captura de requisitos. Entrevistas de final abierto.- Este tipo de entrevistas son del tipo que realizan los psicólogos. La idea es que el ingeniero de requisitos permita que el Cliente le vaya  narrando  su problemática y el  ingeniero de Software lo guíe  a través de la narración para ir determinando los requisitos del sistema.
Captura de Requisitos Entrevistas en grupos de desarrollo.- Este tipo de entrevistas recomienda formar  grupos específicos con el personal del cliente . Estos grupos tendrán en común algún área de trabajo o especialidad. El objetivo es poder contar con los expertos en cierta área de la empresa para poder llegar en conjunto a la especificación de requisitos. Discusiones.- Este tipo de entrevistas pretende que el Ingeniero de Requisitos sostenga una  discusión con el Cliente  sobre su problemática para tratar de determinar en conjunto los requisitos del sistema.
Captura de Requisitos Análisis de Protocolo:   Esta técnica parte de la idea de que el  cliente cuenta con un modelo mental preexistente del sistema  deseado. Se enfrenta al “experto “ con un caso real y se observa como lo resuelve (establecimiento del protocolo), preguntando y anotando las dudas. Casos de Uso:   Es una técnica bastante utilizada que &quot; captura cada una de las funciones del sistema &quot; y en base a cada una de ellas especifica sus requisitos. VORD:   Esta técnica es utilizada para capturar requisitos en base a  puntos de vista . Es utilizado en sistemas que van a ser desarrollados con el paradigma de programación orientados a objetos.
Captura de Requisitos Una buena Especificación de Requisitos debe tener en cuenta las siguientes consideraciones: Naturaleza de la Especificación de Requisitos de Software.-  Se deben especificar los siguientes aspectos: Funcionalidad Interfaz Externa Rendimiento Atributos Restricciones de diseño Ambiente de la Especificación de Requisitos.-  Debe de estar descrita de tal manera que no describa aspectos del área de diseño o de implementación.
Captura de Requisitos Características de los Requisitos.-  Los requisitos descritos deben ser: Completos Implementación Independiente Consistente y no Ambiguo Preciso Verificable Que pueda ser leído Modificable
Captura de Requisitos Aprobación del Cliente o patrocinador.-  Todos los requisitos descritos deben contar con ella. Un punto importante a tener en cuenta es la &quot;evolución&quot; de los mismos y proveer mecanismos que permitan la Evolución de la Especificación de Requisitos, e incluir requisitos del Proyecto en la Especificación de Requisitos. Requisitos tales como: Costo Fecha de Entrega Criterios de Validación y Verificación
Captura de Requisitos En general las fases de captura y análisis de requisitos de usuario han recibido  poca atención por parte de las metodologías de desarrollo  de software.  La  transición  a las fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la  trazabilidad  de los requisitos a lo largo de éste proceso, son también aspectos poco soportados por éstas.
Análisis de Requisitos El objetivo del análisis de requisitos es  descubrir problemas en el borrador de requisitos generado durante su captura . Tareas del análisis:  Cuestionarse la necesidad de todos los requisitos Investigar su consistencia y completitud Asegurar su viabilidad:  técnica, costes y planificación Procedimientos: Checklist Matrices de interacción
Negociación de Requisitos La negociación de requisitos es  el proceso de discutir los conflictos encontrados y llegar a algún compromiso que satisfaga a todos los usuarios .  Ej:  En el desarrollo de cierta aplicación para una empresa el departamento de ventas quiere tener acceso total a los recursos almacenados y a la lista de clientes, mientras que el de seguridad quiere controlar dichos recursos y permitir sólo un acceso restringido Tareas de la negociación:  Discutir los requisitos conflictivos Establecer prioridades en los requisitos  Compromiso final sobre el conjunto de requisitos
Validación de Requisitos La validación de requisitos  consiste en comprobar que los requisitos son consistentes, completos y precisos .  Análisis vs. validación: En el análisis tenemos como entrada un  conjunto incompleto  de requisitos, en la validación un  conjunto acordado  de requisitos. En el análisis nos preguntamos si  ¿los requisitos satisfacen las necesidades del cliente?  o  ¿tengo los requisitos adecuados?  en la validación sin embargo las preguntas más frecuentes son  ¿están bien descritos los requisitos?  o  ¿el documento de requisitos representa claramente el sistema?
Validación de Requisitos El proceso puede ser visto como:
Validación de Requisitos Aproximaciones al proceso de validación: Revisión de requisitos.-  Un grupo de personas lee, analiza y discute el documento de requisitos. Se sigue un procedimiento similar al de inspección de código. Test de requisitos.-  Es deseable diseñar pruebas sobre cada requisito individual. Dificultades a la hora de diseñar casos de test para un requisito puede implicar ambigüedad del mismo o falta de información.
Validación de Requisitos Aproximaciones al proceso de validación: Prototipos.-  Sólo tiene sentido si se desarrolla uno durante la fase de captura y se continua con él en el análisis.
Requisitos no funcionales
Problemas Los Problemas del proceso de análisis de requisitos El primer problema que se presenta es la captura de los requisitos del usuario:  De una manera sistemática y organizada.  Usando directrices o líneas guía. Hacer los requisitos manejables y analizables. Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin de comprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semiformal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, areas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el por qué. Después de obtener una buena lista de requisitos, comenzamos con el análisis y el diseño de la aplicación, y entonces nos surgen nuevos problemas: el primero es la trazabilidad de los requisitos: cómo seguir un requisito de usuario por el análisis, el diseño y el código, que nos permita comprobar que el requisito ha sido tenido en cuenta y cómo lo ha sido. Y esto enlaza directamente con el problema de la mantenibilidad: cuando los requisitos comienzan a evolucionar -como sin duda lo harán-, cómo podemos ir evolucionando el diseño y el código consistentemente con ello, y cómo seguir manteniendo la trazabilidad.
Problemas Los Problemas del proceso de análisis de requisitos El segundo problema es pasar a la fase de análisis, donde analizaremos los requisitos obtenidos para: comprenderlos ,  desarrollar una  especificación  de la aplicación  completa y consistente expresarlos al menos  semiformalmente .
Problemas Los Problemas del proceso de análisis de requisitos Además en este proceso, encontraremos habitualmente gran cantidad de fallos en los requisitos:  áreas no especificadas, requisitos contradictorios, y afirmaciones (aparéntemente) vagas e irrelevantes .  Eso nos llevará de vuelta a los usuarios a los que debemos abordarles sabiendo lo que queremos conseguir,  qué  aspectos de los requisitos obtenidos inicialmente  nos interesa aclarar, y por qué .
Problemas Los Problemas del proceso de análisis de requisitos Durante el análisis y el diseño de la aplicación surgen nuevos problemas:  La trazabilidad de los requisitos : cómo seguir un requisito de usuario por el análisis, el diseño y el código. La mantenibilidad : cuando los requisitos evolucionen cómo podemos evolucionar el diseño y el código consistentemente con ello, y manteniendo la trazabilidad.

Más contenido relacionado

La actualidad más candente

Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4
Ingeniería de Sistemas e Informática
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
Alexander Chaunay Paladines
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
landeta_p
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
Jaziel Torres
 
UML
UMLUML
Metodologias para el desarrollo del software
Metodologias para el desarrollo del softwareMetodologias para el desarrollo del software
Metodologias para el desarrollo del software
yeltsintorres18
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominio
SCMU AQP
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rup
Xochitl Saucedo Muñoz
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
Johan Villamizar Tabares
 
Metodología WEB UWE
Metodología WEB UWEMetodología WEB UWE
Metodología WEB UWE
Universidad Técnica del Norte
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
Cesar Prado
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
Angel Minga
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
Sergio Sanchez
 
51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software
Miguel Angel Rodriguez
 
Metodología basada en componentes
Metodología basada en componentes Metodología basada en componentes
Metodología basada en componentes
Anibal Ulibarri
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdencies
MICProductivity
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
Metodologias web
Metodologias webMetodologias web
Metodologias web
Gabriel Mondragón
 
1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño
landeta_p
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
Gerónimo Hernández Martínez
 

La actualidad más candente (20)

Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4
 
Requerimientos norma ieee830
Requerimientos norma ieee830Requerimientos norma ieee830
Requerimientos norma ieee830
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
UML
UMLUML
UML
 
Metodologias para el desarrollo del software
Metodologias para el desarrollo del softwareMetodologias para el desarrollo del software
Metodologias para el desarrollo del software
 
Modelo del dominio
Modelo del dominioModelo del dominio
Modelo del dominio
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rup
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Metodología WEB UWE
Metodología WEB UWEMetodología WEB UWE
Metodología WEB UWE
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
 
51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software51036806 proyecto-ejemplo-ingenieria-de-software
51036806 proyecto-ejemplo-ingenieria-de-software
 
Metodología basada en componentes
Metodología basada en componentes Metodología basada en componentes
Metodología basada en componentes
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdencies
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Metodologias web
Metodologias webMetodologias web
Metodologias web
 
1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño1 3 ingenieria software y patrones de diseño
1 3 ingenieria software y patrones de diseño
 
Ingeniería web_Unidad 3
Ingeniería web_Unidad 3Ingeniería web_Unidad 3
Ingeniería web_Unidad 3
 

Destacado

UML
UMLUML
Qué es el modelado de negocios
Qué es el modelado de negociosQué es el modelado de negocios
Qué es el modelado de negocios
Jonás A. Montilva C.
 
Analisis
AnalisisAnalisis
Analisis
karlalopezbello
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
Mariana Fajardo Estudillo
 
Agente Hola Mundo
Agente Hola MundoAgente Hola Mundo
Agente Hola Mundo
Juan Carlos González Moreno
 
Tema Introducción IS
Tema Introducción ISTema Introducción IS
Tema Introducción IS
Juan Carlos González Moreno
 
Card Sorting: conceptos básicos
Card Sorting: conceptos básicosCard Sorting: conceptos básicos
Card Sorting: conceptos básicos
Mario Carvajal
 
Ingeniería de requisitos(ir)
Ingeniería de requisitos(ir)Ingeniería de requisitos(ir)
Ingeniería de requisitos(ir)
Kleo Jorgee
 
Modelos del ciclo de vida
Modelos del ciclo de vidaModelos del ciclo de vida
Modelos del ciclo de vida
Deguerrerouno
 
Introducción a los Sistemas Inteligentes
Introducción a los Sistemas InteligentesIntroducción a los Sistemas Inteligentes
Introducción a los Sistemas Inteligentes
Juan Carlos González Moreno
 
Analisis Requisitos2
Analisis Requisitos2Analisis Requisitos2
Analisis Requisitos2
msc080277
 
2.2 tecnicas de ingenieria de requisitos
2.2 tecnicas de ingenieria de requisitos2.2 tecnicas de ingenieria de requisitos
2.2 tecnicas de ingenieria de requisitos
Selins Cassiel
 
Meta-Pregunta-Metrica (GQM)
Meta-Pregunta-Metrica (GQM)Meta-Pregunta-Metrica (GQM)
Meta-Pregunta-Metrica (GQM)
junior perez
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
Jorge Ñauñay
 
Utilizando Metodologia Rup Parte1
Utilizando Metodologia Rup Parte1Utilizando Metodologia Rup Parte1
Utilizando Metodologia Rup Parte1
Universidad Nacional de Frontera
 
11 Clase Analisis De Requisitos
11 Clase Analisis De Requisitos11 Clase Analisis De Requisitos
11 Clase Analisis De Requisitos
Julio Pari
 
Modelo del negocio
Modelo del negocioModelo del negocio
Modelo del negocio
Julio Pari
 
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Miquel Mora
 
Modelado de procesos de negocio
Modelado de procesos de negocioModelado de procesos de negocio
Modelado de procesos de negocio
rehoscript
 

Destacado (20)

UML
UMLUML
UML
 
Qué es el modelado de negocios
Qué es el modelado de negociosQué es el modelado de negocios
Qué es el modelado de negocios
 
Analisis
AnalisisAnalisis
Analisis
 
02 captura de requisitos
02 captura de requisitos02 captura de requisitos
02 captura de requisitos
 
Agente Hola Mundo
Agente Hola MundoAgente Hola Mundo
Agente Hola Mundo
 
Tema Introducción IS
Tema Introducción ISTema Introducción IS
Tema Introducción IS
 
Greetings
GreetingsGreetings
Greetings
 
Card Sorting: conceptos básicos
Card Sorting: conceptos básicosCard Sorting: conceptos básicos
Card Sorting: conceptos básicos
 
Ingeniería de requisitos(ir)
Ingeniería de requisitos(ir)Ingeniería de requisitos(ir)
Ingeniería de requisitos(ir)
 
Modelos del ciclo de vida
Modelos del ciclo de vidaModelos del ciclo de vida
Modelos del ciclo de vida
 
Introducción a los Sistemas Inteligentes
Introducción a los Sistemas InteligentesIntroducción a los Sistemas Inteligentes
Introducción a los Sistemas Inteligentes
 
Analisis Requisitos2
Analisis Requisitos2Analisis Requisitos2
Analisis Requisitos2
 
2.2 tecnicas de ingenieria de requisitos
2.2 tecnicas de ingenieria de requisitos2.2 tecnicas de ingenieria de requisitos
2.2 tecnicas de ingenieria de requisitos
 
Meta-Pregunta-Metrica (GQM)
Meta-Pregunta-Metrica (GQM)Meta-Pregunta-Metrica (GQM)
Meta-Pregunta-Metrica (GQM)
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
 
Utilizando Metodologia Rup Parte1
Utilizando Metodologia Rup Parte1Utilizando Metodologia Rup Parte1
Utilizando Metodologia Rup Parte1
 
11 Clase Analisis De Requisitos
11 Clase Analisis De Requisitos11 Clase Analisis De Requisitos
11 Clase Analisis De Requisitos
 
Modelo del negocio
Modelo del negocioModelo del negocio
Modelo del negocio
 
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
Historias de usuario¿Por qué? ¿Qué son? ¿Cómo son?
 
Modelado de procesos de negocio
Modelado de procesos de negocioModelado de procesos de negocio
Modelado de procesos de negocio
 

Similar a Tema 1 Ingeniería de Requisitos

Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276
marlev boadas
 
Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientos
Xilena16
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
Carlos Chaves
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
Luis Anibal
 
Frank estaba infografiae
Frank estaba infografiaeFrank estaba infografiae
Frank estaba infografiae
ID Z
 
Informe
InformeInforme
Taller en clases adolfo y dionisio adsi
Taller en clases adolfo y dionisio adsiTaller en clases adolfo y dionisio adsi
Taller en clases adolfo y dionisio adsi
DIONISIOJIMENEZANGAR
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
kelyquinayas
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
Tensor
 
Diseño de software
Diseño de softwareDiseño de software
Diseño de software
Yamnibel
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
3045433345
 
Carlos leon
Carlos leonCarlos leon
Carlos leon
CLPROGRAM
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
Naylu Rincón
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
Naylu Rincón
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
Tensor
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
jocabedmariamartinez
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
Mario César Ramírez Venegas
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
Sergio Sanchez
 
Especificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRSEspecificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRS
sullinsan
 
Centro biotecnologo del sena
Centro biotecnologo del senaCentro biotecnologo del sena
Centro biotecnologo del sena
leydismartinez1
 

Similar a Tema 1 Ingeniería de Requisitos (20)

Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276
 
Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientos
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Frank estaba infografiae
Frank estaba infografiaeFrank estaba infografiae
Frank estaba infografiae
 
Informe
InformeInforme
Informe
 
Taller en clases adolfo y dionisio adsi
Taller en clases adolfo y dionisio adsiTaller en clases adolfo y dionisio adsi
Taller en clases adolfo y dionisio adsi
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
 
Diseño de software
Diseño de softwareDiseño de software
Diseño de software
 
Taller en clases
Taller en clasesTaller en clases
Taller en clases
 
Carlos leon
Carlos leonCarlos leon
Carlos leon
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
 
Ingeniería de Requerimientos
Ingeniería de RequerimientosIngeniería de Requerimientos
Ingeniería de Requerimientos
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
Especificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRSEspecificaciones de Requerimientos SRS
Especificaciones de Requerimientos SRS
 
Centro biotecnologo del sena
Centro biotecnologo del senaCentro biotecnologo del sena
Centro biotecnologo del sena
 

Último

Lengua y literatura mandioca para aprend
Lengua y literatura mandioca para aprendLengua y literatura mandioca para aprend
Lengua y literatura mandioca para aprend
RaqelBenitez
 
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docxEXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
d33673240a
 
El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........
DenisseGonzalez805225
 
Sesión de clase: El comienzo del evangelio
Sesión de clase: El comienzo del evangelioSesión de clase: El comienzo del evangelio
Sesión de clase: El comienzo del evangelio
https://gramadal.wordpress.com/
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Cátedra Banco Santander
 
Escuelas Creativas Ken Robinson Ccesa007.pdf
Escuelas Creativas Ken Robinson   Ccesa007.pdfEscuelas Creativas Ken Robinson   Ccesa007.pdf
Escuelas Creativas Ken Robinson Ccesa007.pdf
Demetrio Ccesa Rayme
 
Fichero Léxico / Pandemia Lingüística / USCO
Fichero Léxico / Pandemia Lingüística / USCOFichero Léxico / Pandemia Lingüística / USCO
Fichero Léxico / Pandemia Lingüística / USCO
mariahernandez632951
 
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptxPonencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
yaduli
 
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Cátedra Banco Santander
 
Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)
Cátedra Banco Santander
 
ejemplos-del-servicio-cristiano-fiel (1).pptx
ejemplos-del-servicio-cristiano-fiel (1).pptxejemplos-del-servicio-cristiano-fiel (1).pptx
ejemplos-del-servicio-cristiano-fiel (1).pptx
gersonobedgabrielbat1
 
Power Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.pptPower Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.ppt
https://gramadal.wordpress.com/
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
Cátedra Banco Santander
 
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLAACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
JAVIER SOLIS NOYOLA
 
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
nelsontobontrujillo
 
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
Jose Luis Jimenez Rodriguez
 
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
JAVIER SOLIS NOYOLA
 
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Como hacer que te pasen cosas buenas  MRE3  Ccesa007.pdfComo hacer que te pasen cosas buenas  MRE3  Ccesa007.pdf
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Demetrio Ccesa Rayme
 
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Cátedra Banco Santander
 
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
MariaAngelicaMachica
 

Último (20)

Lengua y literatura mandioca para aprend
Lengua y literatura mandioca para aprendLengua y literatura mandioca para aprend
Lengua y literatura mandioca para aprend
 
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docxEXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
EXPERIENCIA DE APRENDIZAJE N° 09 01 AL 19 DE JULIO.docx
 
El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........El mensaje en la psicopedagogía.........
El mensaje en la psicopedagogía.........
 
Sesión de clase: El comienzo del evangelio
Sesión de clase: El comienzo del evangelioSesión de clase: El comienzo del evangelio
Sesión de clase: El comienzo del evangelio
 
Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)Introducción a las herramientas de Google Apps (3 de julio de 2024)
Introducción a las herramientas de Google Apps (3 de julio de 2024)
 
Escuelas Creativas Ken Robinson Ccesa007.pdf
Escuelas Creativas Ken Robinson   Ccesa007.pdfEscuelas Creativas Ken Robinson   Ccesa007.pdf
Escuelas Creativas Ken Robinson Ccesa007.pdf
 
Fichero Léxico / Pandemia Lingüística / USCO
Fichero Léxico / Pandemia Lingüística / USCOFichero Léxico / Pandemia Lingüística / USCO
Fichero Léxico / Pandemia Lingüística / USCO
 
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptxPonencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
Ponencia 4 AT DIRECTIVOS Día del Logro 02 JULIO 2024.pptx
 
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
Licencias de contenidos y propiedad intelectual (1 de julio de 2024)
 
Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)Aplicaciones móviles de grabación (2 de julio de 2024)
Aplicaciones móviles de grabación (2 de julio de 2024)
 
ejemplos-del-servicio-cristiano-fiel (1).pptx
ejemplos-del-servicio-cristiano-fiel (1).pptxejemplos-del-servicio-cristiano-fiel (1).pptx
ejemplos-del-servicio-cristiano-fiel (1).pptx
 
Power Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.pptPower Point: El comienzo del evangelio.ppt
Power Point: El comienzo del evangelio.ppt
 
Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)Recursos Educativos en Abierto (1 de julio de 2024)
Recursos Educativos en Abierto (1 de julio de 2024)
 
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLAACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
ACERTIJO MATEMÁTICO DEL MEDALLERO OLÍMPICO. Por JAVIER SOLIS NOYOLA
 
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
1. QUE ES UNA ESTRUCTURAOCTAVOASANTA TERESA .pptx
 
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
FEEDBACK DE LA ESTRUCTURA CURRICULAR- 2024. Completo - Jose Luis Jimenez Rodr...
 
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
ROMPECABEZAS DE LA DEFINICIÓN DE LOS JUEGOS OLÍMPICOS EN 100 LETRAS. Por JAVI...
 
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
Como hacer que te pasen cosas buenas  MRE3  Ccesa007.pdfComo hacer que te pasen cosas buenas  MRE3  Ccesa007.pdf
Como hacer que te pasen cosas buenas MRE3 Ccesa007.pdf
 
Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)Crear infografías: Iniciación a Canva (1 de julio de 2024)
Crear infografías: Iniciación a Canva (1 de julio de 2024)
 
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
PLANIFICACION PARA NIVEL INICIAL FEBRERO 2023
 

Tema 1 Ingeniería de Requisitos

  • 1. Análisis de Requisitos Curso 2008-09 Juan Carlos González Moreno
  • 2. Introducción Ingeniería de Requisitos. Modelos de Ciclo de Vida. Proceso de desarrollo. Metodologías de desarrollo. Cliente y usuario.
  • 3. Ingeniería de Requisitos Los requisitos del sistema definen lo que tiene que hacer el sistema y las circunstancias bajo las que debe operar . Tipos: Generales: Indican a “grosso modo” el objetivo del sistema. Ej: El sistema registra libros, periódicos, revistas y vídeos. Funcionales: Definen parte de la funcionalidad del sistema. Ej: El sistema permitirá buscar un libro por título, autor o ISBN. De Implementación: Indican como se construirá el sistema. Ej: La visualización se realizará utilizando el navegador Firefox. De Rendimiento: Especifica atributos de espacio y/o tiempo. Ej: El sistema soportara un mínimo de 30 transacciones/segundo. De Usabilidad: Indican el uso aceptable del sistema. Ej: Las utilidades se tienen que poder demostrar en < de 15 mn.
  • 4. Ingeniería de Requisitos La ingeniería de requisitos es el conjunto de actividades implicadas en descubrir, documentar y mantener un conjunto de requisitos . Un proceso de ingeniería de requisitos es un conjunto estructurado de actividades de cuya ejecución se obtiene, valida y mantiene el documento de requisitos del sistema. El proceso define las actividades a realizar, su secuencia, entradas y salidas de cada actividad, etc. La gestión de requisitos es una actividad encargada de gestionar los cambios en los requisitos del sistema . La gestión implica el control de cambios y el impacto de los mismos.
  • 5. Ingeniería de Requisitos Observaciones: El coste de la fase de requisitos: 10-15 % del total Corregir un requisito es 100 veces más caro que un error de programación Los sistemas complejos conllevan miles de requisitos, por lo que es preciso un proceso y herramientas Fallar en los requisitos es fallar en todo el proceso Cuando se habla de requisitos no funcionales se está hablando de atributos de calidad del producto
  • 9. Captura de Requisitos Es un proceso en el cual los datos son extraídos de las personas pudiendo variar, dependiendo de la persona consultada . La Ingeniería de Requisitos ha trabajado arduamente para tratar de desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y segura: Introspección: Esta técnica recomienda que el ingeniero de requisitos se ponga en el lugar del cliente y trate de imaginar como desearía él el Sistema. Entrevistas: Existen diferentes tipos de entrevistas recomendadas, entre las que po demos mencionar: Entrevistas de Cuestionarios Entrevistas de final abierto Entrevistas en grupos de desarrollo Discusiones
  • 10. Captura de Requisitos Entrevistas de Cuestionarios.- Este tipo de entrevistas recomienda que se genere un cuestionario de preguntas , el cual será aplicado al cliente para comenzar la captura de requisitos. Entrevistas de final abierto.- Este tipo de entrevistas son del tipo que realizan los psicólogos. La idea es que el ingeniero de requisitos permita que el Cliente le vaya narrando su problemática y el ingeniero de Software lo guíe a través de la narración para ir determinando los requisitos del sistema.
  • 11. Captura de Requisitos Entrevistas en grupos de desarrollo.- Este tipo de entrevistas recomienda formar grupos específicos con el personal del cliente . Estos grupos tendrán en común algún área de trabajo o especialidad. El objetivo es poder contar con los expertos en cierta área de la empresa para poder llegar en conjunto a la especificación de requisitos. Discusiones.- Este tipo de entrevistas pretende que el Ingeniero de Requisitos sostenga una discusión con el Cliente sobre su problemática para tratar de determinar en conjunto los requisitos del sistema.
  • 12. Captura de Requisitos Análisis de Protocolo: Esta técnica parte de la idea de que el cliente cuenta con un modelo mental preexistente del sistema deseado. Se enfrenta al “experto “ con un caso real y se observa como lo resuelve (establecimiento del protocolo), preguntando y anotando las dudas. Casos de Uso: Es una técnica bastante utilizada que &quot; captura cada una de las funciones del sistema &quot; y en base a cada una de ellas especifica sus requisitos. VORD: Esta técnica es utilizada para capturar requisitos en base a puntos de vista . Es utilizado en sistemas que van a ser desarrollados con el paradigma de programación orientados a objetos.
  • 13. Captura de Requisitos Una buena Especificación de Requisitos debe tener en cuenta las siguientes consideraciones: Naturaleza de la Especificación de Requisitos de Software.- Se deben especificar los siguientes aspectos: Funcionalidad Interfaz Externa Rendimiento Atributos Restricciones de diseño Ambiente de la Especificación de Requisitos.- Debe de estar descrita de tal manera que no describa aspectos del área de diseño o de implementación.
  • 14. Captura de Requisitos Características de los Requisitos.- Los requisitos descritos deben ser: Completos Implementación Independiente Consistente y no Ambiguo Preciso Verificable Que pueda ser leído Modificable
  • 15. Captura de Requisitos Aprobación del Cliente o patrocinador.- Todos los requisitos descritos deben contar con ella. Un punto importante a tener en cuenta es la &quot;evolución&quot; de los mismos y proveer mecanismos que permitan la Evolución de la Especificación de Requisitos, e incluir requisitos del Proyecto en la Especificación de Requisitos. Requisitos tales como: Costo Fecha de Entrega Criterios de Validación y Verificación
  • 16. Captura de Requisitos En general las fases de captura y análisis de requisitos de usuario han recibido poca atención por parte de las metodologías de desarrollo de software. La transición a las fases de diseño, cuando se utilizan metodologías de orientación a objetos, así como la trazabilidad de los requisitos a lo largo de éste proceso, son también aspectos poco soportados por éstas.
  • 17. Análisis de Requisitos El objetivo del análisis de requisitos es descubrir problemas en el borrador de requisitos generado durante su captura . Tareas del análisis: Cuestionarse la necesidad de todos los requisitos Investigar su consistencia y completitud Asegurar su viabilidad: técnica, costes y planificación Procedimientos: Checklist Matrices de interacción
  • 18. Negociación de Requisitos La negociación de requisitos es el proceso de discutir los conflictos encontrados y llegar a algún compromiso que satisfaga a todos los usuarios . Ej: En el desarrollo de cierta aplicación para una empresa el departamento de ventas quiere tener acceso total a los recursos almacenados y a la lista de clientes, mientras que el de seguridad quiere controlar dichos recursos y permitir sólo un acceso restringido Tareas de la negociación: Discutir los requisitos conflictivos Establecer prioridades en los requisitos Compromiso final sobre el conjunto de requisitos
  • 19. Validación de Requisitos La validación de requisitos consiste en comprobar que los requisitos son consistentes, completos y precisos . Análisis vs. validación: En el análisis tenemos como entrada un conjunto incompleto de requisitos, en la validación un conjunto acordado de requisitos. En el análisis nos preguntamos si ¿los requisitos satisfacen las necesidades del cliente? o ¿tengo los requisitos adecuados? en la validación sin embargo las preguntas más frecuentes son ¿están bien descritos los requisitos? o ¿el documento de requisitos representa claramente el sistema?
  • 20. Validación de Requisitos El proceso puede ser visto como:
  • 21. Validación de Requisitos Aproximaciones al proceso de validación: Revisión de requisitos.- Un grupo de personas lee, analiza y discute el documento de requisitos. Se sigue un procedimiento similar al de inspección de código. Test de requisitos.- Es deseable diseñar pruebas sobre cada requisito individual. Dificultades a la hora de diseñar casos de test para un requisito puede implicar ambigüedad del mismo o falta de información.
  • 22. Validación de Requisitos Aproximaciones al proceso de validación: Prototipos.- Sólo tiene sentido si se desarrolla uno durante la fase de captura y se continua con él en el análisis.
  • 24. Problemas Los Problemas del proceso de análisis de requisitos El primer problema que se presenta es la captura de los requisitos del usuario: De una manera sistemática y organizada. Usando directrices o líneas guía. Hacer los requisitos manejables y analizables. Una vez conseguidos los requisitos, pasamos a la fase de análisis. En ella, lo que haremos es analizar los requisitos obtenidos de los usuarios con el fin de comprenderlos, y a partir de ellos desarrollar una especificación de la aplicación, que deberá ser completa y consistente, y deberá estar expresada de una manera al menos semiformal, no simplemente textual. En este proceso, encontraremos habitualmente gran cantidad de problemas en los requisitos, areas no especificadas, requisitos contradictorios, y afirmaciones (aparentemente) vagas e irrelevantes. Eso nos llevará de vuelta a los usuarios con el fin de mejorar la calidad de los requisitos: pero debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y el por qué. Después de obtener una buena lista de requisitos, comenzamos con el análisis y el diseño de la aplicación, y entonces nos surgen nuevos problemas: el primero es la trazabilidad de los requisitos: cómo seguir un requisito de usuario por el análisis, el diseño y el código, que nos permita comprobar que el requisito ha sido tenido en cuenta y cómo lo ha sido. Y esto enlaza directamente con el problema de la mantenibilidad: cuando los requisitos comienzan a evolucionar -como sin duda lo harán-, cómo podemos ir evolucionando el diseño y el código consistentemente con ello, y cómo seguir manteniendo la trazabilidad.
  • 25. Problemas Los Problemas del proceso de análisis de requisitos El segundo problema es pasar a la fase de análisis, donde analizaremos los requisitos obtenidos para: comprenderlos , desarrollar una especificación de la aplicación completa y consistente expresarlos al menos semiformalmente .
  • 26. Problemas Los Problemas del proceso de análisis de requisitos Además en este proceso, encontraremos habitualmente gran cantidad de fallos en los requisitos: áreas no especificadas, requisitos contradictorios, y afirmaciones (aparéntemente) vagas e irrelevantes . Eso nos llevará de vuelta a los usuarios a los que debemos abordarles sabiendo lo que queremos conseguir, qué aspectos de los requisitos obtenidos inicialmente nos interesa aclarar, y por qué .
  • 27. Problemas Los Problemas del proceso de análisis de requisitos Durante el análisis y el diseño de la aplicación surgen nuevos problemas: La trazabilidad de los requisitos : cómo seguir un requisito de usuario por el análisis, el diseño y el código. La mantenibilidad : cuando los requisitos evolucionen cómo podemos evolucionar el diseño y el código consistentemente con ello, y manteniendo la trazabilidad.