Análisis, especificación y diseño de software

Introducción
A la hora de construir una aplicación o software es fundamental que los desarrolladores
conozcan de forma precisa el problema que van a resolver, de tal manera que la solución que
se construya sea correcta y útil. Para esto se sigue una serie de pasos (proceso de software)
que forman parte del ciclo de vida del desarrollo del software.

Un Proceso de software es una serie de actividades relacionadas que conduce a la elaboración

de un producto de software. ¿Qué es un producto de software? Son todos aquellos conceptos,
actividades y procedimientos que dan como resultado la generación de programas para un
sistema de computación. En otras palabras, son las instrucciones que han sido predefinidas por
un programador para ejecutar las tareas que se le indican.
El objetivo de un “buen software” es aumentar las posibilidades de que éste se desarrolle a
tiempo y de que tenga una mayor efectividad en cuanto a costos debido a una utilización más
eficiente del personal y los recursos.

Las etapas (o actividades) principales a realizar en cualquier ciclo de vida son:

 Análisis: Construye un modelo a partir de la toma de los requisitos.

 Especificación: Es la tarea de describir detalladamente el software a ser escrito, de una
forma rigurosa. (No siempre figura como una etapa del proceso)
 Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura
en la que descompone el sistema y la interfaz de usuario.
 Codificación: Construye el sistema. La salida de esta fase es código ejecutable.
 Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
 Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el
sistema siga funcionando y adaptándose a nuevos requisitos.

El autor Sommerville propone 4 actividades fundamentales: especificación, diseño e

implementación, validación y evolución.
El autor Pressman propone actividades estructurales: comunicación, planeación, modelado,
construcción y despliegue.
Estas diferencias son debido a que no existe un proceso de software “ideal”, estos se adaptan
a las particularidades de cada desarrollo. Más adelante se describirán estas actividades con
más detalle.

Los procesos de software son representados de forma abstracta por modelos de procesos,
presentando una descripción del mismo. Los modelos más comunes son:

Modelo en cascada:
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de
software se concibe como un conjunto de etapas que se ejecutan una tras otra. Se le
denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto,
colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como
una cascada.

Ventajas
 El tiempo que se pasa en diseñar el producto en las primeras fases del proceso puede
evitar problemas que serían más costosos cuando el proyecto ya estuviese en fase de
desarrollo.
 La documentación es muy exhaustiva y si se une al equipo un nuevo desarrollador,
podrá comprender el proyecto leyendo la documentación.
 Al ser un proyecto muy estructurado, con fases bien definidas, es fácil entender el
proyecto.
 Ideal para proyectos estables, donde los requisitos son claros y no van a cambiar a lo
largo del proceso de desarrollo.

Inconvenientes
 En muchas ocasiones, los clientes no saben bien los requisitos que necesitarán antes
de ver una primera versión del software en funcionamiento. Entonces, cambiarán muchos
requisitos y añadirán otros nuevos, lo que supondrá volver a realizar fases ya superadas y
provocará un incremento del coste.
 No se va mostrando al cliente el producto a medida que se va desarrollando, si no que
se ve el resultado una vez ha terminado todo el proceso. Esto cual provoca inseguridad por
parte del cliente que quiere ir viendo los avances en el producto
  Los diseñadores pueden no tener en cuenta todas las dificultades que se encontrarán
cuando estén diseñando un software, lo que conllevará rediseñar el proyecto para solventar el
problema.
 Para proyectos a largo plazo, este modelo puede suponer un problema al cambiar las
necesidades del usuario a lo largo del tiempo. Si por ejemplo, tenemos un proyecto que va a
durar 5 años, es muy probable que los requisitos necesiten adaptarse a los gustos y novedades
del mercado.

Modelo incremental
El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva
de construcción de prototipos. Se basa en la filosofía de construir incrementando las
funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del
software.

Ventajas
 Mediante este modelo se genera software operativo de forma rápida y en etapas
tempranas del ciclo de vida del software.
 Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y
requisitos.
 Es más fácil probar y depurar en una iteración más pequeña.
 Es más fácil gestionar riesgos.
 Cada iteración es un hito gestionado fácilmente

Inconvenientes
 Cada fase de una iteración es rígida y no se superponen con otras.
 Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los
requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio

Modelo iterativo
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que
surge entre las necesidades del usuario y el producto final por malos entendidos durante la
etapa de recogida de requisitos.
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le
entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente
es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas
iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente.

Ventajas
 Una de las principales ventajas que ofrece este modelo es que no hace falta que los
requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando
en cada una de las iteraciones.
 Igual que otros modelos similares tiene las ventajas propias de realizar el desarrollo en
pequeños ciclos, lo que permite gestionar mejor los riesgos, gestionar mejor las entregas…

Inconvenientes
 La primera de las ventajas que ofrece este modelo, el no ser necesario tener los
requisitos definidos desde el principio, puede verse también como un inconveniente ya que
pueden surgir problemas relacionados con la arquitectura.

Modelo en espiral
Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de
construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y
SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del
software que no se basa en fases claramente definidas y separadas para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un
prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del
sistema diseñado.
EL modelo en espiral se divide en un número de actividades de marco de trabajo, también
llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto
de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del
proyecto que va a emprenderse en todos los casos se aplican actividades de protección.
Ventajas
 El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
 Como el software evoluciona a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele evolutivos.
 El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción
de prototipos en cualquier etapa de evolución del producto.
 El modelo en espiral demanda una consideración directa de los riesgos técnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de
que se conviertan en problemas.
 En la utilización de grandes sistemas a doblado la productividad.

Desventajas
 Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
 Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
 Genera mucho tiempo en el desarrollo del sistema
 Modelo costoso
 Requiere experiencia en la identificación de riesgos

Modelo de prototipos

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan
rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren
que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como
también la solución que se propone para dicha necesidad y de esta forma minimizar el riesgo y
la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que
estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones,
es ideal para medir el alcance del producto, pero no se asegura su uso real.
Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos
generales para el software a desarrollarse sin delimitar detalladamente los requisitos de
entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de
un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa el hombre y la
máquina.
Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a
entender de mejor manera cuál será el resultado de la construcción cuando los requisitos
estén satisfechos.
Ventajas
Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un
mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia
de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar
la interacción humano-máquina.

Desventajas
Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y
cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir
buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el
desarrollador haya hecho compromisos de implementación para hacer que el prototipo
funcione rápidamente. Es posible que el prototipo sea muy lento, muy grande, no muy
amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado.
El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido
construido con "plastilina y alambres", y puede desilusionarse al decirle que el sistema aún no
ha sido construido. El desarrollador puede ampliar el prototipo para construir el sistema final
sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.
Etapas o actividades del proceso en detalle
Análisis: búsqueda de los requerimientos del sistema (ingeniería de requerimientos).

Uno de los primeros procesos que se realizan en un proyecto de construcción de software es la

especificación de requisitos. Los objetivos de este proceso son identificar, validar y
documentar los requisitos de software; es decir determinar las características que deberán
tener el sistema o las restricciones que deberá cumplir para que sea aceptado por el cliente y
los futuros usuarios del sistema de software.
El producto final de este proceso es el documento de especificación de requisitos de software
y en este se señala, con el detalle adecuado, lo que el usuario necesita del sistema de
software. Es por ello, que el documento de requisitos de software se considera como un
contrato entre el cliente y el equipo de desarrollo del sistema.

Requerimientos: Los requerimientos especifican qué es lo que el sistema debe hacer (sus
funciones) y sus propiedades esenciales y deseables. La captura de los requerimientos tiene
como objetivo principal la comprensión de lo que los clientes y los usuarios esperan que haga
el sistema. Un requerimiento expresa el propósito del sistema sin considerar como se va a
implantar. En otras palabras, los requerimientos identifican el qué del sistema.

A los requisitos funcionales se los puede dividir en requisitos:

• De usuario: son declaraciones, en lenguaje natural y en diagramas, de los servicios que se
espera que el sistema provea y de las restricciones bajos las cuales se debe operar.
• Del sistema: establecen con detalle los servicios y restricciones del sistema. El documento de
requerimientos del sistema, algunas veces denominado especificación funcional, debe ser
preciso.

La captura y el análisis de los requerimientos del sistema es una de las fases más importantes
para que el proyecto tenga éxito. Como regla de modo empírico, el costo de reparar un error
se incrementa en un factor de diez de una fase de desarrollo a la siguiente.

Características de los requerimientos:

 Deben ser correctos: tanto el cliente como el desarrollador deben revisarlos para asegurar
que no tienen errores.
 Deben ser consistentes: dos requerimientos son inconsistentes cuando es imposible
satisfacerlos simultáneamente.
 Deben estar completos: el conjunto de requerimientos está completo si todos los estados
posibles, cambios de estado, entradas, productos y restricciones están descritos en alguno de
los requerimientos.
 Deben ser realistas: todos los requerimientos deben ser revisados para asegurar que son
posibles.
 ¿Cada requerimiento describe algo que es necesario para el cliente?: los requerimientos
deben ser revisados para conservar sólo aquellos que inciden directamente en la resolución
del problema del cliente.
 Deben ser verificables: se deben poder preparar pruebas que demuestren que se han
cumplido los requerimientos.
 Deben ser rastreables: ¿Se puede rastrear cada función del sistema hasta el conjunto de
requerimientos que la establece?
Fuentes de Requerimientos: de donde pueden extraerse estos requerimientos.

Formas de obtener los requerimientos:

 Revisar la situación actual.

 Trabajar en el ámbito del usuario para comprender el contexto, los problemas y las
relaciones.
 Entrevistar a los usuarios actuales y potenciales.
 Realizar un video para mostrar cómo podría funcionar el nuevo sistema.
 Investigar en documentos existentes.
 Conducir tormentas de ideas con los usuarios actuales y potenciales.
 Observar las estructuras y los patrones.

Cuando se trabaja en conjunto con los usuarios y los clientes surgen los siguientes problemas:

 No saben lo que quieren del sistema, sólo en términos generales, no conocen el costo de
sus peticiones.
 Los requerimientos están en sus términos y con conocimientos implícitos de su propio
trabajo.
 Distintos usuarios tienen distintos requerimientos, se deben encontrar todas las fuentes.
 Influyen factores políticos.
 La importancia de los requerimientos varía en el tiempo.
 Aparecen nuevos requerimientos.
IMPORTANCIA DE APLICAR UN BUEN PROCESO DE SOFTWARE

Los usuarios tienen una forma de expresar sus necesidades, el líder del proyecto, el analista de
sistemas, el programador le dan un enfoque totalmente diferente; por otro lado la
recomendación del consultor externo le añade otras funcionalidades al producto, además no
existe documentación del proyecto y no se ha realizado el estudio de factibilidad económica,
no hay un soporte operativo eficiente y finalmente el producto que el usuario necesitaba era
algo sencillo, sin tantas complicaciones.

Técnicas y herramientas para llevar a cabo la recolección de requerimientos:

Entrevistas:
La entrevista es un método para descubrir hechos y opiniones que tienen los posibles usuarios
y otros participantes dentro del sistema que se está desarrollando. Los errores y
malentendidos pueden ser detectados y corregidos a través de este método, por lo cual
resulta muy útil dentro de esta actividad de la ingeniería de requerimientos. Las entrevistas
pueden ser clasificadas en dos grandes grupos.
• Las entrevistas cerradas, donde el entrevistador (ingeniero de requerimientos) prepara un
conjunto de preguntas antes del encuentro con el entrevistado, y se buscan respuestas para
las preguntas formuladas.
• Las entrevistas abiertas, en las cuales no se preparan preguntas concretas, y, por el
contrario, se discute con el entrevistado las expectativas que este tiene del sistema.
No existe en realidad una delimitación entre los dos tipos de entrevistas en el momento de
llevarlas a cabo. Pueden ser utilizadas de manera conjunta y no necesariamente exclusiva ni
excluyente. La ventaja de este método es que permiten que el entrevistador obtenga una
colección rica en información, que le puede ser útil al desarrollador. La desventaja que tiene
este método, es que la información que se recolecta puede ser difícil de organizar y analizar, y
diferentes participantes dentro del desarrollo del sistema pueden proveer información
conflictiva y contradictoria, esto consecuencia de la gran cantidad de información que es
obtenida durante la ejecución de este método.

Casos de Uso y/o Escenarios.

Los casos de uso describen interacciones entre los usuarios y el sistema, enfatizando en lo que
el usuario necesita del sistema. Un caso de uso describe la posible secuencia de interacciones
que se dan entre el sistema y uno o más actores como respuesta a un estímulo inicial por parte
de alguno de los actores. De igual manera, debe ser incluida dentro de esta interacción, la
descripción de las variantes y extensiones que el sistema debe soportar.
Los casos de uso representan los requerimientos funcionales del software y pueden ser
utilizados dentro de las primeras etapas del proceso de desarrollo. Así mismo, los casos de uso
están escritos en lenguaje natural y son descripciones expresadas de manera informal.
Las descripciones expresan lo que sucede desde el punto de vista del usuario. Los detalles de
cómo el sistema debe funcionar internamente son irrelevantes al caso de uso.
Por otra parte, los escenarios son ejemplos de sesiones de interacción entre el sistema y el
usuario, donde un solo tipo de interacción entre los dos participantes es simulada y descrita.
Los escenarios deben incluir una descripción del estado del sistema antes y después de la
culminación del escenario, que actividades deben ser simultaneas, el flujo normal de los
eventos y las excepciones a esos eventos.

Observación y análisis social.

Los métodos de observación involucran a dos participantes: el investigador observando al
usuario mientras trabaja y tomando notas de las actividades que se llevan a cabo, y al
trabajador (usuario) llevando a cabo las actividades cotidianas que su trabajo le implica
realizar. La observación puede ser realizada de manera directa, es decir que el investigador
este presente mientras el usuario realiza sus actividades; o indirecta, cuando la observación se
lleva en otro escenario, instante, o a través de otro medio que permita que el observador no
esté presente durante la realización de las actividades que está observando (como lo
permitiría el uso de una cámara de video). Este método es muy útil cuando se busca estudiar
las actividades y procesos que se están llevando a cabo en una organización en el momento. La
observación permite a los investigadores observar lo que los usuarios hacen actualmente en
un determinado contexto.
Esto permite superar problemas con los participantes del proyecto que realizan descripciones
idealizadas o demasiado simplificadas de los procesos que se llevan a cabo en sus trabajos.

Lluvia de ideas.
Las lluvias de ideas son sesiones donde todos los participantes brindan sus ideas para obtener
una solución a una problemática. Una lluvia de ideas está compuesta de dos fases: la fase de
generación y la fase de evaluación. Durante la generación las ideas son recolectadas y es
importante que no sean criticadas. Durante la evaluación de las ideas, las propuestas de
solución deben ser evaluadas desde diferentes perspectivas.
Algunas de las características que tienen estas sesiones, es que las ideas deben ser generadas
de manera rápida y abierta. De igual manera, es importante que el ambiente de la sesión
fomente la creatividad de los participantes y esté enfocado a una problemática específica.
Todas estas consideraciones permiten que este método conlleve a un mejor entendimiento del
problema, y permita que los participantes de la sesión adquieran un sentido de propiedad
sobre la solución que se debe llevar a cabo.

Prototipos.
En la ingeniería de software, un prototipo es programa de computador que implementa
algunos de los requerimientos de un sistema. Este prototipo puede ser usado para colaborar
con la definición de los requerimientos, o para facilitar la evaluación de alternativas de
implementación de un sistema.
En general, los prototipos se consideran herramientas muy valiosas para clarificar los
requerimientos que son confusos durante el desarrollo de un sistema. Los prototipos actúan
de manera similar a los escenarios, debido a que proveen un contexto en el cual los usuarios
pueden entender mejor la información que ellos deben proveer a los desarrolladores para que
se pueda construir el sistema.

Técnica de Casos de uso (especificar el comportamiento del sistema)

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa
alguno de sus servicios.
El propósito de los casos de uso es describir en lenguaje natural la funcionalidad completa de
un sistema a desarrollar y su empleo se realiza en el proceso de especificación de requisitos
del sistema.

Definiciones básicas:

 Actores: Una definición previa, es que un Actor es un rol que un

usuario juega con respecto al sistema. Es importante destacar el uso de la
palabra rol, pues con esto se especifica que un Actor no necesariamente
representa a una persona en particular, sino más bien la labor que realiza
frente al sistema. Como ejemplo a la definición anterior, tenemos el caso de
un sistema de ventas en que el rol de Vendedor con respecto al sistema
puede ser realizado por un Vendedor o bien por el Jefe de Local.

 Caso de Uso: Es una operación/tarea específica que se realiza

tras una orden de algún agente externo, sea desde una petición de un
actor o bien desde la invocación desde otro caso de uso.

 Relaciones:
o Asociación: Es el tipo de relación más básica que indica la
invocación desde un actor o caso de uso a otra operación (caso de
uso). Dicha relación se denota con una flecha simple.
o Dependencia o Instanciación: Es una forma muy particular de
relación entre clases, en la cual una clase depende de otra, es decir, se
instancia (se crea). Dicha relación se denota con una flecha punteada.

Ejemplo, máquina Recicladora: Sistema que controla una máquina de reciclamiento de

botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
 Registrar el número de ítemes ingresados.
 Imprimir un recibo cuando el usuario lo solicita:
o Describe lo depositado
o El valor de cada item
o Total
 El usuario/cliente presiona el botón de comienzo
 Existe un operador que desea saber lo siguiente:
o Cuantos ítemes han sido retornados en el día.
o Al final de cada día el operador solicita un resumen de todo lo depositado en
el día.
 El operador debe además poder cambiar:
o Información asociada a ítemes.
o Dar una alarma en el caso de que:
 Item se atora.
 No hay más papel.

Como una primera aproximación

identificamos a los actores que
interactuan con el sistema:

Luego, tenemos que

un Cliente puede
Depositar Itemes y
un Operador puede
cambiar la
información de un
Item o bien puede
Imprimir un informe.

Además podemos notar que

un item puede ser una Botella,
un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes,

que puede ser realizada después de depositar
algún item por un cliente o bien puede ser
realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:

Especificación de requerimientos

La Especificación de Requerimientos de Software (ERS) es también llamada una especificación

funcional, la especificación de un producto, el documento de requerimientos, o la
especificación del sistema. Establece las funciones y capacidades que el sistema de software
debe proveer y las restricciones a tomar en consideración.
La especificación de requerimientos es el proceso de elaboración, refinamiento y organización
de los requisitos plasmados en un documento. La especificación es responsabilidad principal
del analista de sistemas, pero se pueden incluir otros usuarios que permitan hacer las
revisiones y validaciones e incluso aportar con la redacción de los requisitos.

Documentar los requerimientos de usuario

Documentar los requisitos desde el punto de vista del usuario consiste en elaborar un
documento de necesidades de los usuarios (que se describe más adelante). La documentación
permite describir las características y el comportamiento del sistema que se propone desde el
punto de vista del usuario. Esta descripción actúa como un puente entre las necesidades del
usuario y la especificación de requisitos de software. Más adelante se estará analizando y
describiendo la plantilla utilizada para el efecto.

Verificar las necesidades del usuario

Compruebe que los requisitos de los usuarios describen lo que los usuarios tienen que ver con
el sistema. Asegúrese de que los requisitos se derivan de los requerimientos del negocio (es
decir, la visión del producto, metas y objetivos del proyecto). También es necesario que los
Stakeholders comprueben que los requisitos estén completos, consistentes y de alta calidad.
Revise la documentación, según sea necesario.

Documentar los requerimientos de software

Documentar o registrar los requisitos de software en definitiva es realizar una especificación

de requisitos de software que consiste en escribir el documento de especificación para el
público profesional (que proporcionan el software). Esta especificación describe los requisitos
funcionales, los atributos de calidad, las interfaces del sistema, y las limitaciones de diseño e
implementación. Más adelante se analizará la plantilla utilizada para el efecto.

Verificar los requerimientos de software

En esta fase asegúrese de que la documentación describe correctamente las capacidades de

intención y las características del sistema. Comprobar que los requisitos de software han sido
derivados de forma precisa de las necesidades del usuario, de los requisitos del sistema, y
otras fuentes que se utilizaron.
Ahora deberá centrarse en la documentación de los requerimientos; para esto la IEEE a través
de sus estándares facilita plantillas que pueden ser ajustadas a los estándares de la
organización; de igual forma las metodologías de hoy en día como son: RUP, Volere, entre
otras han establecido sus plantillas para proceder con ésta documentación. Las plantillas que
se indican en esta guía tómelas como referencia para desarrollar el caso práctico y ajústelas de
acuerdo a su conveniencia.

Documento de requerimientos de usuario

Un documento de requerimientos de usuario es un registro de los requisitos escritos para una
audiencia de usuarios que describen lo que los usuarios necesitan y porque son necesarios.
Este documento se lo usa para obtener un acuerdo sobre lo que el producto tiene que hacer
para satisfacer las necesidades de los usuarios, para consolidar las necesidades de las
comunidades de usuarios diversos, y para proporcionar detalles adicionales no descritos por
los modelos de análisis. Este documento de requerimientos de los usuarios también actúa
como un puente entre la definición del negocio y los requisitos de software.