ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

¿Qué son Requerimientos?

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 .

(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).

Los requerimientos puedes dividirse en requerimientos funcionales y

requerimientos no funcionales. Los requerimientos funcionales definen las
funciones que el sistema será capaz de realizar. Describen las transformaciones que
el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u
otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo
y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un

conjunto de requerimientos en estado de madurez, deben presentar una serie de
características tanto individualmente como en grupo. A continuación se presentan
las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en

el sistema a construir, y además su capacidad, características físicas o factor de
calidad no pueden ser reemplazados por otras capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción
debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, si se proporciona la información suficiente para su
comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de
manera que permita hacer uso de los siguientes métodos de verificación:
inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).

• Existen muchos tipos de requerimientos y diferentes niveles de detalle.

• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o
más estables que otros.

• Los requerimientos están relacionados unos con otros, y a su vez se relacionan

con otras partes del proceso.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales

específicas.

• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular

para cada proyecto.

Ingeniería de Requerimientos vs. Administración de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente para un

sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de
requerimientos (IR) es entregar una especificación de requisitos de software
correcta y completa.

Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de

software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan
los requerimientos como una base para la estimación del esfuerzo necesario en un
proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por
ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema.

Los requerimientos son la base sobre la cual se decide si un caso de prueba fue
ejecutado exitosamente por el sistema o no.

Son el fundamento del ciclo de vida del proyecto. Los requerimientos

documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y manejados
de la forma más adecuada posible.

Características de un requerimiento

Ya que visualizamos la importancia de los requerimientos en un sistema de

software entonces debemos de definir qué características deben de poseer los
requerimientos adecuadamente formulados.

Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar,
entonces ¿cómo sabemos si cumplimos con él o no?
Descritos como una característica del sistema a entregar. Esto es: que es lo que el
sistema debe de hacer (y no como debe de hacerlo)

Lo más abstracto y conciso posible. Para evitar malas interpretaciones.

Fundamentos del Análisis de Requerimientos

Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer

los elementos necesarios para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el usuario para
resolver un problema o alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer
un contrato, un estándar, una especificación u otro documento formalmente
impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación
completa de los requerimientos de los mismos. Independientemente de lo bien
diseñado o codificado que esté, un programa pobremente especificado
decepcionará al usuario y hará fracasar el desarrollo.

La tarea de análisis de los requerimientos es un proceso de descubrimiento y

refinamiento, El ámbito del programa, establecido inicialmente durante la
ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos
elementos de los programas las soluciones alternativas.

Tanto el que desarrolla el software como el cliente tienen un papel activo en la

especificación de requerimientos. El cliente intenta reformular su concepto, algo
nebuloso, de la función y comportamiento de los programas en detalles concretos,
El que desarrolla el software actúa como interrogador, consultor y el que resuelve
los problemas.

El análisis y especificación de requerimientos puede parecer una tarea

relativamente sencilla, pero las apariencias engañan. Puesto que el contenido de
comunicación es muy alto, abundan los cambios por mala interpretación o falta de
información. El dilema con el que se enfrenta un ingeniero de software puede ser
comprendido repitiendo la sentencia de un cliente anónimo: "Sé que crees que
comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste
oír sea lo que yo quise decir".

Los requerimientos de un sistema de software, cuando se ven en su conjunto son

extensos y detallados, y además contienen múltiples relaciones entre sí. Lo que nos
da a concluir, que el conjunto de requerimientos de un sistema computacional es
complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar
especificaciones simples y concisas para el sistema. Esto se logra mediante al
clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras
palabras al analizar sus requerimientos.

El análisis de requerimientos es la tarea que plantea la asignación de software a

nivel de sistema y el diseño de programas. El análisis de requerimientos facilita al
ingeniero de sistemas especificar la función y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y establecer las ligaduras de
diseño que debe cumplir el programa. El análisis de requerimientos permite al
ingeniero refinar la asignación de software y representar el dominio de la
información que será tratada por el programa. El análisis de requerimientos de al
diseñador la representación de la información y las funciones que pueden ser
traducidas en datos, arquitectura y diseño procedimental. Finalmente, la
especificación de requerimientos suministra al técnico y al cliente, los medios para
valorar la calidad de los programas, una vez que se haya construido.

Tareas del Análisis

El análisis de requerimientos puede dividirse en cuatro áreas:

1.- Reconocimiento del problema

2.- Evaluación y síntesis

3.- Especificación

4.- Revisión.

Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de

proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de
los programas que se usó para generar las estimaciones de la planificación. A
continuación, debe establecerse la comunicación necesaria para el análisis, de
forma que se asegure el reconocimiento del problema.

El analista debe establecer contacto con el equipo técnico y de gestión del usuario /
cliente y con la empresa que vaya a desarrollar el software. El gestor del programa
puede servir como coordinador para facilitar el establecimiento de los caminos de
comunicación. El objetivo del analista es reconocer los elementos básicos del
programa tal como lo percibe el usuario / cliente.

La evaluación del problema y la síntesis de la solución es la siguiente área principal

de trabajo del análisis. El analista debe evaluar el flujo y estructura de la
información, refinar en detalle todas las funciones del programa, establecer las
características de la interfase del sistema y descubrir las ligaduras del diseño, Cada
una de las tareas sirve para descubrir el problema de forma que pueda sintetizarse
un enfoque o solución global.

Las tareas asociadas con el análisis y especificación existen para dar una
representación del programa que pueda ser revisada y aprobada por el cliente. En
un mundo ideal el cliente desarrolla una especificación de requerimientos del
software completamente por sí mismo. Esto se presenta raramente en el mundo
real. En el mejor de los casos, la especificación se desarrolla conjuntamente entre el
cliente y el técnico.

Una vez que se hayan descrito las funcionalidades básicas, comportamiento,

interfase e información, se especifican los criterios de validación para demostrar
una comprensión de una correcta implementación de los programas. Estos criterios
sirven como base para hacer una prueba durante el desarrollo de los programas.
Para definir las características y atributos del software se escribe una especificación
de requerimientos formal. Además, para los casos en los que se desarrolle un
prototipo se realiza un manual de usuario preliminar.

Puede parecer innecesario realizar un manual de usuario en una etapa tan

temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de
usuario fuerza al analista a tomar el punto de vista del usuario del software. El
manual permite al usuario / cliente revisar el software desde una perspectiva de
ingeniería humana y frecuentemente produce el comentario: "La idea es correcta
pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir
tales comentarios lo más tempranamente posible en el proceso.

Los documentos del análisis de requerimiento (especificación y manual de usuario)

sirven como base para una revisión conducida por el cliente y el técnico. La revisión
de los requerimientos casi siempre produce modificaciones en la función,
comportamiento, representación de la información, ligaduras o criterios de
validación. Además, se realiza una nueva apreciación del plan del proyecto de
software para determinar si las primeras estimaciones siguen siendo válidas
después del conocimiento adicional obtenido durante el análisis.

Obteniendo de la información

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de

desarrollo de software, este entendimiento es necesario para poder construir
software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es

lógico que para recabarlos haya que obtener la información de primera mano. Esto
es, mediante entrevistas con el cliente o recabando documentación que describa la
manera que el cliente desea que funcione el sistema de software.

Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada

cambio involucra un costo. Por eso es necesario tener archivada una copia de la
documentación original del cliente, así como cada revisión o cambio que se haga a
esta documentación. Como cada necesidad del cliente es tratada de diferente
forma, es necesario clasificar estas necesidades para saber cuáles de ellas serán
satisfechas por el software y cuales por algún otro producto del sistema.

Especificación de Requisitos de Software (SRS)

La especificación de req