Gestión de requerimientos y

planificación de un proyecto
informático
Una función principal de la Ingeniería de Requerimientos IR es generar
especificaciones correctas, que describan claramente y sin ambigüedades el
comportamiento deseable del sistema. Si este objetivo se cumple, se logrará minimizar
el número de errores durante la ejecución del proyecto
 Gestión de requerimientos y
planificación de un proyecto
informático
Así, durante este tema se pretende:
• Destacar la importancia de la IR dentro del ciclo de desarrollo de proyectos de TI.
• Dar a conocer las diferentes alternativas que existen para identificar requerimientos dentro
de un proyecto de TI.
• Comentar las diferencias entre las diversas técnicas de la IR.
• Exponer conceptos acerca de los casos de uso y generar habilidades en los estudiantes para
crearlos
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema
determinado es llamado ingeniería de requerimientos (IR), y su meta es entregar una
especificación de requisitos de software correcta y completa (Sommerville, 2005). Otra
definición habla de la IR como “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” (Senn, 1992).
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
En cuanto a su tipología, los requerimientos pueden dividirse en dos: funcionales y no
funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar,
describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Por su parte, los requerimientos no funcionales tienen que ver con características que —de una
u otra forma— puedan limitar el sistema, como por ejemplo el rendimiento (en tiempo y
espacio), las interfaces de usuario, la fiabilidad (robustez del sistema, disponibilidad de equipo),
el mantenimiento, la seguridad, la portabilidad y los estándares, entre otros (Wiegers, 2003).
Conceptos básicos e importancia de la
ingeniería de requerimientos (IR) -
Características de los requerimientos
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
El requerimiento es necesario. Para decidir si un requerimiento es necesario el gerente debe
preguntarse: ¿qué pasaría si se omite este requerimiento? Si la respuesta a esta pregunta genera
una deficiencia en el sistema a construir, o en su capacidad de respuesta al problema que
intenta solucionar, o en sus características físicas, entonces el requerimiento es necesario.
El requerimiento es conciso. Si una persona ajena al proyecto es capaz de leer y entender ese
requerimiento, entonces puede decirse que este es conciso. Para lograr sumar esta
característica, se debe pensar en una redacción simple y clara. Además, es frecuente que los
requerimientos, una vez documentados, sean objeto de consulta por parte de diferentes
stakeholders, así que elaborar requerimientos concisos es fundamental en IR.
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
El requerimiento es completo. Un requerimiento está completo si se proporciona la información
suficiente para su comprensión, y no necesita ampliar detalles en su redacción.
El requerimiento es consistente. El gerente del proyecto debe revisar que no existan
contradicciones entre uno y otro requerimiento dentro del sistema.
El requerimiento no es ambiguo. Un requerimiento está libre de ambigüedades cuando sólo es
posible una única interpretación. Si dos usuarios diferentes leen el mismo requerimiento y
obtienen dos interpretaciones diferentes, entonces es necesario revisar posibles ambigüedades.
El requerimiento es verificable. Esto ocurre cuando el requerimiento puede someterse a
inspección, análisis, demostración o pruebas y continúa siendo válido.
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
Algunos ejemplos de requisitos funcionales de un sistema pueden ser:
• Se deben poder realizar búsquedas con base en diferentes criterios.
• Se deben proporcionar diferentes visores para que el usuario lea los documentos
recuperados.
• Cada factura debe tener un número único y correlativo y la fecha.
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
Ejemplos de requisitos no funcionales pueden ser:
• Se utilizará en todas las comunicaciones el conjunto de caracteres ADA estándar.
• El sistema se debe desarrollar de acuerdo con el proceso estándar XYZCo-SP-STAN-
95.
• El sistema no divulgará a los operadores ninguna información personal sobre los
clientes, aparte de su nombre y su número de referencia.
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
• Los principales beneficios que se obtienen con la IR se pueden resumir de la
siguiente forma (Herrera, 2012):
• Gestionar las necesidades del proyecto de manera estructurada. Cada actividad de
la IR consiste de una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir tanto los cronogramas de proyectos como sus
resultados, ya que proporciona un punto de partida para controles subsecuentes y
para actividades de mantenimiento, tales como estimación de costes, tiempo y
recursos necesarios.
• Disminuye los costes y retrasos del proyecto. En esto coinciden muchos estudios
que han demostrado que reparar errores por un mal desarrollo basado en un
requerimiento inadecuado y no descubierto a tiempo resulta sumamente costoso.
 Conceptos básicos e importancia de la
ingeniería de requerimientos (IR)
• Mejora la calidad del software, puesto que esta tiene que ver con cumplir un
conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad y
desempeño, entre otros).
• Mejorar la comunicación entre equipos, puesto que motiva el consenso entre
clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales ya que fuerza 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
Actividades de la ingeniería de
requerimientos
A pesar de que las actividades realizadas en IR varían
dependiendo del dominio del sistema en particular, del
talento humano implicado y de la organización que
desarrolla los requerimientos, un esquema general del
conjunto de actividades realizadas durante un proceso de IR
puede presentarse como se muestra en la figura
Aunque la figura muestra una secuencia de actividades
concreta para la determinación de requerimientos, en la
práctica dichas actividades pueden realizarse bien de forma
secuencial, o bien de manera continua pero cambiando su
orden.
Actividades de la ingeniería de
requerimientos
Estudio de viabilidad
Por medio del estudio de viabilidad es como se decide si el sistema propuesto es
conveniente. Se trata de un estudio rápido y orientado a conocer si el sistema
contribuye a los objetivos de la organización, si el sistema se puede realizar con la
tecnología actual y con el tiempo y el coste previstos, y si el sistema puede integrarse
con otros existentes en la empresa
Actividades de la ingeniería de
requerimientos
Captura de requerimientos
Este paso es de especial relevancia puesto que de él depende en gran medida el éxito
del futuro sistema. En términos generales la captura de requisitos es el proceso
mediante el cual los usuarios descubren, revelan, organizan y comprenden los
requisitos que desean para el futuro sistema. Para ello se dispone de diferentes
técnicas, entre ellas la observación directa, las entrevistas y las herramientas CASE.
Dado que en esta etapa se trata de descubrir los requisitos, el personal técnico debe
trabajar en estrecha relación con los clientes y usuarios para descubrir el dominio de la
aplicación los servicios que se deben proporcionar y las restricciones que pueden
existir.
Actividades de la ingeniería de
requerimientos
Para una correcta y más completa captura de requisitos, es útil seguir los siguientes
pasos:
1. Obtener información sobre el dominio del problema y el sistema actual.
2. Preparar y realizar las reuniones de captura de requisitos.
3. Identificar y revisar los objetivos del sistema.
4. Identificar y revisar los requisitos de información.
5. Identificar y revisar los requisitos funcionales y los no funcionales.
6. Priorizar objetivos y requisitos.
Actividades de la ingeniería de
requerimientos
Existen diversas formas o técnicas para realizar
la captura de requisitos o requerimientos. A
continuación se esbozarán los elementos
importantes de cada una de ellas. En este punto
es importante recalcar que dentro de cada
proyecto las técnicas se pueden usar por
separado (y elegir sólo una), o bien puede
usarse una combinación entre algunas de ellas.
Esto dependerá del gerente del proyecto, y de
ciertos factores como el tiempo disponible para
la actividad de captura, o la complejidad del
sistema.
Actividades de la ingeniería de
requerimientos
En cuanto a los workshops, estos hacen referencia a reuniones entre diversos usuarios
y miembros del equipo de proyecto al mismo tiempo, en las cuales se busca lograr un
acuerdo general sobre el alcance, los riesgos y las características importantes del
sistema. Cada workshop tiene un facilitador o moderador, y su duración puede
extenderse entre tres y cinco días. Normalmente las salidas de un workshop
comprenden:
Una descripción del problema que se está estudiando y que lleva asociado uno o
varios requerimientos.
Un diagrama de casos de uso.
Una lista de riesgos asociados con el requerimiento.
Actividades de la ingeniería de
requerimientos
Actividades de la ingeniería de
requerimientos
Actividades de la ingeniería de
requerimientos
En cuanto a los workshops, estos hacen referencia a reuniones entre diversos usuarios
y miembros del equipo de proyecto al mismo tiempo, en las cuales se busca lograr un
acuerdo general sobre el alcance, los riesgos y las características importantes del
sistema. Cada workshop tiene un facilitador o moderador, y su duración puede
extenderse entre tres y cinco días. Normalmente las salidas de un workshop
comprenden:
Una descripción del problema que se está estudiando y que lleva asociado uno o
varios requerimientos.
Un diagrama de casos de uso.
Una lista de riesgos asociados con el requerimiento.
Actividades de la ingeniería de
requerimientos
Los workshops tienen una ventaja frente a otras herramientas y es la velocidad con la
que permiten llegar a resultados. Esto es así porque en un mismo escenario se
consigue reunir a diferentes stakeholders que aportan su visión particular. Esta visión
es discutida y posteriormente consensuada. Con otras técnicas este proceso puede
durar varias semanas.
En cuanto a las entrevistas como método de captura de requerimientos, estas resultan
muy útiles si el objetivo es recoger por separado las diferentes percepciones de
diversos stakeholders implicados. Esto es así dado que cada usuario tiene un
conocimiento particular sobre el área de estudio, sobre las necesidades y los aspectos
a mejorar, construyendo así su propia visión del sistema (generalmente la dirección
posee una visión global pero difusa, mientras que los trabajadores poseen una visión
parcial, pero concreta).
Actividades de la ingeniería de
requerimientos
Para tener en cuenta:
• Claves para escribir requerimientos
• Utilizar un mismo formato, estándar para todos los requerimientos.
• Emplear el idioma de manera coherente, sin lugar a ambigüedades.
• Distinguir entre los requisitos obligatorios y los deseables.
• Resaltar el texto para identificar las partes clave del requisito.
• Evitar el uso de lenguaje excesivamente técnico.
 La administración de requerimientos
por
medio de casos de uso
Los casos de uso son una técnica para especificar el comportamiento de un sistema.
Como lo expresan McMenamin y Palmer (1984), “un caso de uso es una secuencia de
interacciones entre un sistema y alguien o algo que usa alguno de sus servicios”.
En la vida diaria, un sistema se comunica con su entorno mediante una serie de
servicios que el sistema ofrece. Un caso de uso es una técnica que permite expresar
cómo alguien o algo externo a un sistema lo usa. Cuando se hace referencia a “algo”,
es básicamente debido a que los sistemas son usados por personas, pero también por
otros sistemas.
 La administración de requerimientos
por
medio de casos de uso
Por ejemplo, un sistema de registro de ensayos de laboratorio debe ofrecer un servicio
para ingresar una nueva solicitud de ensayo, así, cuando un usuario accede a este
servicio, se puede decir que está “ejecutando” el caso de uso o “ingresando solicitud
de ensayo”
 La administración de requerimientos
por
medio de casos de uso
Para tener en cuenta:
• Los eventos describen qué hace el sistema cuando el evento ocurre. Los casos de
uso describen cómo es el diálogo entre el usuario y el sistema.
• Los eventos son “atómicos”: se recibe una entrada, se la procesa y se genera una
salida. Los casos de uso se prolongan a lo largo del tiempo mientras dure la
interacción del usuario con el sistema. Un caso de uso puede agrupar varios
eventos.
• Para los eventos lo importante es qué datos ingresan al sistema o salen de él
cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que
para los casos de uso la importancia del detalle sobre la información que se
intercambia es secundaria.
 Principales conceptos en la
técnica de casos de uso (CU)
Actores
Identificar a los actores es el primer paso para usar la técnica de casos de uso. Un
actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan
con el sistema que se construye. Por ejemplo, para un departamento de atención
telefónica al cliente, que recibe llamadas, todos los operadores que reciban solicitudes
en forma de llamadas, y las ingresen en un sistema, si pueden hacer las mismas cosas
con el sistema, son considerados un único actor: “Operador de atención telefónica”.
Los actores son externos al sistema que se va a desarrollar.
 Principales conceptos en la
técnica de casos de uso (CU)
Caso de uso
Es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de
sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese
actor, junto con otros actores, intercambian datos o control con el sistema,
participando de ese caso de uso. El nombre de un caso de uso se expresa con un
verbo, seguido generalmente por el principal objeto o entidad del sistema que es
afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con
el nombre del caso en su interior.
 Principales conceptos en la
técnica de casos de uso (CU)
Extensiones
En algunas oportunidades, los CU incluyen un conjunto de pasos que ocurren sólo en
algunas oportunidades. En estas oportunidades se dice que el caso de uso1 extiende el
caso de uso2 y se representa por una línea de trazos desde el caso que “extiende a” el
caso que es “extendido”. Las extensiones tienen las siguientes características:
• Representan una parte de la funcionalidad del caso que no siempre ocurre.
• Son un caso de uso en sí mismas.
• No necesariamente provienen de un error o excepción.
 Principales conceptos en la
técnica de casos de uso (CU)
Usos
Una ocurrencia frecuente es que la misma funcionalidad del sistema sea accedida a
partir de varios CU. Por ejemplo, la funcionalidad de buscar un ensayo de laboratorio
puede ser accedida desde el ingreso de ensayos, desde las consultas de ensayos
existentes, o desde los informes de solicitudes por ensayo. A esto se denomina
relaciones de uso. Así pues, las características de las relaciones de uso son:  Aparecen
como función común, a posteriori de la especificación de varios casos de uso.  Los
casos usados son casos de uso en sí mismos.  El caso es usado siempre que el caso
que lo usa se ejecuta. Esto marca la diferencia con las extensiones, que son opcionales.
 Principales conceptos en la
técnica de casos de uso (CU)
No obstante lo anterior, algunos autores afirman que en el análisis de casos de uso los
diagramas no son verdaderamente importantes (Gracia, 2003), o al menos no lo son
tanto como el documento que describe los casos de uso. En este documento se explica
la forma de interactuar entre el sistema y el usuario. Por ejemplo, un documento de
caso de uso podría ser el se presenta en la tabla
 Principales conceptos en la
técnica de casos de uso (CU)
No obstante lo anterior, algunos autores afirman que en el análisis de casos de uso los
diagramas no son verdaderamente importantes (Gracia, 2003), o al menos no lo son
tanto como el documento que describe los casos de uso. En este documento se explica
la forma de interactuar entre el sistema y el usuario. Por ejemplo, un documento de
caso de uso podría ser el se presenta en la tabla
 Principales conceptos en la
técnica de casos de uso (CU)
 Principales conceptos en la
técnica de casos de uso (CU)