1. El documento habla sobre los sistemas de información y la ingeniería de requerimientos. Explica que los sistemas de información capturan, procesan, almacenan y distribuyen información para apoyar la toma de decisiones. También describe los requerimientos como condiciones o capacidades necesarias en un sistema y las características que deben cumplir como ser necesarios, concisos y verificables.

1. 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
4. Sistema de Informació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. "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

2. 14. "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
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

3. 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