Ingeniería de Requerimientos.
El término Requirements Engineering es acuñado en 1977 a través de un reporte técnico por parte del TRW Defense and Space Systems Group en Estados Unidos, el cual hace énfasis en la problemática de la “pobre” definición de los requerimientos de software y el alto costo que esto implica en los proyectos.
Investigadores
en el área de software comienzan a formular metodologías, herramientas y
técnicas para la definición de requerimientos. Esta comunidad va tomando fuerza
y es en 1993 cuando surge el primer simposio en Ingeniería de Requerimientos
(RE, por sus siglas en inglés).
Anualmente
se realiza una conferencia para discutir los problemas relacionados con este
tema. La edición número 25 se llevará a cabo este año en Lisboa, Portugal, con
la participación de profesionales de la industria y reconocidos autores de
libros sobre ingeniería de software, como Ian Sommerville.
Las Metas de RE
La
ingeniería de requerimientos (RE) es un proceso sistemático y disciplinado para
la especificación y administración de éstos con las siguientes metas:
Entender el problema por el que surge la necesidad del software.
Conocer
los requerimientos relevantes y lograr un consenso entre los stakeholders
(personas interesadas en el software que toman decisiones sobre los requerimientos).
Documentar
las necesidades de los stakeholders.
La
fase de definición de requerimientos es sumamente importante, ya que se
necesita mucha disposición por parte del cliente o usuario, y de paciencia y
creatividad por parte de los analistas para lograr buenos resultados.
INGENIERIA DE REQUERIMIENTOS
Ingeniería
de Requerimientos
El
término Requirements Engineering es acuñado en 1977 a través de un reporte
técnico por parte del TRW Defense and Space Systems Group en Estados Unidos, el
cual hace énfasis en la problemática de la “pobre” definición de los
requerimientos de software y el alto costo que esto implica en los proyectos.
Investigadores
en el área de software comienzan a formular metodologías, herramientas y
técnicas para la definición de requerimientos. Esta comunidad va tomando fuerza
y es en 1993 cuando surge el primer simposio en Ingeniería de Requerimientos
(RE, por sus siglas en inglés).
Anualmente
se realiza una conferencia para discutir los problemas relacionados con este
tema. La edición número 25 se llevará a cabo este año en Lisboa, Portugal, con
la participación de profesionales de la industria y reconocidos autores de
libros sobre ingeniería de software, como Ian Sommerville.
Las
Metas de RE
La
ingeniería de requerimientos (RE) es un proceso sistemático y disciplinado para
la especificación y administración de éstos con las siguientes metas:
Entender
el problema por el que surge la necesidad del software.
Conocer
los requerimientos relevantes y lograr un consenso entre los stakeholders
(personas interesadas en el software que toman decisiones sobre los requerimientos).
Documentar
las necesidades de los stakeholders.
La
fase de definición de requerimientos es sumamente importante, ya que se
necesita mucha disposición por parte del cliente o usuario, y de paciencia y
creatividad por parte de los analistas para lograr buenos resultados.
4
pasos al definir los requerimientos
Las
actividades principales del proceso de definición de requerimientos pueden
dividirse en cuatro:
1
Extracción
Consiste
en una comunicación intensa con el cliente/usuario para establecer claramente
el problema que requiere una solución.
Diferentes
técnicas deben ser usadas en combinación para obtener la mayor cantidad de
información.
Algunas
técnicas: entrevistas, cuestionarios, prototipos (en papel) y sesiones de
lluvia de ideas, entre otros.
Inicia
una vez que se cuenta con la información obtenida.
Usa
técnicas de modelado y lenguajes como UML y BPMN para plasmar conceptos que son
parte del problema y que formarán parte de la solución.
Lo
ideal es que haya una iteración de las primeras dos actividades antes de pasar
a la especificación, aunque pueden repetirse en cualquier momento.
3
Especificación
El
objetivo es documentar los requerimientos en formatos establecidos.
Los
modelos generados en la etapa de análisis también forman parte de la
especificación.
Documentos
con el listado de requerimientos funcionales, no funcionales, reglas de
negocio, casos de uso y diagramas de estados y clases, por ejemplo, conforman
el paquete que especifica el software a ser construido.
4
Validación y verificación
La
información que ha sido documentada en la especificación debe ser validada por
el cliente, de forma que esté de acuerdo con lo establecido.
En
caso de que no esté completamente satisfecho, el ingeniero de requerimientos
debe negociar posibles extensiones.
La
parte de verificación sucede una vez que se tiene el software en
funcionamiento, es decir, hay una estrecha relación entre la verificación y las
pruebas, ya que debe confirmarse que el software realiza lo especificado en los
documentos.
La
administración de requerimientos es ortogonal a las actividades anteriores y
comprende cualquier medida que sea necesaria para estructurar los
requerimientos, mantener la consistencia después de los cambios y asegurar la
implementación.
Todos
los integrantes del equipo de desarrollo deben aportar sus conocimientos y
experiencia en cada actividad del proceso de levantamiento. Es cierto que un
ingeniero de requerimientos tendrá mayor dominio durante esta fase, pero es
importante que cada integrante opine y contribuya con preguntas, dudas y
cuestionamientos para presentarlas al cliente/usuario.
Cada
reunión con el cliente es valiosa y hay que tomar nota de todo lo que menciona.
Todo esto debe ser interpretado y plasmado en diagramas, prototipos o alguna
otra representación gráfica que permita al equipo ir analizando y consolidando
las ideas, a fin de aterrizarlas en una solución que sea factible.
El
proceso de levantamiento de requerimientos es iterativo y debe repetirse
cuantas veces sean necesarias para refinar aquellos que no son claros, están
incompletos o que no han sido validados por el cliente. Pero es cierto que los
factores tiempo y presupuesto determinan el momento en que la fase de
requerimientos acaba para comenzar el desarrollo. Es por esta razón que la
negociación con el cliente tiene que iniciar desde que el equipo ha
identificado los requerimientos esenciales y los que pueden omitirse o
implementarse en versiones posteriores.
Los 4 pasos para definir requerimientos.
Las actividades principales del proceso de definición de requerimientos pueden dividirse en cuatro:
Extracción
Consiste en una comunicación intensa con el cliente/usuario para establecer claramente el problema que requiere una solución.
Diferentes técnicas deben ser usadas en combinación para obtener la mayor cantidad de información.
Algunas técnicas: entrevistas, cuestionarios, prototipos (en papel) y sesiones de lluvia de ideas, entre otros.
Análisis
Inicia una vez que se cuenta con la información obtenida.
Usa técnicas de modelado y lenguajes como UML y BPMN para plasmar conceptos que son parte del problema y que formarán parte de la solución.
Lo ideal es que haya una iteración de las primeras dos actividades antes de pasar a la especificación, aunque pueden repetirse en cualquier momento.
Especificación
El objetivo es documentar los requerimientos en formatos establecidos.
Los modelos generados en la etapa de análisis también forman parte de la especificación.
Documentos con el listado de requerimientos funcionales, no funcionales, reglas de negocio, casos de uso y diagramas de estados y clases, por ejemplo, conforman el paquete que especifica el software a ser construido.
Validación y verificación
La información que ha sido documentada en la especificación debe ser validada por el cliente, de forma que esté de acuerdo con lo establecido.
En caso de que no esté completamente satisfecho, el ingeniero de requerimientos debe negociar posibles extensiones.
La parte de verificación sucede una vez que se tiene el software en funcionamiento, es decir, hay una estrecha relación entre la verificación y las pruebas, ya que debe confirmarse que el software realiza lo especificado en los documentos.
La administración de requerimientos es ortogonal a las actividades anteriores y comprende cualquier medida que sea necesaria para estructurar los requerimientos, mantener la consistencia después de los cambios y asegurar la implementación.
Todos los integrantes del equipo de desarrollo deben aportar sus conocimientos y experiencia en cada actividad del proceso de levantamiento. Es cierto que un ingeniero de requerimientos tendrá mayor dominio durante esta fase, pero es importante que cada integrante opine y contribuya con preguntas, dudas y cuestionamientos para presentarlas al cliente/usuario.
Cada reunión con el cliente es valiosa y hay que tomar nota de todo lo que menciona. Todo esto debe ser interpretado y plasmado en diagramas, prototipos o alguna otra representación gráfica que permita al equipo ir analizando y consolidando las ideas, a fin de aterrizarlas en una solución que sea factible.
El proceso de levantamiento de requerimientos es iterativo y debe repetirse cuantas veces sean necesarias para refinar aquellos que no son claros, están incompletos o que no han sido validados por el cliente. Pero es cierto que los factores tiempo y presupuesto determinan el momento en que la fase de requerimientos acaba para comenzar el desarrollo. Es por esta razón que la negociación con el cliente tiene que iniciar desde que el equipo ha identificado los requerimientos esenciales y los que pueden omitirse o implementarse en versiones posteriores.
¿Cómo redactar los requerimientos de un sistema?
- El Sistema debe proveer…
- El Sistema debe hacer cumplir con…
- El Sistema debe tener una interfaz con…