3.1 Obtencin y especificacin de requerimientos.

Los requerimientos son las necesidades o especificaciones que tiene el cliente con
respecto a un producto. Para fines de esta asignatura, entendemos que ese
producto es el software. En esta unidad, es importante que se logre la
comprensin de cmo obtener una adecuada descripcin de las necesidades que
el cliente pretende cubrir con las funciones del software, para poder transformarlas
en requerimientos claros y bien definidos para el equipo de trabajo y para el
mismo cliente. Los conjuntos de requerimientos sern desarrollados y gestionados
a travs de las etapas del proceso de desarrollo y poco a poco sern
transformados en un software que reunir todas esas caractersticas solicitadas. A
continuacin se mostrara un ejemplo para mejor comprensin:

Cuando un cliente solicita que se le desarrolle un software para llevar el control

de las existencias de su almacn de materia prima, ya que la empresa ha crecido
y por lo tanto el almacn cada vez tiene una mayor cantidad de materiales, lo
cual provoca que la actual forma de trabajo que es realizada con hojas de
clculo, resulta cada vez ms difcil de actualizar y mantener. Por lo cual ha
decidido que un software construido para este fin podra ser una solucin a esta
necesidad.
El ejemplo previo representa las necesidades que se deben detectar y traducir en
requerimientos y posteriormente representarlos en un lenguaje de modelado para
que sean entendibles para el equipo de desarrollo de software.
2.1. Obtencin y especificacin de requerimientos
Muchos proyectos de desarrollo de software no llegan a terminar en tiempo y
forma de acuerdo a lo planeado, esto es debido a que los requerimientos no se
obtuvieron ni se especificaron completamente, o no fueron muy precisos, el caso
es que durante la construccin del software se van identificando inconsistencias,
por ejemplo: puede haber duplicidad de requerimientos por un mal manejo de
nombres que se han registrado varias veces, pero en esencia es el mismo; otro
ejemplo sera la inconsistencia en revisiones de lo que se requiere; es decir, a
veces con una revisin puede parecer entendible pero en el momento de tratar de
traducirla para generar algo, no es posible por falta de datos o porque
simplemente no se comprende.
Ahora bien, en la obtencin de requerimientos, tenemos que las tareas del cliente
y del analista sern llegar a la definicin adecuada de requerimientos procurando
que las necesidades del cliente con respecto al software se cumplan y se puedan
describir en trminos entendibles para el equipo de desarrollo (lder, analista,
diseadores, programadores, encargados de pruebas). Por ello la funcin del

analista o ingeniero de requerimientos es ser un interrogador consultor, que ser

de ayuda al cliente para deter
determinar
minar la completa definicin de requerimientos.

Entonces decimos que los requerimientos son la base del desarrollo de software,
ya que, nos servirn para entender qu es lo que se va a producir y estos debern
describirse de manera clara, concreta, comple
completa
ta y sin ambigedades (evitar que
sean confusos, mal escritos, redundantes). Debemos tener presente que los
lectores de los requerimientos sern personas que posiblemente no conocen
aspectos tcnicos; por ejemplo el cliente, usuarios, contratistas y, por otra
o
parte,
personal altamente especializado como diseadores, programadores, arquitectos
de software, encargados de pruebas y de implantacin, el lder, y el mismo
analista. Para describirlos, podemos comenzar a clasificarlos como requerimientos
del usuario
o y requerimientos del sistema, tal como se muestra a continuacin:

En este diagrama se visualiza la primera clasificacin que observa y comprende

lo que el autor Ian Sommerville (2011. Pg. 83) define: Los requerimientos del
usuario son enunciados, en un lenguaje natural junto con diagramas, acerca de
qu servicios
rvicios esperan los usuarios del sistema, y de las restricciones con las
cuales ste debe operar. Un ejemplo
jemplo de esto puede ser el siguiente:
Requerimiento del usuario. El usuario puede realizar la consulta de las
existencias del almacn de materia prima
prima de manera remota va Internet.

En seguida se definen los principales requerimientos del usuario:

Casos de uso: representaciones grficas de las funciones de un software. Sus
elementos son el caso de uso o funcin del software, actor que es representado
por una figura de un monigote y los arcos que son lneas que relacionan al actor
y los casos de uso.
Escenarios: son descripciones del usuario de lo que se espera que el software
realice. Estas descripciones se realizan como una historieta y son consideradas
como requerimientos. Generalmente se utilizan en modelos de desarrollo giles.
Prototipos: representaciones tipo borrador de la construccin del software,
generalmente se utiliza para mostrar interfaces y su navegacin.
La segunda clasificacin son los requerimientos del sistema. Observa la siguiente
definicin de Sommerville (2011. Pg. 83): Los requerimientos del sistema son
descripciones ms detalladas de las funciones, los servicios y las restricciones
operacionales del sistema de software.
Ejemplo de requerimiento del sistema.
Todos los viernes el software generar el reporte denominado Explosin de
materiales que consiste en mostrar la materia prima que se necesitar para la
produccin de la siguiente semana. El cual deber indicar de color rojo los
materiales que debern comprarse y las cantidades para poder producir y
mantener los niveles de stock adecuados.

La manera de representar los requerimientos del sistema es el documento de

especificacin de requerimientos del software o SRS (Software Requierement
Specification), que contiene todos los requerimientos descritos con un alto nivel de
detalle. A veces forma parte del contrato entre el comprador del software y el
equipo de desarrollo.
De cualquier manera, an y con todo el cuidado que se haya tenido al detectar los
requerimientos, stos podrn presentar cambios durante el desarrollo del software.
Sin embargo, un adecuado control mantendr el proyecto dentro del margen de lo
planeado en tiempo, costo y recursos.
Los requerimientos del sistema del software se clasifican como funcionales y no
funcionales. Esta clasificacin nos servir para identificar de una mejor manera
cules requerimientos se refieren a las caractersticas para concebir el software
como un todo y cuales funciones el sistema debe realizar de manera especfica.
3.1.1. Requerimientos funcionales y no funcionales
Como se ha mencionado en el tema anterior, la redaccin de requerimientos
puede ser poco exacta, lo cual puede generar problemas en su interpretacin,
ocasionando que no se logre el entendimiento del software. Es por ello que
tenemos otra manera de clasificar los requerimientos, sta es una sub clasificacin
de los requerimientos del sistema que los divide en funcionales y no funcionales:

Diagrama de clasificacin de requerimientos y de requerimientos del sistema.

Para entender de forma clara, observa la siguiente definicin que Sommerville
(2011, pag. 84) da sobre los requerimientos funcionales. Son enunciados acerca
de servicios que el sistema debe proveer, de cmo debera reaccionar el sistema a
entradas particulares y de cmo debera comportarse el sistema en situaciones
especficas. En algunos casos, los requerimientos funcionales tambin explican lo
que no debe hacer el sistema.
Un ejemplo de requerimiento funcional sera: El software debe enviar una alerta
cuando los niveles de stock o reservas han comenzado a utilizarse y debe
sugerir generar la orden de compra.
Un requerimiento no funcional podra estar conformado por varios requerimientos
funcionales y stos generalmente son restricciones en presupuesto, polticas de la
empresa, imposiciones del gobierno, vnculos con algn otro sistema de
informacin o atributos de calidad del sistema. Estos requerimientos se refieren al
software como una sola entidad y no como un conjunto de elementos. Por
ejemplo:

El software debe estar accesible para realizar las consultas en tiempo real va
Internet las 24 horas del da los 365 das del ao.
El software debe restringir el acceso a personas ajenas a la organizacin.
Es importante comentar que, al redactar la descripcin de cada requerimiento no
funcional, ste debe cuantificarse de alguna manera ya que, de lo contrario, dicha
descripcin quedar imprecisa provocando una mala interpretacin llena de
subjetividad. Algunas expresiones comunes son las que encontramos en la
siguiente tabla que te presentamos a continuacin con dos columnas; la primera
se llama Descripcin incorrecta la cual contiene palabras o frases que
normalmente nos sentimos tentados a utilizar en la descripcin de algn
requerimiento no funcional, lo cual no debe ser as; la segunda columna llamada

Descripcin correcta ofrece ejemplos para quitar la imprecisin del

requerimiento, haciendo ste ms cuantificable, medible y por lo tanto alcanzable.

Descripcin incorrecta
Descripcin correcta
Que el software sea rpido (veloz, El tiempo de despliegue de las pginas
en tiempo real, lento)
estticas ser dado en un rango de
tiempo de <=5 segundos.
Otros
elementos
pueden
ser
transacciones, tiempos de respuesta
del usaurio, eventos, todo sobre la
unidad de tiempo.
Ser un software pequeo (grande, Se espera que el archivo que se genere
mediano)
no exceda los 10,000 KB para que
pueda ser descargado fcilmente por el
usuario desde internet.
Bits, Kb, B, KB, TB, GB, etc.
Que sea fcil de usar (sencillo, El software contar con un mdulo de
amigable, lgico)
ayuda de cada uno de los procesos y
ventanas.
Tambin se puede disminuir la
ambigedad del requerimiento indicando
que el personal ser capacitado por un
cierto periodo de tiempo estimado para
que pueda aprender a utilizarlo.
La informacin que genere debe ser El software deber realizar procesos de
fiable (veraz, oportuna)
eliminacin de registros incompletos
cuando
estos
no
hayan
sido
completados cuando el software se haya
apagado
por
fallos
elctricos.
Conservando de esta manera, solo los
registros completos.
Otras
consideraciones
son
la
probabilidad de que el sistema no est
disponible (Si se hacen respaldos o
migraciones a otro servidor).
Que el software sea robusto ( Cuando el software detecta algn error
potente)
de autentificacin, por ejemplo la prdida
de variables de sesin o cookies, lanzar
una pgina indicando al usuario que
vuelva a introducir su nmero y
contrasea.
Otros casos podran ser: indicar si se
requiere el reinicio despus de una falla
e incluso podra indicar en qu

porcentaje los datos estn corruptos por

un error o falla.
El software debe ser portable Se espera que el software pueda ser
(porttil, transportable, movible)
visible en los navegadores iExplorer v. 9,
Chrome.
La idea es que describa exactamente en
que otros sistemas o equipos debe
funcionar el software.
Tabla para describir requerimientos no funcionales.
Observa el siguiente ejemplo que demuestra un requerimiento no funcional y que
tambin se encuentra mal definido:

El software debe ser fcil de usar para el personal del almacn.

Como pudiste ver es incorrecto ya que no es posible cuantificar o medir su
cumplimiento, ahora se presentara el mismo requerimiento no funcional descrito
de forma correcta:

El personal del almacn tomar una capacitacin de 3 horas en el uso del

software, adems el software contar con videos explicando la funcionalidad del
mismo como apoyo extra.
Los requerimientos son la base del desarrollo de un sistema de software, es por
ello que se hace un especial nfasis en su obtencin, especificacin, clasificacin
y buena redaccin. Pero no siempre se cuenta con la informacin necesaria a la
mano, para ello habr que utilizar algunas tcnicas de recoleccin para identificar
y priorizar los requerimientos.