Especificación de requerimientos

Especificación de requerimientos
La especificación de requerimientos de software (SRS: Software Requirement
Specification) contiene una descripción completa del comportamiento externo del
software. El SRS son las especificaciones para un producto de software en particular,
programa o conjunto de programas que realizan ciertas funciones en un determinado
entorno. Deben especificarse tanto requerimientos funcionales como no funcionales.

Una alternativa es completar el análisis del problema y luego escribir el SRS. Otra, es ir
descomponiéndolo e ir escribiendo la sección correspondiente en el medida que se va
avanzando.

El documento SRS puede ser llevado a cabo por personal representativo del proveedor, es
decir, el desarrollador del producto, o podría ser realizado por el usuario o potencial
cliente. Lo recomendable es que fuera con la participación de ambos partes.

Los aspectos básicos que deben incluir el SRS son

- Funcionalidad: qué debe hacer el software.

- Interfaces externas: cómo interactúa con usuarios, hardware y otros sistemas.
- Rendimiento: velocidad, tiempos de respuesta, recuperación, etc.
- Atributos: portabilidad, seguridad, exactitud, etc.
- Restricciones impuestas al diseño: lenguajes, plataformas, etc.

También es importante remarcar que en el SRS no debe incluir:

- Requerimientos referentes al proyecto, como por ejemplo: costos, cronogramas de

tiempos, fechas de conclusión, etc.
- Diseños: deben ser excluidos porque tienen audiencias diferentes, y particionar la
documentación.
- Planes de aseguramiento del producto, como por ejemplo: plan de administración
de configuraciones, plan de pruebas, etc.

La especificación de requerimientos, algunas veces, puede servir como base para un

pedido de cotización a distintos proveedores, en cuyo caso no se detalla tanto cada
requerimiento, sino que se describe en forma más general, para poder abarcar más
alternativas disponibles en el mercado.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 1

Tradicionalmente, esta especificación fue considerada igual a la especificación funcional,
con lo cual dejaba de lado los objetivos, los requerimientos no funcionales y las
restricciones de desarrollo. Existe un estándar generado para la especificación de
requerimientos de software (se recomiendo leerlo): IEEE Std. 830 – 1998.

Si bien es probable que en el ámbito laboral no se lleve a cabo el estándar tal como lo
indica la IEEE, es habitual que las organizaciones se basen en él y hagan una adaptación
acorde a sus necesidades.

Propósito de la cuantificación y tipos de cuantificación

En toda etapa de requerimientos, además de saber qué tenemos que hacer, debemos
saber cuánto tenemos que hacer. Esto se debe a que un mismo problema, con distintos
volúmenes, lleva a soluciones distintas.

Los volúmenes no siempre son un problema, pero para saber si lo son o no, deben
analizarse. Por ejemplo: si mi sistema procesa autorizaciones de compras para tarjetas de
crédito, diseñar una solución para un pico de 20 autorizaciones por día, 500
autorizaciones por hora o 5000 autorizaciones por hora, no será lo mismo.

El propósito de la cuantificación es especificar para los requerimientos estáticos y/o

dinámicos vinculados al software o a la interacción humana con el software en conjunto.
Los requisitos estáticos pueden incluir a lo siguiente:

- El número de terminales a ser consideradas.

- El número de usuarios que se conectarán en simultáneo.
- La cantidad y tipo de información que se manejará.

Pueden identificarse este tipo de requisitos estáticos en un apartado separado en la

especificación de requerimientos, bajo el título: capacidad. Por ejemplo, los requisitos
dinámicos pueden incluir los números de transacciones, tareas y la cantidad de datos a ser
procesado dentro de ciertos períodos de tiempo para condiciones del trabajo normales y
máximas. Todos estos requisitos deben declararse en las condiciones mensurables. Por
ejemplo, 95% de las transacciones se procesarán en menos de 1 seg.

Se podrían realizar cuadros como el siguiente para cuantificar entidades involucradas en el

software a desarrollar:

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 2

 Volumen Crecimiento Volumen Condición de
Entidad inicial esperado máximo obsolescencia

Clientes 150 25 por año 500 1 año sin pedidos

Autorizaciones 25 15 por año 3000 2 meses de hecha

Técnicas para especificación de requerimientos no funcionales

Especificar los requerimientos funcionales para nuestro sistema de software es solo una
parte de la tarea a realizar. Nos falta otra parte relevante que es enfocarnos en
requerimientos no funcionales. Todos los sistemas, desde los más simples hasta los que
presentan alta complejidad, tienen requerimientos adicionales que refieren a restricciones
o atributos que deben también cumplir.

El siguiente cuadro fue confeccionado por Barry Boehm, un reconocido autor en el área de
ingeniería del software, que estableció en 1976 una lista jerárquica de cualidades
presentes un producto de software.

Si bien el cuadro es muy completo, no todos los sistemas de software que nosotros
desarrollemos van a requerir que se especifique toda la lista de cualidades precedente.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 3

Esto dependerá de los requisitos planteados por el cliente/usuarios para cada aplicación
en particular. Por ejemplo, si se trata de un controlador de vuelo del que dependen vidas
humanas, la confiabilidad se transformará en un requerimiento importante, mientras que
si se trata de un producto que se comercializará en forma masiva, como un juego para
niños, quizás la portabilidad sea un factor más crítico para poder alcanzar a la mayor
cantidad de usuarios.

Lo más relevante a tener en cuenta es que debe determinarse para cada aplicación y cada
situación particular cuáles son los requerimientos críticos necesarios, sin generalizar, para
evitar malgastar tiempo y recursos en cuestiones que no son imprescindibles.

Al momento de redactarlos, tengamos presente que los requerimientos no funcionales

habitualmente son expresados en lenguaje natural. Esto implica que suelan tener un alto
nivel de ambigüedad que debe ser evitado para poder ser verificados.

Los requerimientos no funcionales, como se indicó previamente, refieren a:

- Restricciones que representan características impuestas por el cliente.

- Atributos de calidad que son propiedades relevantes para los usuarios.

Cuando el cliente o los usuarios especifican requerimientos no funcionales, se recomienda

llevar a cabo un análisis costo/beneficio para ellos. La correcta descripción puede
evaluarse con las siglas del término SMART (Specific, Measurable, Attainable, Realizable,
Traceable) que implica:

- Específico: el requerimiento debe estar expresado sin ambigüedad, en forma

simple y clara.
- Medible: el requerimiento debe poder medirse, probarse si lo cumple o no.
- Alcanzable: que sea factible llevarlo a cabo.
- Realizable: se puede cumplir con los recursos que se encuentran disponibles,
infraestructura, tecnología, personal, etc.
- Rastreable: se puede determinar su origen, quién lo solicitó, dónde se encuentra
especificado, su diseño e implementación.

Para validar un requerimiento puede emplearse la definición de escenarios, donde

debe definirse la entrada (quien produce el estímulo y el estímulo que se produce), las
condiciones (en que se encuentra el sistema y que componente recibe el estímulo), y
los resultados (la respuesta que provoca ese estímulo, junto con la métrica para
medirlo).

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 4

Atributos de una buena especificación
Describiremos brevemente a continuación los atributos que debe cumplir una SRS para
ser considerada bien escrita:

Correcto: Una especificación de requisitos de software es correcta si, y solo si, todos y
cada uno de los requisitos indicados representa algo requerido por el sistema a
construirse. No hay una herramienta que pueda garantizar la corrección, pero si es
recomendable que el cliente determine si la especificación del software muestra sus
necesidades.

No ambigua: Si, y solo si, cada requerimiento establecido en la especificación de

requerimientos tiene una única interpretación. Algo a tener en cuenta es que cada
término que tenga múltiples significados debe aparecer en un glosario, sobre todo porque
el lenguaje natural invita a la ambigüedad.

Completa: Un documento SRS está completo si, y solo si, incluye:

 Todo lo que el software tiene que hacer está en el SRS. Es una condición difícil de
lograr ya que, si lo olvidamos, no lo detectaremos fácilmente.
 Todas las posibles respuestas del software a todas las posibles entradas de datos
deben estar definidas. Es importante especificar las respuestas tanto para datos de
entrada válidos, como inválidos.
 Todas las páginas, figuras y tablas numeradas y referenciadas.
 Ninguna sección puede contener las siglas en inglés TBD (to be determined: a
determinar), que se incluye junto a un requerimiento del SRS cuando su descripción
no se encuentra completa. Es recomendable incluir, en este caso, la causa por la cuál
está incompleto, junto con quién es la persona responsable de llevarlo a cabo y una
fecha estipulada para cumplirse.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 5

Verificable: Un requisito es verificable si solo si existe algún proceso concreto y finito en el
cual una persona o máquina pueda comprobar si el software lo cumple.

En función de cómo se describe, puede ser difícil verificar el requerimiento: los requisitos
ambiguos no son verificables (por ejemplo: “el sistema debe tener una interfaz
amigable”). Lo mismo sucede cuando indican cantidades no mensurables (por ejemplo: “el
sistema usualmente no debe demorar más de 30 segundos en una consulta”) o cualquier
requerimiento referente a pruebas de bloqueo (por ejemplo: “el sistema no puede entrar
en un ciclo infinito”). Si no es posible establecer un método para comprobar si el software
cumple con un determinado requisito, el requisito debe eliminarse o revisarse.
Consistente: La documentación es internamente consistente si, y solo si, no se establecen
conflictos entre requisitos individuales o grupos de requisitos. Los tres tipos de conflictos
posibles son:

- Términos conflictivos: dos términos en distintos contextos se emplean para significar

la misma cosa.
- Características conflictivas: dos partes de la SRS demandan comportamientos
contradictorios.
- Inconsistencia temporal: dos partes del SRS demandan del producto características
temporales contradictorias.

Entendible por no especialistas: refiere a que la notación formal que se emplee debe
poder ser comprendida por clientes y usuarios especialistas en todas las áreas. La idea es
que sea fácil de entender para que el cliente pueda validarla.

Modificable: Un documento de requisitos es modificable si, y solo si, su estilo y estructura

permiten que puedan llevarse a cabo modificaciones en los requisitos manteniendo la
estructura y el estilo, de forma fácil, completa y consistente. La modificabilidad
generalmente requiere en la documentación una tabla de contenidos y un índice.

Rastreable o trazable: Un SRS es trazable si el origen de cada uno de los requerimientos

es claro y facilita su referencia de cada uno de ellos en las futuras etapas del desarrollo, o
en las actualizaciones de la documentación.

Se recomiendan los siguientes tipos de trazabilidad:

 Trazabilidad hacia atrás desde los requerimientos: podemos conocer porque cada
requerimiento en el SRS existe.
 Trazabilidad hacia adelante hasta los requerimientos: todos los documentos que
preceden al SRS pueden referenciarse al SRS.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 6

  Trazabilidad hacia atrás hasta los requerimientos: cada comportamiento del
software refiere explícitamente aquellos requerimientos que satisface.
 La trazabilidad hacia adelante desde los requerimientos: podemos entender cuáles
componentes del software satisfacen cada requerimiento.

Anotada: Cada requerimiento con una anotación que provee una guía al desarrollo.
Existen básicamente dos tipos de notaciones:

 Necesidad relativa: son de utilidad cuando el cliente prefiere el producto a tiempo

aun cuando no estén completos los requerimientos no relevantes. Así, cada
requerimiento puede ser catalogado por ejemplo como: E (esencial9, D (deseable),
O (opcional).
 Estabilidad relativa: determina si el requerimiento es estable o volátil.

Aspectos de la gestión de requerimientos

La revisión, en forma regular, de la definición de los requerimientos que se va realizando
puede ayudar a su mejor gestión y detección de errores. En esta tarea van a estar
involucrados tanto los desarrolladores como el cliente. La revisión de la especificación de
requerimientos puede realizarse en formalmente, es decir, cuando se cuenta con la
documentación completa, o en informalmente durante su producción. Mantener una
buena comunicación entre todos los involucrados, clientes, usuarios y desarrolladores,
puede ayudar a prevenir problemas en las primeras etapas del desarrollo.

La validación de los requerimientos la debe realizar el cliente y los usuarios para confirmar
que coincidan con los definidos para el sistema en relación a lo que se desea o espera de
él. La validación es importante porque los costos de errores en los requerimientos son
altos, por lo cual, cuanto antes se detecten, más pronto podrán corregirse. El prototipado
es una técnica de gran utilidad al momento de validar los requerimientos.

Evolución de los requerimientos

Los requerimientos buscan comprender y cubrir las necesidades de los usuarios, pero, así
como los objetivos de la organización pueden ir modificándose, esto puede implicar un
cambio en los requerimientos. Es importante planear los posibles cambios o
modificaciones en los requerimientos cuando desarrolle el sistema, y mientras se esté
utilizando.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 7

Todos los posibles cambios en los requerimientos deben actualizarse en el documento
SRS, generando una nueva versión. Por esta razón, y como mencionamos previamente, el
documento debe ser organizado de forma tal que los cambios puedan ser incorporados
fácilmente.

© Universidad de Palermo. Prohibida la reproducción total o parcial de imágenes y textos. 8