Ingeniería de Requisitos
¿Qué es un requerimiento/requisito?
Normalmente, un tema de la Ingeniería de Software tiene
diferentes significados. De las muchas definiciones que existen para
requerimiento, a continuación se presenta la definición que aparece en el
glosario de la IEEE. (Richard ,1997) .
(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (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. (3) Una representación documentada de una condición o capacidad como en (1) o (2). (Richard , 1997)
Características de los requerimientos
Los requerimientos deben especificarse antes de intentar
comenzar la construcción del producto, sin ellos no podrá ser posible llevar a
cabo las etapas de diseño y construcción correctamente. Los mismos pueden verse
como una declaración abstracta de alto nivel de un servicio que el sistema debe
proporcionar, como una definición matemática detallada y formal. Los requisitos
cumplen una doble función ya que son la base para una oferta de contrato, por
lo tanto deben estar abiertos a la interpretación. Además son la base para
redactar el contrato en sí mismo.
Los requisitos una vez establecidos y documentados, sufren
cambios continuos, en este sentido, no se trata la obtención ni el análisis de
los mismos, se trata de su gestión, es decir, el seguimiento respecto a los
cambios que se generan durante el ciclo de vida del proyecto y las herramientas
de gestión de requisitos que auxilian y/o automatizan estas tareas. El uso de
herramientas para auxiliar la gestión de requisitos se ha convertido en un
aspecto importante de la Ingeniería de Sistemas y el diseño. Considerando el
tamaño y la complejidad del desarrollo, las herramientas vienen siendo algo
esencial. Las herramientas que los gestores de requisitos utilizan para
automatizar los procesos de Ingeniería de Requisitos han disminuido el trabajo
duro en el mantenimiento de requisitos, añadiendo beneficios significativos al
reducir errores. (Loucopoulos, 1995).
Tipos de requisitos
Los requerimientos pueden dividirse en varios tipos dentro
de ellos, se hará referencia a los siguientes:
Declaraciones en lenguaje natural y en diversos diagramas de
los servicios del sistema y de las restricciones bajo las que debe operar.
1.- El sistema debe permitir representar y acceder a
archivos externos creados por otras herramientas.
Requisitos del sistema
Un documento estructurado que determina las descripciones
detalladas de los servicios de sistema. Escrito como contrato entre el cliente
y el contratista.
1.- El usuario deberá poder definir el tipo de un nuevo
archivo externo.
Requisitos funcionales
Declaración de los servicios que el sistema debe proporcionar, cómo debe reaccionar a una entrada particular y cómo se debe comportar ante situaciones particulares. Describen la funcionalidad del sistema, y dependen del tipo de software, del sistema a desarrollar y de los usuarios del mismo. Por lo general se describen mejor a través del modelo de Casos de uso y los Casos de uso como tal. Por lo tanto los requerimientos funcionales especifican el comportamiento de entrada y salida del sistema y surgen de la razón fundamental de la existencia del producto.
Requisitos no funcionales
Los requerimientos no funcionales son propiedades o
cualidades que el producto debe tener. Restricciones que afectan a los
servicios o funciones del sistema, tales como restricciones de tiempo, sobre el
proceso de desarrollo, estándares, etc.
Gestión de Requisitos. Principales características
La Gestión de Requisitos es un componente vital en el
desarrollo de un proyecto software ya que es una de las actividades de la
Ingeniería de Requisitos más importantes. Los requisitos se inician cuando
empieza un proyecto en las etapas de análisis y especificación de requisitos,
posteriormente, dichos requisitos en el ciclo de vida de un proyecto pueden ser
modificados por lo que se establece el concepto de Gestión de Requisitos, que
es el tratamiento y control de las actualizaciones y cambios a los mismos.
Debido a que un proyecto informático es susceptible de cambios, habría que
proceder a su actualización o a la incorporación de nuevas funcionalidades o
eliminar otras, esto obliga a mantener controlado y documentado el producto.
Los cambios de requisitos deben ser gestionados para asegurar que la calidad de
los mismos se mantenga, los problemas suscitados por los cambios de requisitos
podrían incurrir en altos costos, siendo el requisito factor crítico de riesgo.
Más formalmente el Manejo de Requisitos es una forma
sistemática de descubrir, organizar y documentar los requisitos del sistema.
Además es el proceso que establece y mantiene un consenso entre el cliente y el
grupo del proyecto en el cambio de los requisitos del sistema.
El término Gestión de Requisitos incluye:
Estándares para escribir requisitos de alta calidad:
1. - Análisis de documentación
Consiste en obtener la información sobre los requerimientos
funcionales y requerimientos no funcionales de software a partir de documentos
que ya están elaborados.
Es útil cuando los expertos en la materia no están
disponibles para ser entrevistados o ya no forman parte de la organización.
Utiliza la documentación que sea relevante al requerimiento
que se está levantando.
Ejemplos de documentación: Planes de negocio, actas de
constitución de proyecto, reglas de negocio, contratos, definiciones de
alcance, memorándums, correos electrónicos, documentos de entrenamiento, entre
otros.
2.- Observación
Consiste en estudiar el entorno de trabajo de los usuarios,
clientes e interesados de proyecto (Stakeholders).
Es una técnica útil cuando se está documentando la situación
actual de procesos de negocio.
Puede ser de dos tipos, pasiva o activa.
En observación pasiva, el observador no hace preguntas,
limitándose solo a tomar notas y a no interferir en el desempeño normal de las
operaciones.
En observación activa, el observador puede conversar con el usuario.
3.- Entrevistas
Se realizan con los usuarios o interesados clave.
Direccionan al usuario hacia aspectos específicos del
requerimiento a levantar.
Son útiles para obtener y documentar información detallada
sobre los requerimientos y sus niveles de granularidad.
Pueden ser entrevistas formales o informales.
Una clave es mantenerse enfocado en los objetivos de la
entrevista.
Las preguntas abiertas son útiles para identificar
información faltante.
Las preguntas cerradas son útiles para confirmar y validar
información.
El éxito de las entrevistas depende del grado de
conocimiento del entrevistador y entrevistado, disposición del entrevistado de
suministrar información, buena documentación de la discusión y en definitiva de
una buena relación entre las partes.
4.- Encuestas o cuestionarios
Diseñado por Freepik
Es una técnica útil para recopilar eficientemente los
requerimientos de muchas personas.
La clave para el éxito es que tengan un propósito y
audiencia claramente definida, establecer fechas topes para llenar la encuesta,
con preguntas claras y concisas.
Deben enfocarse en los objetivos de negocio que se necesitan
identificar.
Pueden apoyarse con entrevistas de seguimiento con usuarios
individuales.
Pueden contener tanto preguntas cerradas como preguntas
abiertas.
5.- Mesas de trabajo (Workshops)
Es una técnica efectiva para obtener información rápidamente
de varias personas.
Es recomendable tener una agenda predefinida y
preseleccionar a los participantes, siguiendo buenas prácticas para reuniones
efectivas.
Se puede utilizar un facilitador neutral y un transcriptor
(que no sea el mismo facilitador).
Se puede utilizar un material común sobre el cual enfocar la
atención y conversar, por ejemplo una presentación con un desglose del proceso
que se está estudiando o un flujograma.
Se pueden combinar con otras técnicas como pueden ser las entrevistas y cuestionarios.
6.- Tormenta de ideas
Diseñado por Freepik
Es una sesión de trabajo estructurada orientada para obtener
la mayor cantidad de ideas posibles.
Es recomendable limitarlas en el tiempo, utilizar ayudas
visuales y designar un facilitador.
Las reglas son importantes, por ejemplo los criterios para
evaluar ideas y asignarles un puntaje, no permitir las críticas a las ideas y
limitar el tiempo de discusión.
En una primera fase, se deben identificar la mayor cantidad
de ideas, para luego evaluarlas. Todas las ideas deben ser consideradas y deben
limitarse que una idea se le ahogue o critique antes de tener tiempo de
desarrollarla.
7.- Historia del usuario
Las historias de usuario, son una aproximación simple al
levantamiento de requerimientos de software, en la cual la conversación pasa a
ser más importante que la formalización de requerimientos escritos.
Es recomendable que sean escritas por el mismo cliente o
interesado (con apoyo del facilitador si es necesario), con énfasis en las
funcionalidades que el sistema deberá realizar.
Al redactar una historia de usuario deben tenerse en cuenta
describir el Rol, la funcionalidad y el resultado esperado de la aplicación en
una frase corta.
Las historias de usuario son una de las técnicas más
difundidas para levantar requerimientos de software en metodologías ágiles.
Técnica JAD.
Joint Application
Design (JAD) El Diseño de Aplicación Conjunta es una técnica o proceso usado en
el Ciclo de Vida del Desarrollo de Sistemas para elicitar requerimientos de
Sistemas de información para una compañía. Le técnica JAD también incluye
enfoques para mejorar la participación de los usuarios, agilizar el desarrollo
y mejorar la calidad de las especificaciones de requerimientos. Consiste en un
taller donde los trabajadores del conocimiento y especialistas de TI se reúnen,
a veces por varios días, para definir y revisar los requerimientos del negocio
para el sistema. Sus principales ventajas son la optimización del tiempo,
organización y resolución de conflictos
intrínsecos al ámbito de la gestión.
Fundamentos del JAD.
El proceso de JAD se basa en cuatro ideas simples:
· La gente que
hace un trabajo tiene la mejor comprensión de ese trabajo
· La gente entrenada en Tecnologías de la
Información tiene la mejor comprensión de las posibilidades de esas
tecnologías.
· Los sistemas
de información y los procesos del negocio raramente existen en forma aislada.
Más bien trascienden los límites de cualquier sistema u oficina y afectan el
trabajo en departamentos relacionados. La gente que trabaja en estas áreas
relacionadas tiene una percepción valiosa del papel del sistema dentro de una
comunidad más amplia.
· Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales. El documento de requerimientos de software, es el lugar donde se da descripción a las características y requisitos de un software, producto, programa o conjunto de programas. Los requisitos se expresan en lenguaje natural, sin consideraciones ni términos técnicos.
Comentarios
Publicar un comentario