En esta fase se especifican a detalle los requerimientos funcionales y no funcionales correspondientes a la versión del software a desarrollar en la iteración actual, de esta manera, la especificación de requerimientos irá evolucionando con el desarrollo de cada iteración.

La especificación de requerimientos funcionales corresponde a la descripción de los casos de uso del software, en los cuales se indica la interacción entre los usuarios y las funcionalidades del software, es decir, las acciones que pueden ejecutar los usuarios en el software y las respuestas de éste ante dichas acciones. Es por ello que la especificación de requerimientos funcionales representa el principal insumo para la fase de Análisis y Diseño, así como para las fases de Codificación y Pruebas.

Es importante resaltar que los casos de uso que se especificaran en esta fase corresponden a los casos de uso planteados en el proceso de Conceptualización de Proyectos de Software Libre para definir el alcance del software.

La especificación de requerimientos no funcionales corresponde a la definición de característica o atributos de calidad del software, como por ejemplo:

• Tiempo de respuesta de las funciones de un software, referido éste al atributo eficiencia como característica de calidad, en específico a la subcaracterística utilización de recursos del software.

• Seguridad para el acceso a los datos que maneja un software, referido éste al atributo funcionalidad como característica de calidad, en específico a la subcaracterística seguridad.

• Intercambio de datos con otros software, referido éste al atributo funcionalidad como característica de calidad, en específico a la subcaracterística interoperabilidad.

• Manejo de fallas en el software, referido éste al atributo confiabilidad como característica de calidad, en específico a la subcaracterística tolerancia a fallas.

• Funcionamiento aceptable del software ante incrementos en el volumen de procesamiento. Éste corresponden al atributo eficiencia como característica de calidad, en específico a la subcaracterística desempeño.

A continuación se indican las actividades y tareas que componen esta fase.

Actividad: Especificación de requerimientos funcionales

Tarea: Describir textualmente los casos de uso correspondientes a la iteración actual.

Recomendaciones:

• La descripción textual de un caso de uso se debe realizar en lenguaje natural, y la misma debe contener la siguiente información: a) Actores: usuarios y/o sistemas que interactúan con el caso de uso. b) Condiciones de entrada (precondiciones): condiciones que se deben cumplir para poder acceder al caso de uso. c) Condiciones de salida (postcondiciones): respuesta del software al ejecutarse exitosamente el caso de uso. d) Flujo básico: lista enumerada de los pasos que ejecuta el software y los actores para llevar a cabo el caso de uso, obteniéndose así la condición de salida. e) Flujos alternativos: pasos que ejecutan los actores y el software en situaciones no comunes, por ejemplo, ingreso de datos de entrada inválidos o la omisión de datos obligatorios, así como el comportamiento del software ante dicho ingreso u omisión de datos. f) Requisitos especiales: cualquier otra información que se considere pertinente para la construcción de la función a la cual se hace referencia en el caso de uso, por ejemplo, información referida a requerimientos no funcionales.

• Los casos de uso no constituyen documentos de diseño de interfaz de usuario, por lo cual nunca debe hacerse referencia en ellos a elementos de la interfaz, tales como página principal, pantalla de ingreso o “clickear” botones (“Consejos para escribir,” 2009).

• La descripción del caso de uso debe ser hecha en forma detallada, clara y precisa, de manera que el Arquitecto de Software, el Diseñador Gráfico, los Programadores, los Probadores y los Documentadores no deban leer ningún otro documento para realizar su trabajo en relación con el software a construir (Peréz, s.f.).

• Paro los requerimientos funcionales referidos a las operaciones CRUD (crear, obtener, actualizar y borrar) que mantengan un comportamiento similar en el software, cuyas operaciones sean cortas y simples, se recomienda especificar las misma en un solo caso de uso. Este planteamiento evita especificar por separado cada una de las operaciones CRUD, lo cual disminuye el número de casos de uso del software, y, por ende, el trabajo asociado a ello (Cuesta, 2007).

Herramientas:

• Los diagramas de casos de uso y la descripción textual de los mismos pueden registrarse en la plantilla Especificación de requerimientos.

Productos:

• Especificación de requerimientos funcionales. Este documento debe contener por cada requerimiento funcional: un diagrama de caso de uso (estos diagramas están contenidos en la propuesta de desarrollo del software) y su respectiva descripción textual.

Responsables:

• Analistas.

Colaboradores:

• Usuarios y/o interesados.

---

Tarea: Validar con los usuarios la descripción textual de los casos de uso asociados a la iteración actual.

Productos:

• Especificación de requerimientos funcionales validada por los Usuarios.

Responsables:

Analistas y Usuarios.

---

Tarea: Discutir con el Equipo de Desarrollo la descripción textual de los casos de uso asociados a la iteración actual.

Recomendaciones:

• Dado que la descripción textual de los requerimientos funcionales constituye el insumo principal que se utiliza para llevar a cabo las actividades de las fases de Análisis y Diseño, Codificación y Pruebas, se recomienda la discusión de esta descripción con los demás integrantes del Equipo de Desarrollo. Ello permite a su vez identificar posibles ambigüedades en dichas descripciones.

Productos:

• Especificación de requerimientos funcionales validada por el Equipo de Desarrollo.

Responsables:

• Analistas y demás miembros del Equipo de Desarrollo.

---

Actividad: Especificación de requerimientos no funcionales

Tarea: Definir con los usuarios los requerimientos no funcionales que debe cumplir el software.

Recomendaciones:

• Los requerimientos no funcionales representan un insumo muy importante para la definición de la arquitectura del software, pues ellos implican aspectos que debe contemplar el software en términos de seguridad, tiempos de respuesta, interfaz de usuario, entre otros, que son determinantes para seleccionar una arquitectura que permita cumplir con tales requerimientos.

• Durante el proceso de Conceptualización de Proyectos de Software Libre se levanta información que puede servir de insumo para la definición formal de requerimientos no funcionales.

• Estos requerimientos pueden ser definidos en la primera iteración y pueden ser refinados en iteraciones posteriores.

Herramientas:

• La especificación de los requerimientos no funcionales puede registrarse en una plantilla.

Productos:

• Especificación de requerimientos no funcionales.

Responsables:

• Analistas y Usuarios.