SlideShare una empresa de Scribd logo
UNIDAD I Procesos de la Ingeniería de Requerimientos
Un sistema de información puede definirse técnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución, ya sea pública o privada. Sistema de Información Introducción
Los Sistemas de Información pueden también ayudar a los administradores a analizar problemas, visualizar cuestiones complejas y crear nuevos productos. Sistema de Información Introducción
Sistema de Información
Los sistemas de información proporcionan la solución institucional más importante a los retos y problemas que surgen del medio ambiente de negocios. Un administrador debe conocer en amplitud las tecnologías de la organización, administración e información en los sistemas. Luego es necesario examinar las capacidades y oportunidades que proporciona la tecnología de la información actual para dar soluciones . Sistema de Información
Tipos de Sistemas de Información
Sistema de Información En la actualidad, los Sistemas de Información juegan un papel estratégico en la vida de la empresa.
Ningún sistema proporciona por sí mismo toda la información que la institución requiere.
Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Una representación documentada de una condición o capacidad. ¿Qué son Requerimientos?
Necesario:  Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso:  Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo:  Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente:  Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo:  Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable:  Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.  Características de los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.  Son difíciles de expresar en palabras (el lenguaje es ambiguo).  Existen muchos tipos de requerimientos y diferentes niveles de detalle.  La cantidad de requerimientos en un proyecto puede ser difícil de manejar.  Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.  Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.  Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.  Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.  Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Dificultades para definir los requerimientos
Expresarse de modo adecuado Ser de acceso sencillo Numerarse Acompañarse con pruebas que lo verifiquen Tomarse en cuenta en el diseño Tomarse en cuenta en el código Probarse aislado Probarse junto con otros requerimientos Validarse con las pruebas después de construir la aplicación Cada requerimiento debe…
"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979. "Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. Definición de Ingeniería de Requerimientos
"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Definición de Ingeniería de Requerimientos
Permite gestionar las necesidades del proyecto en forma estructurada:  Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.  Mejora la capacidad de predecir cronogramas de proyectos,  así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.  Disminuye los costos y retrasos del proyecto : Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.  Mejora la calidad del software : La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).  Mejora la comunicación entre equipos:  La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.  Evita rechazos de usuarios finales : La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. Los principales beneficios que se obtienen  de la Ingeniería de Requerimientos son:
Procesos de la Ingeniería de Requerimientos Requerimientos de Proceso Requerimientos de Usuarios Requerimientos de Análisis y  Negociación Requerimientos para la Gestión
Estos requerimientos existen porque los procesos los usan durante el desarrollo del software. Requerimientos de Proceso
Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Requerimientos del Usuario
Problemas que se presentan cuando se redacta en lenguaje natural: Falta de claridad Confusión de requerimientos Conjunción de requerimientos Requerimientos del Usuario
Pautas sencillas para redactar requerimientos: Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al formato. Utilizar el lenguaje en forma consistente. Resaltar el texto para ver las partes claves del requerimiento. Evitar utilizar el lenguaje “técnico” de computación. Requerimientos del Usuario
Los requisitos se agrupan en categorías y se organizan en subconjuntos, se analiza cada requisito en relación con el resto, se examina los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuario.  Requerimientos para el Análisis y Negociación
Para hacer el Análisis de requisitos se plantean las siguientes cuestiones: ¿Cada requisito es consistente con los objetivos generales del sistema/producto? ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? ¿Algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa? ¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema? ¿Cada requisito está delimitado y sin ambigüedad? Requerimientos para el Análisis y Negociación
5. ¿Cada requisito tiene procedencia? Es decir, ¿Existe un origen (general o específico) conocido para cada requisito? 6. ¿Existen requisitos incompatibles con otros requisitos? 7. ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto? 8. ¿Se puede probar el requisito una vez implementado? Requerimientos para el Análisis y Negociación
Proceso de Negociación Los clientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad.  Los riesgos asociados con cada requisito serán identificados y analizados.  Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados. Requerimientos para el Análisis y Negociación
Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza con la actividad de identificación. A cada requisito se le asigna un único identificador, que puede tomar la forma: <tipo de requisito><requisito no.> Requerimientos para la Gestión
Identificadores, según el tipo de requisito: F Funcional D Datos C Comportamiento I Interfaz S Salida Requerimientos para la Gestión
Matrices que se deben realizar para la Gestión de Requisitos: Matriz de seguimiento de características:  muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto. Matriz de seguimiento de orígenes:  identifica el origen de cada requisito. Matriz de seguimiento de dependencias:  indica cómo se relacionan los requisitos entre sí. Matriz de seguimiento de subsistema:  vincula los requisitos a los subsistemas que lo manejan. Matriz de seguimiento de interfaces:  muestra cómo los requisitos están vinculados a las interfaces externas o internas del sistema. Requerimientos para la Gestión
Matriz de seguimiento de características:  muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto. Ejemplo: Requerimientos para la Gestión Una solución exitosa debería Cuyo impacto ocasiona Afecta a El problema de
Matriz de seguimiento de orígenes:  identifica el origen de cada requisito. Ejemplo: Requerimientos para la Gestión Origen Usuario Tipo Requerimiento
Matriz de seguimiento de interfaces:  muestra cómo los requisitos están vinculados a las interfaces externas o internas del sistema. Ejemplo: Requerimientos para la Gestión Módulo Usuario Tipo Interfaz Requerimiento

Más contenido relacionado

PDF
Ingeniería de requisitos e ingeniería de requerimientos
PPTX
Proceso del software
PPTX
Análisisde requerimientos
PDF
Modelos de desarrollo de aplicaciones web
PDF
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010
PPTX
Estimacion basada en puntos de casos de uso
PPTX
Diseño caso de pruebas
PPTX
Diagrama de despliegue
Ingeniería de requisitos e ingeniería de requerimientos
Proceso del software
Análisisde requerimientos
Modelos de desarrollo de aplicaciones web
Tema N° 7 Atributos de Calidad del Software según Norma ISO 25010
Estimacion basada en puntos de casos de uso
Diseño caso de pruebas
Diagrama de despliegue

La actualidad más candente (20)

PPTX
Modelamiento de software
PDF
3. Análisis de Requerimientos
PPTX
Planificacion de proyecto de software
PDF
Gestión de la Calidad en Proyectos de Software
PPTX
Aseguramiento de la calidad del software SQA
PPTX
Factores de calidad de software grupo#4
PPTX
Requerimientos del software
PPTX
SEGURIDAD EN LINUX vs SEGURIDAD EN WINDOWS
PPTX
Tecnicas de estimacion de software
PPTX
Ventajas y desventajas de cmmi
PDF
Ingenieria de software
PDF
Componentes IHC : Factor Humano
DOCX
25 Estandares - IEEE Calidad de Software
DOCX
Ensayo ingenieria de requisitos
PDF
Analisis de requerimientos, Ingenieria de Software
PPTX
Ingenieria de requerimientos 1
PPT
Fundamentos de la arquitectura de software
DOCX
Factores y métricas que determinan la calidad de un
Modelamiento de software
3. Análisis de Requerimientos
Planificacion de proyecto de software
Gestión de la Calidad en Proyectos de Software
Aseguramiento de la calidad del software SQA
Factores de calidad de software grupo#4
Requerimientos del software
SEGURIDAD EN LINUX vs SEGURIDAD EN WINDOWS
Tecnicas de estimacion de software
Ventajas y desventajas de cmmi
Ingenieria de software
Componentes IHC : Factor Humano
25 Estandares - IEEE Calidad de Software
Ensayo ingenieria de requisitos
Analisis de requerimientos, Ingenieria de Software
Ingenieria de requerimientos 1
Fundamentos de la arquitectura de software
Factores y métricas que determinan la calidad de un
Publicidad

Destacado (20)

PPSX
Ciclo de vida de un sistema de información
DOCX
2. requerimientos del software
PPT
Listado de-requerimientos
PPT
Las Tic Una Realidad Educativa
PPT
Cielos De Francia
PPS
Amistad
PDF
Noticias Sahara Enero 09
PPSX
Eriorkys_Majano_presentacion
PPT
Rodrigo Rojas (Acti)
PPT
Hogar DomóTico2
PPSX
Instructivo para la actividad Moodle
PPT
Configuración punto de acceso
PPTX
Comunicacion Corporativa Retos en un Ambiente Complejo
PPS
Día de la patria
PDF
Noticias Sahara Ago 2009
PPT
trabajo_modelos_final_vrtsion2
PPTX
5 ideas para aplicaciones mas seguras
PDF
Historia de una transformación ágil en Ferrer
PPTX
Cómo aprende un adulto y cómo aplicarlo
PPTX
El futur de les TIC a la vila de Masquefa 2010-12-09
Ciclo de vida de un sistema de información
2. requerimientos del software
Listado de-requerimientos
Las Tic Una Realidad Educativa
Cielos De Francia
Amistad
Noticias Sahara Enero 09
Eriorkys_Majano_presentacion
Rodrigo Rojas (Acti)
Hogar DomóTico2
Instructivo para la actividad Moodle
Configuración punto de acceso
Comunicacion Corporativa Retos en un Ambiente Complejo
Día de la patria
Noticias Sahara Ago 2009
trabajo_modelos_final_vrtsion2
5 ideas para aplicaciones mas seguras
Historia de una transformación ágil en Ferrer
Cómo aprende un adulto y cómo aplicarlo
El futur de les TIC a la vila de Masquefa 2010-12-09
Publicidad

Similar a Unidad I Requerimientos (20)

TXT
Desarrollo unidad1
PDF
Ingeniería de Requerimientos
PDF
Ingeniería de Requerimientos
PPT
Unidad 1.3 Analisis De Requerimientos
PDF
Material de apoyo analis de requerimientos
PPTX
Ingeniería de requisitos
PPTX
Ingenieria de requisitos
PPTX
Ingenieria de requisitos
DOCX
Análisis de requerimientos
PPTX
Ingenieria de requisitos 4tto semestre
PPTX
Ingenieria de requisitos
DOCX
Requerimiento
PDF
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
PPT
Unidad13analisisderequerimientos 13026971308524-phpapp01
PPTX
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
PPTX
importancia del análisis de requerimientos para el desarrollo de sistemas
DOCX
Unidad 1 requerimientos del software
PPTX
Ingenieria de Requerimientos
PDF
Analisis y-tecnicas-de-recoleccion-de-datos
Desarrollo unidad1
Ingeniería de Requerimientos
Ingeniería de Requerimientos
Unidad 1.3 Analisis De Requerimientos
Material de apoyo analis de requerimientos
Ingeniería de requisitos
Ingenieria de requisitos
Ingenieria de requisitos
Análisis de requerimientos
Ingenieria de requisitos 4tto semestre
Ingenieria de requisitos
Requerimiento
Análisis y diseño de sistemas sesion 09 - validacion de requisitos ii
Unidad13analisisderequerimientos 13026971308524-phpapp01
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
importancia del análisis de requerimientos para el desarrollo de sistemas
Unidad 1 requerimientos del software
Ingenieria de Requerimientos
Analisis y-tecnicas-de-recoleccion-de-datos

Último (20)

PDF
Iniciación Al Aprendizaje Basado En Proyectos ABP Ccesa007.pdf
PDF
Introducción a la historia de la filosofía
PPTX
Clase 3 del silabo-gestion y control financiero
PDF
MATERIAL DIDÁCTICO 2023 SELECCIÓN 1_REFORZAMIENTO 1° BIMESTRE.pdf
PPTX
Presentación de la Cetoacidosis diabetica.pptx
PDF
Escuelas Desarmando una mirada subjetiva a la educación
PPTX
LAS MIGRACIONES E INVASIONES Y EL INICIO EDAD MEDIA
PDF
La Formacion Universitaria en Nuevos Escenarios Ccesa007.pdf
PDF
ACERTIJO EL CONJURO DEL CAZAFANTASMAS MATEMÁTICO. Por JAVIER SOLIS NOYOLA
PDF
Como Potenciar las Emociones Positivas y Afrontar las Negativas Ccesa007.pdf
PDF
RM2025 - FUNDAMENTOS TEÓRICOS - PEDIATRÍA.pdf
PDF
La lluvia sabe por qué: una historia sobre amistad, resiliencia y esperanza e...
PDF
Cronograma de clases de Práctica Profesional 2 2025 UDE.pdf
PDF
ACERTIJO Súper Círculo y la clave contra el Malvado Señor de las Formas. Por ...
PDF
1. Intrdoduccion y criterios de seleccion de Farm 2024.pdf
DOCX
Programa_Sintetico_Fase_4.docx 3° Y 4°..
PPTX
MATEMATICAS GEOMETRICA USO TRANSPORTADOR
DOCX
PLAN DE AREA DE CIENCIAS SOCIALES TODOS LOS GRUPOS
PDF
Como usar el Cerebro en las Aulas SG2 NARCEA Ccesa007.pdf
DOCX
PLANES DE área ciencias naturales y aplicadas
Iniciación Al Aprendizaje Basado En Proyectos ABP Ccesa007.pdf
Introducción a la historia de la filosofía
Clase 3 del silabo-gestion y control financiero
MATERIAL DIDÁCTICO 2023 SELECCIÓN 1_REFORZAMIENTO 1° BIMESTRE.pdf
Presentación de la Cetoacidosis diabetica.pptx
Escuelas Desarmando una mirada subjetiva a la educación
LAS MIGRACIONES E INVASIONES Y EL INICIO EDAD MEDIA
La Formacion Universitaria en Nuevos Escenarios Ccesa007.pdf
ACERTIJO EL CONJURO DEL CAZAFANTASMAS MATEMÁTICO. Por JAVIER SOLIS NOYOLA
Como Potenciar las Emociones Positivas y Afrontar las Negativas Ccesa007.pdf
RM2025 - FUNDAMENTOS TEÓRICOS - PEDIATRÍA.pdf
La lluvia sabe por qué: una historia sobre amistad, resiliencia y esperanza e...
Cronograma de clases de Práctica Profesional 2 2025 UDE.pdf
ACERTIJO Súper Círculo y la clave contra el Malvado Señor de las Formas. Por ...
1. Intrdoduccion y criterios de seleccion de Farm 2024.pdf
Programa_Sintetico_Fase_4.docx 3° Y 4°..
MATEMATICAS GEOMETRICA USO TRANSPORTADOR
PLAN DE AREA DE CIENCIAS SOCIALES TODOS LOS GRUPOS
Como usar el Cerebro en las Aulas SG2 NARCEA Ccesa007.pdf
PLANES DE área ciencias naturales y aplicadas

Unidad I Requerimientos

  • 1. UNIDAD I Procesos de la Ingeniería de Requerimientos
  • 2. Un sistema de información puede definirse técnicamente como un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución, ya sea pública o privada. Sistema de Información Introducción
  • 3. Los Sistemas de Información pueden también ayudar a los administradores a analizar problemas, visualizar cuestiones complejas y crear nuevos productos. Sistema de Información Introducción
  • 5. Los sistemas de información proporcionan la solución institucional más importante a los retos y problemas que surgen del medio ambiente de negocios. Un administrador debe conocer en amplitud las tecnologías de la organización, administración e información en los sistemas. Luego es necesario examinar las capacidades y oportunidades que proporciona la tecnología de la información actual para dar soluciones . Sistema de Información
  • 6. Tipos de Sistemas de Información
  • 7. Sistema de Información En la actualidad, los Sistemas de Información juegan un papel estratégico en la vida de la empresa.
  • 8. Ningún sistema proporciona por sí mismo toda la información que la institución requiere.
  • 9. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Una representación documentada de una condición o capacidad. ¿Qué son Requerimientos?
  • 10. Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Características de los requerimientos
  • 11. Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto. Dificultades para definir los requerimientos
  • 12. Expresarse de modo adecuado Ser de acceso sencillo Numerarse Acompañarse con pruebas que lo verifiquen Tomarse en cuenta en el diseño Tomarse en cuenta en el código Probarse aislado Probarse junto con otros requerimientos Validarse con las pruebas después de construir la aplicación Cada requerimiento debe…
  • 13. &quot;Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema&quot; Boehm 1979. &quot;Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones&quot;. STARTS Guide 1987. Definición de Ingeniería de Requerimientos
  • 14. &quot;Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos&quot; Leite 1987. &quot;Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto&quot; Rational Software Definición de Ingeniería de Requerimientos
  • 15. Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto : Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software : La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales : La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:
  • 16. Procesos de la Ingeniería de Requerimientos Requerimientos de Proceso Requerimientos de Usuarios Requerimientos de Análisis y Negociación Requerimientos para la Gestión
  • 17. Estos requerimientos existen porque los procesos los usan durante el desarrollo del software. Requerimientos de Proceso
  • 18. Describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento técnico detallado. Únicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las características de diseño del sistema. Deben redactarse utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos. Requerimientos del Usuario
  • 19. Problemas que se presentan cuando se redacta en lenguaje natural: Falta de claridad Confusión de requerimientos Conjunción de requerimientos Requerimientos del Usuario
  • 20. Pautas sencillas para redactar requerimientos: Inventar un formato estándar y asegurar que todos los requerimientos se adhieren al formato. Utilizar el lenguaje en forma consistente. Resaltar el texto para ver las partes claves del requerimiento. Evitar utilizar el lenguaje “técnico” de computación. Requerimientos del Usuario
  • 21. Los requisitos se agrupan en categorías y se organizan en subconjuntos, se analiza cada requisito en relación con el resto, se examina los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuario. Requerimientos para el Análisis y Negociación
  • 22. Para hacer el Análisis de requisitos se plantean las siguientes cuestiones: ¿Cada requisito es consistente con los objetivos generales del sistema/producto? ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? ¿Algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa? ¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema? ¿Cada requisito está delimitado y sin ambigüedad? Requerimientos para el Análisis y Negociación
  • 23. 5. ¿Cada requisito tiene procedencia? Es decir, ¿Existe un origen (general o específico) conocido para cada requisito? 6. ¿Existen requisitos incompatibles con otros requisitos? 7. ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto? 8. ¿Se puede probar el requisito una vez implementado? Requerimientos para el Análisis y Negociación
  • 24. Proceso de Negociación Los clientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados. Requerimientos para el Análisis y Negociación
  • 25. Es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza con la actividad de identificación. A cada requisito se le asigna un único identificador, que puede tomar la forma: <tipo de requisito><requisito no.> Requerimientos para la Gestión
  • 26. Identificadores, según el tipo de requisito: F Funcional D Datos C Comportamiento I Interfaz S Salida Requerimientos para la Gestión
  • 27. Matrices que se deben realizar para la Gestión de Requisitos: Matriz de seguimiento de características: muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto. Matriz de seguimiento de orígenes: identifica el origen de cada requisito. Matriz de seguimiento de dependencias: indica cómo se relacionan los requisitos entre sí. Matriz de seguimiento de subsistema: vincula los requisitos a los subsistemas que lo manejan. Matriz de seguimiento de interfaces: muestra cómo los requisitos están vinculados a las interfaces externas o internas del sistema. Requerimientos para la Gestión
  • 28. Matriz de seguimiento de características: muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto. Ejemplo: Requerimientos para la Gestión Una solución exitosa debería Cuyo impacto ocasiona Afecta a El problema de
  • 29. Matriz de seguimiento de orígenes: identifica el origen de cada requisito. Ejemplo: Requerimientos para la Gestión Origen Usuario Tipo Requerimiento
  • 30. Matriz de seguimiento de interfaces: muestra cómo los requisitos están vinculados a las interfaces externas o internas del sistema. Ejemplo: Requerimientos para la Gestión Módulo Usuario Tipo Interfaz Requerimiento