Ingeniería de requerimientos

De acuerdo con Sommerville (2011) los requerimientos de un sistema de software son las descripciones de qué es lo que el sistema debe hacer, los servicios que debe proveer y las restricciones de operación. Estos requerimientos reflejan las necesidades de los clientes por un sistema.

Al proceso de encontrar, analizar, documenta, y revisar estos servicios y restricciones se le llama Ingeniería de Requerimientos.

Requerimientos de Software

Diferentes personas pueden hablar de una sola cosa en cuestión, como un requerimiento de usuario, tecnológico, de negocio, funcional, de sistema o de producto. Sin embargo, la definición de requerimiento, para un cliente, puede sonar como un producto de alto nivel para los desarrolladores.

La noción de requerimientos, para los desarrollados, puede referirse al diseño detallado de una interfaz de usuario para el usuario. Esta discrepancia entre términos nos lleva a problemas frustrantes de comunicación. Un aspecto clave es que los requerimientos deben ser documentados, es decir, si por alguna razón una parte del desarrollo del proyecto es cambiada será algo molesto para el cliente y éste pedirá que se le expliquen a detalle los cambios realizados.

El consultor Lawrence (2006) ha señalado que un requerimiento es “cualquier cosa que dirige las opciones del diseño”

Por otra pate, el glosario estándar de la IEEE, de terminología de ingeniería de software, define un requerimiento como:

A) Una condición o capacidad necesitada por un usuario par resolver un problema o alcanzar un objetivo.

B) Una condición o capacidad que debe encontrarse en un sistema, o un componente de un sistema, para satisfacer un contrato, un estándar, una especificación o cualquier otro documento impuesto formalmente.

c) Una representación documentada de una condición o capacidad.

Somerville y Sawyer (1997) han manifestado que “los requerimientos son especificaciones de lo que debe ser implementado. Son descripciones que dicen como debe comportarse el sistema, o una propiedad o atributo de un sistema. Pueden se restricciones sobre el proceso de desarrollo del sistema”.

Las especificaciones de requerimientos deben ser:

Completas. Ningún requerimiento o información importante debe faltar. Los requisitos faltantes son muy difíciles de identificar porque simplemente no están ahi. Una forma de identificar los requerimientos faltantes es basándonos en las funciones de los usuarios y no en las funciones del sistema.

Consistentes. Los requerimientos consistentes no entran en conflicto con otros requerimientos del mismo tipo, con niveles mas altos de reglas de negocios o con requerimientos de los usuarios. Los conflictos entre requerimientos deben ser resueltos antes de iniciar el proceso de desarrollo.

Modificables. Debemos ser capaces, en todo momento, de revisar las especificaciones de requerimientos de software, para mantener un historial de los cambios realizados, esto quiere decir que cada requerimiento debe ser especificado de manera independiente y aislada de los demás, de tal forma que podamos referirnos all de manera precisa.

Rastreables. Un requerimiento rastreaba puede se ligado hacia atrás (hacia su origen), hacia adelante (hacia sus elementos de diseño), hacia el código que lo implementa y hacia los casos de prueba que verifican que su implementación es correcta.

Los requerimientos rastreables son etiquetados con identificadores únicos, por ello, hay que evitar incluir mas de un requerimiento en uno solo.

Buenas prácticas de Ingeniería de Requerimientos

De acuerdo con Wiegers (2003) el concepto de lo que es una buena práctica puede ser rebatible, pues no jaula un sólo parámetro que determine qué es lo mejor.

Una manera de determinar las buenas prácticas de Ingeniería de requerimientos es juntando a un grupo de expertos o investigadores de la industria, para analizar proyectos de diferentes organizaciones. Las prácticas con mejores resultados son llamadas buenas prácticas.

Administración de Riesgos

Mucha gente tiene dificultades para describir sus necesidades, pues no tienen algo tangible frente a ellos, además de que criticar es mucho mas fácil que crear. Los prototipos de software hacen los requerimientos más reales, facilitan la identificación de casos de uso y eliminan confusiones en el entendimiento de los requerimientos (Wiegers, 2003).

Aun aplicando las prácticas de desarrollo de requerimientos algunas porciones de los requerimientos pueden estar incompletas, inciertas o no muy claras para los clientes o los desarrolladores. Es mucho más factible que un usuario interactúa con un prototipo a que se ponga a leer una especificación formal de requerimientos.

Los prototipos tienen varios significados y los participantes de una actividad de prototipos tienen diferentes expectativas. 

Los tres principales propósitos de los prototipos son:

- Clarificar y completar los requerimientos 

- Explorar alternativas de diseño

- Crecer hacia el producto final

Mejorando el proceso de requerimientos

De acuerdo con Wiegers (2003) los usuarios, por lo general, se enfocan en especificar sus requerimientos funcionales o de comportamiento, es decir, las cosas que el software les debe permitir hacer; pero un software exitoso hace mas que sólo ofrecer la funcionalidad deseada.

Los usuarios tienen expectativas en cuanto a:

- Qué tan bien funcionará el software

- Qué tan fácil será utilizarlo

- Qué tan rápido se ejecutará

- Qué tan seguido fallará

- Cómo manejarán situaciones no previstas

Todas estas características juntas son comúnmente conocidas como atributos de calidad de software, o factores de calidad, esto es parte de los requerimientos no funcionales. En los sistemas reales, alcanzar los requerimientos no funcionales puede ser más importante que cubrir los requerimientos funcionales, para la determinación de la percepción de éxito o fracaso.

Elicitación de requerimientos 

Wiegers (2003) señala que el proceso de licitación de requerimientos puede llevarse a cabo a través de los siguientes puntos.

1. Definir un proceso de desarrollo de requerimientos. Hay que documentar los pasos que la organización sigue para felicitar, analizar, especificar, y validar requerimientos. Hay que proveer ayuda en cómo llevar a cabo los pasos claves, esto ayudaría a los analistas a hacer un trabajo consistente, también hará mucho más fácil el planear las tareas de desarrollo de cada requerimiento del proyecto.

2. Escribir una visión y alcance del documento. La visión y alcance del documento contiene los requerimientos del negocio del producto. El enunciado de la visión da todos los lineamientos, es decir, un entendimiento común de los objetivos del producto. Por su parte, el alcance define los limites entre qué está contemplado y qué está fuera de nuestro producto.

3. Identificar las clases de usuarios y sus características. Hay que identificar los diferentes grupos de usuarios en una comunidad, o los grupos de usuarios para nuestro producto, éstos pueden cambiar en: frecuencia de uso, características usadas, niveles de privilegios o niveles de habilidad.

4. Seleccionar un producto “campeón” para cada clase de usuarios. Identificar al menos una persona que pueda servir de manera adecuada como el vocero del cliente, para cada clase de usuarios. El producto campeón presenta las necesidades de la clase de usuarios.

5. Establecer grupos de interés de usuarios típicos. Es necesario crear grupos de usuarios representativos de las versiones previas del producto, o de productos similares.

6. Trabajar con representantes de los usuarios para identificar casos. Esta actividad implica explorar con los representantes de usuarios las tareas que necesitan realizar con el software, estudiar los casos de uso, comentar las interacciones entre los usuarios y determinar el sistema que les permitirá completar cada una de sus tareas.

7. Identificar eventos del sistema y respuestas. Hay que crear un listado de los eventos externos que el sistema puede experimentar y reconocer cuál es la respuesta esperada a estos eventos.

8. Mantener talleres de elicitación que permitan la colaboración entre los analistas y los clientes. Esta es una forma muy poderosa de explorar las necesidades de los usuarios y de bosquejar documentos de requerimientos.

9. Observar a los usuarios llevando a cabo sus trabajos. Observar a los usuarios desarrollando sus tareas establece un contexto para el uso potencial de una nueva aplicación , de esta manera se pueden obtener diagramas de flujo de trabajo y diagramas de flujo de información.

10. Examinar los reportes de problemas de sistemas actuales, para generar ideas de requerimientos. Los reportes de problemas y las peticiones de mejora, por parte de los cliente, son una fuente rica de ideas para incluir nuevas características en una nueva versión o en un nuevo producto.

11. Reusar requerimentos entre proyectos. Si los clientes solicitan funcionalidades similares a las que ya están presentes en un producto existente se debería analizar si los requerimientos son lo suficientemente flexibles para permitir ser reutilizados o adaptados con los componentes existentes.

El proceso de documentación de análisis de requerimientos 

Wiegers (2003) ha establecido que el resultado del desarrollo de requerimientos es un acuerdo documentado entre los clientes y los desarrolladores, acerca del producto que se va a construir. Los requerimientos funcionales y no funcionales, detallados del producto, residen en una especificación de requerimientos de software (SRS).

Podemos representar los requerimientos de software de diferentes maneras, revisemos algunas:

1. Documentos que utilizan un lenguaje natural, escrito cuidadosamente y bien estructurado.

2. Modelos gráficos que ilustran los procesos transformaciones, los estados del sistema y las transacciones entre ellos.

3. Especificaciones formales que definen los requerimientos, utilizando lenguajes matemáticos, lógicos, formales y precisos.

Las especificaciones de requerimientos de software, con frecuencia son llamadas “especificaciones funcionales”, “especificaciones de producto”, “documento de requerimientos”, o “especificaciones del sistema”.

El SRS (Software Requirements Specification) declara con precisión las funciones y capacidades que un sistema debe proveer, así como las restricciones que debe respetar. El SRS es la base para toda la planeación, diseño y programación de proyectos.

Revisión, verificación y Validación

Muchos desarrolladores de software han experimentado la frustración de tener que implementar requerimientos ambiguos o incompletos. Si los desarrolladores no pueden obtener la información que necesitan entonces tienen que hacer sus propias interpretaciones, lo cual no es siempre correcto.

La validación de requerimientos pretende asegurar los siguientes puntos:

1. El SRS describe de manera correcta las capacidades deseadas del sistema y las características que cubrirán las necesidades de los usuarios.

2. Los requerimientos de software fueron correctamente derivados de los requerimientos del sistema, reglas de negocios y otra fuentes.

3. Los requerimientos están completos y son de alta calidad.

4. Las representaciones de los requerimientos son consistentes unas con otras.

5. Los requerimientos proveen una base adecuada para proceder con el diseño y la construcción.

Técnicas de elicitación

Los ingenieros de requerimientos pueden necesitar de diferentes técnicas para obtener información. Yes y Zave (1980) sugiere que hay tres formas fundamentales de estructurar las técnicas de elicitación que brindarán a los ingenieros de requerimientos la obtención de la información deseada:

1. Particionamiento. Se refiere a la organización del conocimiento en relaciones agregadas, donde el conocimiento de los requerimientos está descrito en términos de sus partes.

2. Abstracción. Es la organización del conocimiento, de acuerdo con relaciones generales específicas. El Conocimiento de los requerimientos es descrito relacionando instancias específicas a estructuras abstractas.

3. Proyección. Es la organización del conocimiento desde diferentes puntos de vista. Diversas fuentes contribuyen con diferente información sobre el sistema.

Modelos de análisis

El análisis es un intermediario de comunicación, entre las vagas nociones del cliente y las claras especificaciones que guion al equipo de trabajo de software. El analista debe entender los objetivos de los usuarios para el nuevo sistema, de esta forma podrá definir los nuevos requerimientos funcionales y de calidad.

El trabajo como analista inicia cuando ayudamos al representante de la empresa, product manager o marketing manager, a definir los requerimientos de negocio del proyecto.

Los requerimientos de un producto de software no están por ahí esperando a que algún analista los recolecte. Un analista pro-activo ayuda a los usuarios a articular las capacidades del sistema que necesitan para alcanzar sus objetivos laborales.

Algunas técnicas para obtener información de análisis son las siguientes:

Entrevistas

Talleres de requerimientos 

Encuestas

Visitas al cliente en su lugar de trabajo

Verificación del proceso de negocio

Verificación del flujo de trabajo y flujo de tareas

Lista de eventos

Atributos de la calidad de software

La mayoría de los proyectos necesitan considerar cuidadosamente características que podemos denominar como atributos de calidad.

Si los desarrolladores identifican cuáles de estas características son cruciales para el desarrollo del proyecto entonces podrán proponer una arquitectura, diseño y enfoque de programación para alcanzar metas específicas de calidad.

Otro enfoque consiste en separa las características visibles que son importantes, de las características significantes a nivel técnico, las cuales interviene indirectamente en la satisfacción del cliente.

Algunos elementos que son evaluados por los usuarios y regulan la calidad del software son los siguientes:

Disponibilidad

Eficiencia 

Flexibilidad

Integridad

Interoperabilidad

Confiabilidad

Robustez

Usabilidad

Mantenibilidad

Portabilidad

Reusabilidad

Facilidad de prueba

Reducción del riesgo por prototipos

Una manera de reducir los riesgos al realizar productos es por medio de los prototipos. Existen 4 prototipos básicos: 

1. Prototipo horizontal. Es llamado horizontal porque no se mete en todas las capas de la arquitectura o en detalles del sistema, en lugar de eso muestra solamente una porción de la interfaz del usuario. Este tipo de prototipos nos permite explorar los comportamientos específicos del sistema, con el objetivo de refinar los requerimientos.

2. Prototipo vertical. Un prototipo vertical trabaja en todos los niveles de la implementación del sistema. Hay que desarrollar prototipos verticales cuando no estemos seguros de que el enfoque de una arquitectura propuesta es factible, cuando queramos optimizar algoritmos, evaluar un esquema propuesto de base de datos o probar requerimientos típicos de tiempo.

3. Prototipos desechables. Hay que construir un prototipo desechable para resolver preguntas, resolver cosas inciertas y mejorar la calidad de los requerimientos.

4. Prototipo evolutivo. A diferençia del prototipo desechable, éste provee una arquitectura sólida. Los prototipos evolutivos son un componente del modelo de ciclo de vida del desarrollo del software orientado a objetos.

Estableciendo la prioridad de los requerimientos

Cuando las expectativas del cliente son altas y los tiempos son cortos necesitamos asegurarnos que el producto cumpla la funcionalidad más importante tan pronto como sea posible. 

Establecer prioridades es una forma de lidiar con las demandas competitivas para recursos limitados.

Establecer la prioridad relativa de cada característica nos permite planear la construcción del software para proveer el valor mas alto al costo más bajo.

Los componentes principales en el proceso de asignación de prioridades incluyen: 

1. Al project manager porque es quien lidera el proceso, resuelve conflictos y ajusta la cooperación de otros participantes, si es necesario.

2. A los representantes de los cliente porque son quienes asignan tasas de beneficios y penalizaciones.

3. A los representantes de los desarrolladores porque actúan como los líderes técnicos de equipos.

Verificando la calidad de los requerimientos

Para verificar la calidad de los requerimientos se puede llevar a cabo una revisión de los mismos.

Los documentos de revisión de requerimientos son una técnica poderosa para identificar requerimientos ambiguos o no confiables, requerimientos que no han sido definidos de manera clara o que pueden dar origen a problemas.

Las revisiones informales son muy útiles para informar a otras personas acerca del producto y para recolectar retroalimentación no estructurada. Los enfoques de revisiones informales pueden incluir:

A) Preguntar a un colega qué opina.

B) Pedir que se le dé un vistazo a nuestro trabajo

C) Invitar a varios colegas para examinar el trabajo de manera concurrente.

D) Solicitar comentarios.

Por otro lado estaño las revisiones formales, las cuales permiten elaborar un reporte final acerca de la viabilidad de un producto. 

La mejor forma de elaborar una revisión formal es por medio de inspecciones.  Si realmente queremos maximizar la calidad de nuestro software un equipo de expertos debe inspeccionar cada documento de requerimientos que se genera.

Referencias

Lawrence B. (1996). Unresolved Ambiguity.

Sommerville, I. (2011). Software Engineering

Sommerville, I. Y Sawyer, P. (1997). Requirements engineering: A god practice guide.

Wiegers, K. (2003). Software requirements