Ingeniería de requerimientos
Ingeniería de Requerimientos Y
La Ingeniería de
Requerimientos (IR) cumple un papel primordial en el proceso de producción de software, ya que
se enfoca un área fundamental: la definición de lo que se desea producir. Su
principal tarea consiste en la generación de especificaciones correctas que
describan con claridad, sin ambigüedades, en forma consistente y compacta, las
necesidades de los usuarios o clientes; de esta manera, se pretende minimizar
los problemas relacionados por la mala gestión de los requerimientos en el
desarrollo de sistemas.
2.
Ingeniería de requerimientos: conceptos y características
Como se menciono
anteriormente, la ingeniería de requerimientos sirve como una base sólida en el
proceso de desarrollo de software, por lo que antes de pasar a tratar los
aspectos referentes a la administración
adecuada de los requerimientos, es importante primero definir lo que es un
requerimiento y cuales serían las características deseables que deberían de
tener.
2.1 ¿Qué
son Requerimientos?
Se presenta a
continuación la definición existente en el glosario de la IEEE de lo que es un
“Requerimiento”:
1. “Una
condición o necesidad de un usuario para resolver un problema o alcanzar un
objetivo”. (Std
610.12-1900, IEEE: 62)
2. “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”.
(Std
610.12-1900, IEEE: 62)
También, Ian
Sommerville presenta una definición acerca de lo que es un “Requerimiento”:
3. “Un
requerimiento es simplemente una declaración abstracta de alto nivel de un
servicio que debe
proporcionar el
sistema o una restricción de éste”. (Sommerville, 2005: 108)
Analizando las
definiciones anteriores, un requerimiento es una descripción de una condición o
capacidad que debe cumplir
un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, estipulada en un
contrato, estándar, especificación u otro documento formalmente impuesto al
inicio del proceso.
2.2 Tipos
de Requerimientos
Los
requerimientos de software pueden dividirse en 2 categorías: requerimientos
funcionales y requerimientos
no funcionales.
Los
requerimientos funcionales son los que definen las funciones que el sistema
será capaz de realizar, describen las
transformaciones que el sistema realiza sobre las entradas para producir
salidas. Es importante que
se describa el ¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones.
Estos requerimientos
al tiempo que avanza el proyecto de software se convierten en los algoritmos,
la lógica y gran parte del
código del sistema.
Por otra 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),
interfaces de usuario,
fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento,
seguridad,
portabilidad, estándares,
etc.
2.3
Características de un Requerimiento
Es importante no
perder de vista que un requerimiento debe ser:
Especificado por
escrito: Como todo contrato o acuerdo entre dos partes.
Posible de
probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo
se sabe si se
cumplió con él o no?
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.
2.4
Dificultades para definir los requerimientos
Durante la etapa
de especificación de requerimientos se pueden presentar muchos inconvenientes
los
cuales son
importantes de identificar y prevenir, a continuación se presenta un listado
con los problemas más comunes en
este proceso:
Los
requerimientos no son obvios y vienen de muchas fuentes.
Son difíciles de
expresar en palabras (el lenguaje es ambiguo).
La cantidad de
requerimientos en un proyecto puede ser difícil de manejar.
Un requerimiento
puede cambiar a lo largo del ciclo de desarrollo.
El usuario no
puede explicar lo que hace Tiende a
recordar lo excepcional y olvidar lo rutinario Hablan de lo que
no funciona Los usuarios
tienen distinto vocabulario que los desarrolladores.
2.5
Ingeniería de requerimientos
El proceso de
recopilar, analizar y verificar las necesidades del cliente o usuario para un
sistema es llamado
ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR)
es entregar una especificación
de requisitos de software correcta y completa.
Algunos otros
conceptos de ingeniería de requerimientos son:
“Ingeniería de
Requerimientos ayuda a los ingenieros de software a entender mejor el
problema en cuya
solución trabajarán. Incluye el conjunto de tareas que conducen a
comprender cuál
será el impacto del software sobre el negocio, qué es lo que el cliente
quiere y cómo
interactuarán los usuarios finales con el software”. (Pressman, 2006: 155)
“La ingeniería
de requerimientos es el proceso de desarrollar una especificación de
software. Las
especificaciones pretender comunicar las necesidades del sistema del
cliente a los
desarrolladores del sistema”. (Sommerville, 2005: 82)
En síntesis, el
proceso de ingeniería de requerimientos se utiliza para definir todas las
actividades involucradas en
el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de
software determinado, donde es muy importante tomar en cuenta que el aporte de
la IR vendrá a ayudar
a determinar la viabilidad de llevar a cabo el software (si es factible
llevarlo a cabo o no), pasando
posteriormente por un subproceso de obtención y análisis de requerimientos, su
especificación formal, para
finalizar con el subproceso de validación donde se verifica que los
requerimientos realmente definen el
sistema que quiere el cliente.
2.6
Importancia de la ingeniería de requerimientos
Según la autora
Lizka Johany Herrera en su documento de la ingeniería de requerimientos, los principales
beneficios que se obtienen de la Ingeniería de Requerimientos son (2003: 3):
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: es sabido que reparar errores por un mal
desarrollo no descubierto a
tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR,
ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de
las primeras en llevarse a cabo.
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.
2.7 Actividades
de la ingeniería de requerimientos
Dentro del mismo
documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la
IR existen cuatro
actividades básicas que se tienen que llevar a cabo para completar el proceso.
Estas actividades
ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto
de software realizar una
especificación y administración adecuada de los requerimientos de los clientes
o usuarios.
Las cuatro
actividades son: extracción, análisis, especificación y validación, y serán
explicadas a continuación
cada una de ellas.
2.7.1
Extracción
Esta fase
representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a
las actividades
involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los
analistas de requerimientos
deben trabajar junto al cliente para descubrir el problema que el sistema debe
resolver, los diferentes
servicios que el sistema debe prestar, las restricciones que se pueden
presentar, etc. Es importante,
que la extracción sea efectiva, ya que la aceptación del sistema dependerá de
cuan bien éste satisfaga
las necesidades del cliente.
2.7.2
Análisis
Sobre la base de
la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir
problemas con los requerimientos del sistema identificados hasta el momento.
Usualmente se
hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos;
en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el
resto del equipo, se resaltan los problemas, se buscan alternativas y
soluciones, y luego se van fijando
reuniones con el cliente para discutir los requerimientos.
2.7.3
Especificación
En esta fase se
documentan los requerimientos acordados con el cliente, en un nivel apropiado
de detalle. En la práctica,
esta etapa se va realizando conjuntamente con el análisis, se puede decir que
la especificación
es el "pasar en limpio" el análisis realizado previamente aplicando
técnicas y/o estándares de
documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un
estándar para el modelado
orientado a objetos, por lo que los casos de uso y la obtención de
requerimientos basada en casos de uso se
utiliza cada vez más para la obtención de requerimientos.
2.7.4
Validación
La validación es
la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es
decir, verificar todos los
requerimientos que aparecen en el documento especificado para asegurarse que
representan una descripción, por
lo menos, aceptable del sistema que se debe implementar. Esto implica verificar
que los requerimientos
sean consistentes y que estén completos.
Se puede
apreciar que el proceso de ingeniería de requerimientos es un conjunto
estructurado de actividades,
mediante las cuales se obtiene, se valida y se logra dar un mantenimiento
adecuado al documento de
especificación de requerimientos, que es el documento final, de carácter
formal, que se obtiene de este
proceso. Es necesario recalcar que no existe un proceso único que sea válido de
aplicar en todas las
organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo
al tipo de producto que se
esté desarrollando, a la cultura organizacional, y al nivel de experiencia y
habilidad de las personas
involucradas en la ingeniería de requerimientos. Hay muchas maneras de
organizar el proceso de
ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de
recurrir a consultores, ya
que ellos tienen una perspectiva más objetiva que las personas involucradas en
el proceso.
3.
Técnicas y herramientas utilizadas en la ingeniería de requerimientos
3.1 Técnicas utilizadas en las actividades de
IR
Existen varias
técnicas para la IR propuestas para ingeniería de requerimientos (Herrera,
2003: 12), y de las cuales en
este artículo solo se abarcarán cinco de ellas. Es importante resaltar que
estas técnicas pueden ser
aplicables a las distintas fases del proceso de la IR, haciendo la salvedad de
que hay que tomar en cuenta
las características propias del proyecto en particular que se este
desarrollándose para aprovechar al
máximo su utilidad.
3.1.1
Entrevistas y Cuestionarios
Las entrevistas
y cuestionarios se emplean para reunir información proveniente de personas o de
grupos.
Durante la
entrevista, el analista conversa con el encuestado; el cuestionario consiste en
una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo común,
los encuestados son usuarios de los sistemas existentes o usuarios en potencia
del sistema
propuesto. En algunos casos, son gerentes o empleados que proporcionan datos
para el sistema propuesto o que
serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y
de su preparación para la misma.
3.1. 2
Sistemas existentes
Esta técnica
consiste en analizar distintos sistemas ya desarrollados que estén relacionados
con el sistema a ser
construido. Por un lado, podemos analizar las interfases de usuario, observando
el tipo de información que
se maneja y cómo es manejada, por otro lado también es útil analizar las
distintas salidas que los
sistemas producen (listados, consultas, etc.), porque siempre pueden surgir
nuevas ideas sobre la base de
estas.
3.1.3
Lluvia de ideas (Brainstorm)
Este es un
modelo que se usa para generar ideas. La intención en su aplicación es la de
generar la máxima cantidad
posible de requerimientos para el sistema. No hay que detenerse en pensar si la
idea es o no del todo
utilizable. La intención de este ejercicio es generar, en una primera instancia,
muchas ideas.
Luego, se irán
eliminando en base a distintos criterios como, por ejemplo, "caro",
"impracticable",
"imposible",
etc.
Las reglas
básicas a seguir son:
Los
participantes deben pertenecer a distintas disciplinas y, preferentemente, deben
tener mucha experiencia.
Esto trae aparejado la obtención de una cantidad mayor de ideas creativas. Conviene
suspender el juicio crítico y se debe permitir la evolución de cada una de las
ideas, porque sino se
crea un ambiente hostil que no alienta la generación de ideas.
Por más locas o
salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas
probablemente se tornen en un requerimiento sumamente útil.
A veces ocurre
que una idea resulta en otra idea, y otras veces podemos relacionar varias
ideas para generar una
nueva.
3.1.4
Prototipos
Durante la
actividad de extracción de requerimientos, puede ocurrir que algunos
requerimientos no estén demasiado claros
o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta
el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema
final.
Entonces, para
validar los requerimientos hallados, se construyen prototipos. Los prototipos
son simulaciones del
posible producto, que luego son utilizados por el usuario final, permitiéndonos
conseguir una importante retroalimentación en cuanto a si el sistema diseñado
con base a los requerimientos recolectados le
permite al usuario realizar su trabajo de manera eficiente y efectiva.
El desarrollo
del prototipo comienza con la captura de requerimientos. Desarrolladores y
clientes se reúnen y definen
los objetivos globales del software, identifican todos los requerimientos que
son conocidos, y
señalan áreas en las que será necesaria la profundización en las definiciones.
Luego de esto, tiene
lugar un “diseño rápido”. El diseño rápido se centra en una representación de
aquellos aspectos del
software que serán visibles al usuario (por ejemplo, entradas y formatos de las
salidas).
BIBLIOGRAFIA:
(PDF) La ingeniería de requerimientos y su importancia en el desarrollo de
proyectos de software. Available from: https://www.researchgate.net/publication/237038693_La_ingenieria_de_requerimientos_y_su_importancia_en_el_desarrollo_de_proyectos_de_software
[accessed Sep 23 2018].
Comentarios
Publicar un comentario