Ingeniería de requisitos.

La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo

de sistemas software que tiene como objetivos:
• Definir, con la mejor calidad posible, las características de un sistema software que
satisfaga las necesidades de negocio de clientes y usuarios y que se integre con éxito en el
entorno en el que se explote. La definición de dicho sistema se realiza mediante lo que se
conoce como una especificación de requisitos.
• Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la
especificación de requisitos, manteniendo la trazabilidad entre los requisitos y otros
productos del desarrollo.

MADEJA (Marco de Desarrollo de la Junta de Andalucía) recoge la ingeniería de requisitos

como pieza clave para proporcionar un sistema de información con calidad. Esta calidad
debe entenderse como la satisfacción del usuario ante el sistema de información
proporcionado, que cubre las expectativas, deseos y necesidades que los usuarios
manifestaron y que se supieron recoger e implementar.
El resultado de esta tarea o actividad no es estático, ya que a lo largo del proyecto pueden
aparecer nuevos requisitos, ampliaciones, incluso eliminaciones o modificaciones de los
existentes. Cuanto más tarde descubramos requisitos nuevos o haya desviaciones entre los
requisitos y el producto, mucho mayor impacto tendrá en tiempo y coste.
Desde este punto de vista, se tiene que considerar la trazabilidad de los requisitos como
aspecto fundamental en la gestión de un proyecto. Es decir, actualizar los requisitos del
proyecto conforme se vayan produciendo tales cambios, pero sin olvidar la actualización,
el impacto y la coherencia de la documentación asociada al mismo: análisis del sistema,
diseño, pruebas de validación, etc.

La Ingeniería de Requisitos es una de las partes cruciales en el éxito de todo proyecto

software. La aparición de errores o carencias durante la recogida de requisitos implica un
descenso en la productividad del proceso de desarrollo y, por lo tanto, un incremento del
coste del mismo. Incluir una adecuada ingeniería de requisitos en el ciclo de vida del
software minimizará la posibilidad de que esto ocurra. La Ingeniería de Requisitos se
convierte en pieza clave para poder medir la calidad de un sistema informático al poder
iniciar la definición de la batería de pruebas que el sistema debe pasar, garantizando que
éstas satisfacen los requisitos establecidos y por lo tanto el sistema es válido y
funcionalmente es correcto.
Tener herramientas y mecanismos que recojan las necesidades de los usuarios y que se
alimenten de las opiniones de los mismos, así como integrar los requisitos en todo el
proceso de desarrollo, son parte de los objetivos que cubrimos en estos apartados dentro
del proyecto MADEJA.
De forma estructurada, se presentan los objetivos, responsabilidades y productos de esta
área.
Objetivos:
• Fomentar la realización de una ingeniería de requisitos de acuerdo a los principios de
calidad y eficiencia en el desarrollo establecida por MADEJA
• Trasmitir la importancia de la ingeniería de requisitos y la trazabilidad de los requisitos
como aspecto de un impacto directo en la calidad del sistema de información.

Responsabilidades:
• Definir y establecer pautas que ayuden a estandarizar el desarrollo de procesos y
actividades relacionadas con la ingeniería de requisitos de acuerdo a las buenas prácticas
propuestas por MADEJA. Establecer recursos que faciliten la integración de estas buenas
prácticas dentro del desarrollo común de aplicaciones.
• Facilitar herramientas que ayuden en la automatización, adopción y mantenimiento de
las buenas practicas establecidas por MADEJA para el conjunto de actividades y procesos
relacionadas.
• Facilitar la plantilla del documento de Especificación de Requisitos del Sistema (ERS).

Actividades:
• Identificar las necesidades de negocio de clientes y usuarios.
• Desarrollar los requisitos de un sistema software que satisfaga las necesidades de
negocio Gestionar los requisitos del sistema software a desarrollar.

Métodos agiles.
Cada vez son más las empresas que apuestan por las metodologías ágiles y en la coyuntura
actual las empresas necesitan implementar procedimientos que les permitan entregar
productos de calidad con los costes y tiempos pactados.

Y las metodologías tradicionales ya no bastan para este cometido, no se adaptan a las

nuevas expectativas de los usuarios y a las exigencias del mercado.

Por definición, las metodologías ágiles son aquellas que permiten adaptar la forma de
trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la
respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del
entorno.
En esencia, las empresas que apuestan por esta metodología consiguen gestionar sus
proyectos de forma eficaz reduciendo los costes e incrementando su productividad. Pero
veámoslo detalladamente.
¿Cuáles son los principios básicos de las metodologías ágiles?

En primer lugar, las metodologías ágiles mejoran la satisfacción del cliente dado que se
involucrará y comprometerá a lo largo del proyecto. En cada etapa del desarrollo se
informará al cliente sobre los progresos del mismo. De ese modo, el cliente puede sumar
su experiencia para optimizar las características del producto final. Se pueden evitar así
numerosos malentendidos dado que el cliente poseerá en todo momento una completa
visión del estado del producto.

Asimismo, mejora la motivación e implicación del equipo de desarrollo. Pero esta mejora
no es casual: las metodologías ágiles permiten a todos los miembros del equipo conocer el
estado del proyecto en cualquier momento. Los compromisos son negociados y aceptados
por todos los miembros del equipo y las ideas de cualquiera de sus integrantes son tenidas
en cuenta.
Destacar que los procesos ágiles permiten ahorrar tanto tiempo como costes. El desarrollo
ágil trabaja de un modo más eficiente y rápido que otras metodologías. Además, estos
procesos ponen el foco en cumplir estrictamente el presupuesto y los plazos pactados a la
hora de definir y planificar el proyecto.

Se trabaja con mayor velocidad y eficiencia. En las metodologías ágiles se trabaja

realizando entregas parciales pero funcionales del producto. De ese modo, es posible
entregar en el menor intervalo de tiempo posible una versión funcional del producto.
Gracias a las entregas parciales (centradas en entregar en primer lugar aquellas
funcionalidades que en verdad aportan valor) y a la implicación del cliente será
posible eliminar aquellas características innecesarias del producto.

Las metodologías ágiles permiten mejorar la calidad del producto. La continua interacción
entre los desarrolladores y los clientes tienen como objetivo asegurar que el producto final
sea exactamente lo que el cliente quiere y necesita. Además, este enfoque permite abrazar
la excelencia tecnológica, lo que permite obtener un producto tecnológicamente superior.
Por otro lado, esta metodología permite alertar rápidamente tanto de errores como de
problemas. En la etapa de planificación, el equipo ha presentado una hoja de ruta
anticipando y dando respuesta a los principales problemas técnicos y a la velocidad en la
que se puede trabajar. Con metodologías más tradicionales, los errores no identificados en
las primeras fases del proyecto suelen acarrear costes muy altos.

Y, finalmente, las metodologías ágiles permiten rentabilizar nuestras inversiones más

rápidamente. Gracias a la realización de entregas tempranas el cliente tendrá rápido
acceso a aquellas funcionalidades que en verdad aportan valor acelerando el retorno de la
inversión.
Análisis de requisitos.
El análisis de requisitos está en función de costo y tiempo (f ($, t)).

Back log: recopila un conjunto de requisitos (necesidades técnicas).

MVP: producto mínimo viable.
Daily meeting: reuniones diarias de 15 minutos aprox. en donde está presente: en que
estoy, lo que voy hacer, los problemas que tengo.

Diagnóstico: describir la situación actual (en 3ª persona), va acompañado de un diagrama

de procesos, comprensión del problema.

El análisis de requisitos tiene las siguientes etapas:

Diagnóstico de la situación actual.

 Conocer el negocio.
 Levantamiento de procesos.
 Toma de requerimientos.

Plantear situación ideal.

 descripción.

Plantear alternativas de solución.

 Alternativa 1. (moto)
 Alternativa 2. (auto)

En cada alternativa de solución se debe realizar un estudio de factibilidad, el cual, integra

las siguientes etapas:

Estudio de factibilidad.
 Técnico. (licencia para conducir moto, espacio para estacionar, casco e
indumentaria, moto, patente.)
 Económico. (moto $1,200,000, licencia $25,000, casco $40,000, patente
$120,000, etc.)
 Operacional. (saber conducir)
 Legal. (compra, patente, licencia, seguro, revisión técnica.)
 Análisis costo/beneficio. (costo $1,500,000, gastos $500,000 anuales.)

Propuesta de desarrollo (prototipo).

 Imágenes.
 Vistas.
Casos de uso.
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse
para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso
de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es
una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en
respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas
de casos de uso sirven para especificar la comunicación y el comportamiento de un
sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un
diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una
relación es una conexión entre los elementos del modelo, por ejemplo, la especialización y
la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los
requisitos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito
o en él mismo.
Su uso es común para la captura de requisitos funcionales, especialmente con el
paradigma de la programación orientada a objetos, donde se originaron, si bien puede
utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

En la figura se muestra un diagrama de caso de uso.

Toma de requerimiento.
Para que un proyecto de desarrollo de software pueda tener éxito es crucial realizar una
comprensión total de los requerimientos del software a diseñar.
En la etapa del análisis y la especificación de requerimientos, tanto el cliente, como el
desarrollador juegan un rol fundamental, debido a que el primero se encarga de describir
las necesidades que le apremian, mientras que el segundo es el encargado de dar solución
a dichas necesidades. Debido a que la especificación es complicada de detallar, desde el
comienzo del desarrollo de los sistemas se ha tratado de realizar una adecuada
identificación de los requisitos del sistema derivadas de las necesidades de los usuarios.
Por todo esto, dentro de la Ingeniería existe una rama que se dedica a la captura de
requerimientos, la cual es la Ingeniería de requerimientos cuyo propósito general es
desarrollar técnicas para que este proceso fundamental se realice en forma eficiente y
segura.
La ingeniería de requerimientos se puede dividir en cuatro etapas, las cuales son: estudio
de factibilidad, obtención y análisis de requerimientos, especificación de requerimientos y
validación de requerimientos.

Estudio de factibilidad.

El resultado de esta etapa es producir un informe de factibilidad como se ilustra en la

figura 1 que consiste, tanto en realizar una recolección y evaluación de la información,
como redactar el informe del estudio de la factibilidad.

Obtención y análisis de requerimientos.

El objetivo de esta etapa es determinar: el dominio de la aplicación, desempeño del

sistema, las restricciones que el sistema debe poseer, entre otras cosas. En esta etapa
toman principal importancia los stakeholders, los cuales son aquellas personas con alguna
influencia ya sea directa o indirecta en los requerimientos del sistema, es decir, pueden ser
los usuarios finales, ingenieros desarrolladores, ingenieros de mantenimiento, etc.
Obtención y análisis de requerimientos.

En esta etapa se establece la especificación de los requerimientos, es decir lo que el

sistema debe realizar. Esta etapa es muy complicada debido a que la naturaleza de los
problemas es muy compleja.
Es menester destacar que la especificación puede verse como un proceso independiente
del modo en que se realice, todo esto con el objetivo de lograr una adecuada
implementación de software. Además, se han determinado los siguientes principios para
representar los requisitos de software

1. Separar la funcionalidad de la implementación

2. Desarrollar un modelo de comportamiento de un sistema que comprenda los datos y las
respuestas funcionales de un sistema a varios estímulos del entorno.
3. Establecer los componentes del sistema que interactúan con él.
4. Definir el entorno en que operara el sistema
5. Crear un modelo intuitivo
6. Considerar que una especificación es una abstracción de una situación real por lo cual
será incompleta y existirá a muchos niveles de detalle.
7. Definir un contenido y estructura que sea susceptible a cambios.

Validación de Requerimientos.

En esta etapa se establecen los requerimientos finales ó completos que definirán el

sistema que el cliente desea

REQUERIMIENTOS FUNCIONALES
Un requerimiento funcional, tiene que ver con todas las funciones posee el software, estos
pueden ser: Procedimientos, cálculos, la manipulación de los datos, etc.
Algunos requerimientos funcionales del software son:
 El sistema deberá reconocer si el usuario está registrado, si no es así, el usuario
deberá registrarse.
 El sistema deberá mostrar un mapa con los talleres más cercanos. además,
reconocer si el usuario tiene activado el GPS, si no es así deberá mandar un
mensaje para activar dicha función.
 El sistema al final de cada atención del usuario en el taller seleccionado, deberá
calificar y hacer una breve descripción de la atención del taller.
REQUERIMIENTOS NO FUNCIONALES
Los requerimientos no funcionales tienen que ver más que nada con los atributos de
calidad del software.
Algunos requerimientos no funcionales del software son:
 El sistema deberá ser capaz de tener buen rendimiento cuando se encuentre en
uso.
 El sistema deberá ser fiable para el usuario.
 El sistema deberá contar con disponibilidad hacia el usuario.

HISTORIA DE USUARIO

Yo, como: Usuario de bicicleta

Necesito: Un sistema de información sobre talleres de bicicletas.

Para: Consultar sobre talleres de bicicletas cercanos a la posición donde uno se encuentra.

Reglas de aceptación: El sistema deberá reconocer si el usuario está registrado, si no es así, el

usuario deberá registrarse.

Yo, como: Usuario de bicicleta

Necesito: Un sistema de mapas sobre talleres de bicicletas.

Para: Consultar y obtener la o las rutas más cercanas hacia ese taller.

Reglas de aceptación: El sistema deberá mostrar un mapa con los talleres más cercanos.
Además, reconocer si el usuario tiene activado el GPS, si no es así deberá mandar un mensaje
para activar dicha función.

Yo, como: Usuario de bicicleta

Necesito: Un sistema de evaluación del taller de bicicletas.

Para: Calificar y describir la atención del taller de bicicletas.

Reglas de aceptación: El sistema al final de cada atención del usuario en el taller seleccionado,
deberá calificar y hacer una breve descripción de la atención del taller.