ANLISIS DE REQUERIMIENTOS

El anlisis de los requerimientos busca detectar y corregir las falencias o carencias,

transformando los requerimientos que se obtuvieron en entrevistas, solicitudes escritas, entre
otras, en condiciones apropiadas para ser tratadas en la fase de diseo.
Los principales aspectos del anlisis de los requerimientos que deben tratarse son:

Determinar los paquetes de funcionalidad y de la calidad de servicio del producto,

formulados de una forma independiente de su implementacin, y refinar y detallar estas
especificaciones hasta que den lugar a una especificacin no ambigua del producto que
se desarrolla.

Identificar los actores externos al sistema que interactan con la aplicacin de forma
relevante.

Identificar la semntica y las caractersticas de los mensajes que intercambian los

actores con el sistema que se desarrolla.

Refinar los protocolos de interaccin que usan los actores para llevar a cabo las
diferentes transacciones que se pueden realizar con el sistema.

Se trabaja en conjunto con los usuarios y los clientes.

Problemas Comunes:
No saben lo que quieren del sistema, slo en trminos generales, no conocen el
costo de sus peticiones.
Los requerimientos estn en sus trminos y con conocimientos implcitos de su
propio trabajo.
Distintos usuarios tienen distintos requerimientos, se deben encontrar todas las
fuentes.
Influyen factores polticos.
La importancia de los requerimientos vara en el tiempo.
Aparecen nuevos requerimientos.

FASES PARA EL ANLISIS DE REQUERIMIENTOS

COMPRENSIN
El analista debe desarrollar su propia comprensin del dominio de la aplicacin. Ej.: Si fuera un
sistema para un supermercado este debe evaluar cmo funciona un supermercado.
Este proceso es de vital importancia, incluso teniendo gran eficiencia en la programacin, si no
tuvimos la dedicacin de comprender lo que el cliente requiere desarrollaremos algo que quizs
puede resultar inservible, ya que obtener una solucin a un problema distinto al enfrentado
realmente no sirve de nada, por muy elaborado que sea nuestro software. Para obtener un
resultado ptimo y lograr satisfacer las solicitudes, es necesario ir ms all e indagar en la
informacin obtenida, con esto nos referimos a entender las necesidades, los objetivos, los
recursos con los que se cuenta y las operaciones, y procesos con los que, hasta el momento, ha
contado la empresa para funcionar.
CONCEPTUALIZACIN DE LOS REQUERIMIENTOS
Los sistemas interactan con su entorno externo, ya sean operadores, usuarios, otros sistemas,
dispositivos, entre otros, y la funcionalidad que deben ofrecer debe establecerse en funcin del
contexto en que interactan y con independencia de la forma en que se construyen
internamente.
Existen tres vas que pueden utilizarse para llevar a cabo esto y son las siguientes:
Descripcin del proyecto: Es un paso previo y puede parecer obvio que tiene una gran
importancia, este consiste en generar un documento que resuma de forma precisa la
informacin con respecto al proyecto que se inicia. Este debe contener la naturaleza y objetivo
del proyecto, las caractersticas importantes, su oportunidad de mercado y el anlisis de los
riesgos que presenta. Aqu se establece el punto de arranque para que todos los responsables
de su ejecucin tengan el mismo concepto de que se desarrolla.
Anlisis del contexto: Se trata de especificar las funcionalidades del sistema a travs de las
interacciones que pueda tener el sistema y el entorno externo. En esta se identifican los actores
externos que interactan con el sistema, as como los tipos de mensajes que se producen y la
informacin que transmiten.
Casos de uso: Es un recurso especfico de UML para describir la funcionalidad y las caractersticas
de calidad de servicio del sistema. Se basa en identificar los lmites del sistema a travs de la
captura de los actores, de los elementos bsicos de funcionalidad a travs de casos de uso, y de
los protocolos de interaccin a travs de diagramas de secuencia o de interaccin.
INVESTIGACIN
La investigacin en el anlisis de requerimientos es el estudio y documentacin del sistema a
crear. Combina elementos de la solucin de problemas, elaboracin, negociacin y
especificacin. Con la finalidad de potenciar un equipo colaborativo que trabaje para lograr la
identificacin del problema, proponer elementos de la solucin, negociar distintas visiones y
especificar un conjunto preliminar de requerimientos para la solucin.

DISCUSIN
La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una
evaluacin de los mismos antes de definir si son adecuados para el cliente.
En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como
referencia los niveles de abstraccin y descomposicin de cada problema presentado.
Los principales pasos de esta actividad son:
Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas de los
requerimientos estn presentes en cada uno de los ellos, es decir, se identifican aquellos
requerimientos ambiguos, incompletos, inconsistentes, etc.
Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un
requerimiento en trminos de implementacin. A esta caracterstica se le conoce como
prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de
diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las
necesidades que tenga el negocio.
En base a la prioridad, cada requerimiento puede ser clasificado como mandatorio, deseables o
innecesarios. Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si
existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un
requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para
fases posteriores, el requerimiento es catalogado como innecesario.
Una vez hecha esta categorizacin de los requerimientos, puedo tomar como estrategia general
el incluir los mandatorios, discutir los deseables y descartar los innecesarios.
Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo,
complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de
implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable.
Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (Pueden
implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales
(puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas
(ha sido aprobado por los clientes el presupuesto?).
En la actividad de negociacin, se incrementa la comunicacin entre el equipo de desarrollo y
los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay
una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

Documentar todos los requerimientos a un nivel de detalle apropiado.

Mostrar todos los requerimientos a los involucrados en el sistema.
Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.
Establecer las relaciones entre requerimientos que indiquen dependencias.
Negociar con flexibilidad para que exista un beneficio mutuo.
Enfocarse en intereses y no en posiciones.

Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema.
Se espera que una especificacin de requerimientos que fue aprobada por clientes y/o usuarios
tenga al menos las siguientes caractersticas:

Que contenga todos los requerimientos deseados.

Que cada requerimiento solo tenga una interpretacin posible (esto apunta a eliminar
ambigedades).
Que el cumplimiento de cualquier requerimiento no provoque conflictos con el
cumplimiento de otro requerimiento, es decir, que sea consistente.
Que se definan prioridades.

La discusin para el anlisis de requerimientos enfrenta diferentes enfoques de resolucin y

cada uno de estos utiliza un escenario diferente, pero para todos nos encontramos con algunos
tpicos en comn. (Ing. de Software, R.S. Pressman, Edicin 7)

Tantos ingenieros de software como otros participantes dirigen o intervienen en las

reuniones.
Se establecen reglas para la preparacin y participacin.
Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos
importantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas.
Un facilitador (cliente, desarrollador o participante externo) controla la reunin.
Se utiliza un mecanismo de definicin (que pueden ser hojas de trabajo, tablas sueltas,
etiquetas adhesivas, pizarrn electrnico, grupos de conversacin o foro virtual).

ALTERNATIVAS
An despus de los tpicos dados y de que se realice la discusin, puede ser posible que se
incurra en errores u omisiones con los requerimientos. Es por esto que lo siguiente es dar
alternativas sobre los mismos y evaluarlas segn corresponda.
Una correcta presentacin de alternativas ser el primer paso en una adecuada presentacin y
preparacin del proyecto o a una alternativa final para la solucin. Tambin, ser la base para el
documento de especificaciones tcnicas en el proceso.
Restricciones asociadas a cada alternativa
La idea es mencionar las restricciones de precio, mantencin, operacin y tecnologa que
presenta cada alternativa.
Producto o servicio esperado en cada alternativa
Debe establecerse si se espera el mismo servicio o producto por cada alternativa de solucin y
en qu consiste en trminos generales. Por ejemplo, se podra mencionar que el producto de la
alternativa seleccionada cumplir con un requerimiento especfico y que en cambio no
solucionar otro requerimiento menos importante.

ESPECIFICACIN DE REQUERIMIENTOS
Consiste en el desarrollo de un documento que de manera clara y precisa contenga y especifique
cada uno de los requerimientos del sistema. Aqu se deben especificar los requerimientos
funcionales y no funcionales en forma clara y detallada.

Tcnica o estndares de documentacin de requerimientos

Para comenzar debemos especificar que es un estndar, La definicin ms correcta seria que es
un conjunto de criterios documentados para especificar y determinar la adecuacin de un
objeto.
La documentacin puede llevarse a cabo mediante diferentes estndares que nombraremos y
definiremos a continuacin:

ISO/IEC 26514:2008
IEEE 830

ISO/IEC 26514:2008
Esta ISO est enfocada en la documentacin por parte del desarrollador del sistema y cubre la
documentacin como producto, su estructura, contenido y formato.
Dentro de esta ISO podemos encontrar 2 partes fundamentales
La primera: ayuda a establecer la informacin que los usuarios necesitan y a cmo determinar
la mejor forma en que se le debe dar la informacin al usuario
La segunda: cubre lo que es el manual del usuario cmo debe ser impreso, tutoriales y
documentacin de referencia para el usuario
IEEE 830 RSR (especificacin de requerimientos del software)
Este estndar se utiliza como un acuerdo entre el cliente y el grupo de trabajo (desarrolladores)
Estos documentos tienen por finalidad reunir los requisitos completos del cliente para poder
desarrollar un producto de acuerdo a lo que el cliente quiere y necesita.
Sus funciones principales son:

Determinar con precisin las funciones y las restricciones del software o producto
Es la base para desarrollar cualquier tipo de planificacin, diseo, codificacin, pruebas
del software y documentacin.

Sugiere la siguiente estructura para los documentos de requerimientos:

I.- Introduccin
1.1 Propsito del documento de requerimientos
1.2 Alcance del producto
1.3 Definiciones y abreviaturas
1.4 Referencias
1.5 Descripcin del resto del documento
II.- Descripcin General
2.1 Perspectiva del Producto
2.2. Funciones del Producto
2.3 Caractersticas del usuario
2.4 Restricciones generales
2.5 Suposiciones y dependencias
III.- Requerimientos especficos
Incluyen requerimientos funcionales, no funcionales y de interfaz, es la parte ms sustancial del
documento.
IV.- Apndices
V.- ndice

DOCUMENTACION DE REQUERIMIENTO DEL USUARIO

Requerimientos de usuario: Son declaraciones en lenguaje natural y diagramas de los servicios

que el sistema proporcione y de las restricciones bajo las cuales debe funcionar
Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales
y no funcionales de tal forma que sean comprensibles para los usuarios del sistema sin
conocimiento tcnico detallado nicamente deben especificar el comportamiento externo del
sistema y deben evitar, tanto como sea posible, las caractersticas del diseo del sistema
Actores que estn involucrados
Usuario Final: Son los que usan el sistema al final de todo, se relacionan con la "Accesibilidad",
la "Disponibilidad" y la "Fiabilidad" de este sistema.
Usuario Lder: Son los encargados de comprender el dominio del problema en el cual ser
empleado el software, proporcionan al equipo de trabajo los detalles y requerimientos de las
interfaces del sistema.
Personal de mantenimiento: Bsicamente lo que hacen es revisar y mejorar los procesos del
producto que ya est finalizado.
Analistas y programadores: Son las personas responsables de desarrollar el producto, ellos
interactan directamente con el cliente.
Personal de pruebas: Se encargan de elaborar y ejecutar el "plan de pruebas", se aseguran de
que las condiciones presentadas por el sistema sean las ms adecuadas. Tambin son los que
validan los requerimientos, viendo que satisfagan las necesidades del cliente.
Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto
pueden ser:

Administradores de proyecto
Documentadores
Diseadores de bases de datos

DOCUMENTACION DE REQUERIMIENTO DEL SISTEMA

Establecen con detalle los servicios y restricciones del sistema.

El documento de requerimientos del sistema, algunas veces denominado especificacin
funcional, debe ser preciso.
Este sirve como un contrato entre el comprador del sistema y el desarrollador
Del software.
Son descripciones ms detalladas de los requerimientos del usuario. Sirve como base para
definir el contrato de la especificacin del sistema y por lo tanto debe ser una especificacin
completa consistente del sistema. Son utilizados por los ingenieros de software como el punto
de partida para el diseo de sistema.
La especificacin de requerimientos del sistema incluye diferentes modelos del sistema como el
de objetos o el de flujo de datos.

VALIDACIN DE REQUERIMIENTOS
Proceso por el cual se determina si la especificacin es consistente con las necesidades del
cliente.
Incluye verificar trazabilidad entre la especificacin y el documento de requerimientos.
Se trabaja con un bosquejo completo del documento a diferencia de la verificacin del Anlisis.
Se realizan las siguientes verificaciones en el documento de requerimientos:
Validez: compromiso con el usuario, que valide que es lo que quiere.
Consistencia: que no haya contradicciones.
Realismo: que se puedan implementar (incluye: tecnologa, presupuesto y
calendario).
Verificabilidad: Disear conjunto de pruebas para demostrar que el sistema
cumple esos requerimientos.
La validacin de requerimientos sirve para demostrar que stos realmente definen el sistema
que el cliente desea. Asegura que los requerimientos estn completos, son exactos y
consistentes. Debe garantizar que lo descrito es lo que el cliente pretende ver en el producto
final. Esta validacin es importante porque la deteccin de errores durante el proceso de anlisis
de requerimientos reduce mucho los costos. Si se detecta un cambio en los requerimientos una
vez que el sistema est hecho, los costos son muy altos, ya que significa volver a cambiar el
diseo, modificar la implementacin del sistema y probarlo nuevamente.

TCNICAS DE VALIDACIN DE REQUERIMIENTO

Tcnicas del requerimiento desde punto de vista de la forma o funcional.
Prototipo:
Los prototipos de interfaz de usuario se pueden utilizar para explorar un diseo alcanzable y
adecuado que cumpla los requisitos, ayudando a reducir las distancias entre lo que es necesario
(expresado a travs de la adquisicin de requisitos) y lo que es factible.
El objetivo principal de la creacin de un prototipo de interfaz de usuario, es poder probar el
diseo de interfaz de usuario, incluyendo la capacidad de utilizacin antes de que empiece el
desarrollo real. De este modo, puede garantizar que est construyendo el sistema correcto,
antes de dedicar demasiado tiempo y recursos al desarrollo.

TCNICAS DEL REQUERIMIENTO DESDE EL PUNTO DE VISTA DE CONTENIDO O NO FUNCIONAL.

Casos de Prueba:
El recorrido o walkthrough, es una tcnica de revisin de productos tradicionalmente asociada
a la inspeccin de cdigo fuente. Su principal objetivo es encontrar conflictos en el producto que
se revisa, de forma que puedan plantearse alternativas y los participantes aumenten su
conocimiento del producto en cuestin.
Durante las sesiones de recorrido, el autor del producto recorre el producto a revisar en detalle,
permitiendo que los participantes pongan de manifiesto sus opiniones sobre el mismo.
Para ser ms especficos sobre el tema informtico, vamos hacer referencia a que existe una
norma que regula la validacin de los requerimientos de un proyecto de software y sealaremos
las tcnicas que estn presentes en este estndar.

TCNICAS DE VALIDACIN Y VERIFICACIN DE REQUERIMIENTOS DE UN SOFTWARE SEGN

ESTNDAR IEEE729:

Inspecciones de Software
Analizan y comprueban las representaciones del sistema (los diagramas de diseo, el cdigo
fuente del programa). Se aplica a todas las etapas del proceso de desarrollo y se complementan
con algn tipo de anlisis automtico del texto fuente y documentos asociados. Son tcnicas de
verificacin y validacin estticas, no requieren que el sistema se ejecute. (Ceniceros, 2012)

Pruebas de Software:
Consisten en comparar datos tericos con los resultados del software utilizando series de datos
de prueba, se examinan los resultados del software y su comportamiento operacional para
comprobar que se desempee conforme a lo requerido. Es una tcnica dinmica de la
verificacin y validacin ya que requiere disponer de un prototipo ejecutable del sistema.
(Ceniceros, 2012)
10

Proceso de Depuracin:

Es un proceso independiente que no tiene por qu estar integrado:

La verificacin y validacin establece la existencia de defectos en el programa.

La depuracin es el proceso que localiza el origen y corrige estos defectos.

Localizar los fallos es un proceso complejo porque los fallos no necesariamente se localizan cerca
del punto en que se detectan. Para localizar un fallo de un programa el programador responsable
de la depuracin tiene que disear programas de prueba adicionales que repitan el fallo original
y que ayudan a descubrir el origen del fallo.

Despus de que se descubre el origen del fallo en el programa, este debe corregirse y entonces
reevaluar el sistema. Esto implica repetir de nuevo las pruebas anteriores (pruebas de
regresin). Estas pruebas se hacen para comprobar que los cambios introducidos resuelven
definitivamente el fallo y no introducen nuevos fallos. La estadstica muestra que la reparacin
de un fallo frecuentemente es incompleta y adems introduce nuevos fallos. (Drak & Lopez,
2014)

11