Qu son Requerimientos?

Normalmente, un tema de la Ingeniera de Software tiene diferentes significados.

De las muchas definiciones que existen para requerimiento, ha continuacin se
presenta la definicin que aparece en el glosario de la IEEE .
(1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar
un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema
o componentes de sistema para satisfacer un contrato, estndar, especificacin u
otro documento formal. (3) Una representacin documentada de una condicin 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 caractersticas 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, estndares, etc.
Caractersticas de los requerimientos
Las caractersticas de un requerimiento son sus propiedades principales. Un
conjunto de requerimientos en estado de madurez, deben presentar una serie de
caractersticas tanto individualmente como en grupo. A continuacin se presentan
las ms importantes.
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia
en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin
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
redaccin, es decir, si se proporciona la informacin suficiente para su
comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de
manera que permita hacer uso de los siguientes mtodos de verificacin:
inspeccin, anlisis, demostracin o pruebas.

* Dificultades para definir los requerimientos *

Los requerimientos no son obvios y vienen de muchas fuentes.
Son difciles 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 difcil de manejar.
Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o
ms estables que otros.
Los requerimientos estn relacionados unos con otros, y a su vez se relacionan
con otras partes del proceso.
Cada requerimiento tiene propiedades nicas y abarcan reas funcionales
especficas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular
para cada proyecto.

* Ingeniera de Requerimientos vs. Administracin de Requerimientos *

El proceso de recopilar, analizar y verificar las necesidades del cliente para un
sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de
requerimientos (IR) es entregar una especificacin 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 usarn en l. Los lderes de proyecto
usan los requerimientos como una base para la estimacin del esfuerzo necesario
en un proyecto.
Especificar el tipo de verificaciones que se habrn de realizar al sistema. Por
ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estndar.
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 documentacin del sistema
De ah su importancia y la importancia de que deban de ser definidos y manejados
de la forma mas adecuada posible.
Caractersticas de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de
software entonces debemos de definir que caractersticas 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 cmo sabemos si cumplimos con l o no?
Descritos como una caracterstica del sistema a entregar. Esto es: que es lo que el
sistema debe de hacer (y no como debe de hacerlo)
Lo ms abstracto y conciso posible. Para evitar malas interpretaciones.


* Fundamentos del Anlisis de Requerimientos *

Definicin: Es el conjunto de tcnicas y procedimientos que nos permiten conocer
los elementos necesarios para definir un proyecto de software.
Es la etapa ms crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condicin o capacidad de un sistema requerida por el usuario para
resolver un problema o alcanzar un objetivo.
No Funcionales: Condicin o capacidad que debe poseer un sistema par satisfacer
un contrato, un estndar, una especificacin u otro documento formalmente
impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificacin
completa de los requerimientos de los mismos. Independientemente de lo bien
diseado o codificado que est, un programa pobremente especificado
decepcionar al usuario y har fracasar el desarrollo.
La tarea de anlisis de los requerimientos es un proceso de descubrimiento y
refinamiento, El mbito del programa, establecido inicialmente durante la
ingeniera 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
especificacin de requerimientos. El cliente intenta reformular su concepto, algo
nebuloso, de la funcin y comportamiento de los programas en detalles concretos,
El que desarrolla el software acta como interrogador, consultor y el que resuelve
los problemas.
El anlisis y especificacin de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engaan. Puesto que el contenido de
comunicacin es muy alto, abundan los cambios por mala interpretacin o falta de
informacin. El dilema con el que se enfrenta un ingeniero de software puede ser
comprendido repitiendo la sentencia de un cliente annimo: "S que crees que
comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que
creste or sea lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su conjunto son
extensos y detallados, y adems contienen mltiples 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 anlisis de requerimientos es la tarea que plantea la asignacin de software a
nivel de sistema y el diseo de programas. El anlisis de requerimientos facilita al
ingeniero de sistemas especificar la funcin y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y establecer las ligaduras de
diseo que debe cumplir el programa. El anlisis de requerimientos permite al
ingeniero refinar la asignacin de software y representar el dominio de la
informacin que ser tratada por el programa. El anlisis de requerimientos de al
diseador la representacin de la informacin y las funciones que pueden ser
traducidas en datos, arquitectura y diseo procedimental. Finalmente, la
especificacin de requerimientos suministra al tcnico y al cliente, los medios para
valorar la calidad de los programas, una vez que se haya construido.

* Tareas del Anlisis *

El anlisis de requerimientos puede dividirse en cuatro reas:
1.- Reconocimiento del problema
2.- Evaluacin y sntesis
3.- Especificacin
4.- Revisin.

Inicialmente, el analista estudia la especificacin 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 planificacin. A
continuacin, debe establecerse la comunicacin necesaria para el anlisis, de
forma que se asegure el reconocimiento del problema.

El analista debe establecer contacto con el equipo tcnico y de gestin 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 comunicacin. El objetivo del analista es reconocer los elementos
bsicos del programa tal como lo percibe el usuario / cliente.

La evaluacin del problema y la sntesis de la solucin es la siguiente rea
principal de trabajo del anlisis. El analista debe evaluar el flujo y estructura de la
informacin, refinar en detalle todas las funciones del programa, establecer las
caractersticas de la interfase del sistema y descubrir las ligaduras del diseo,
Cada una de las tareas sirven para descubrir el problema de forma que pueda
sintetizarse un enfoque o solucin global.

Las tareas asociadas con el anlisis y especificacin existen para dar una
representacin del programa que pueda ser revisada y aprobada por el cliente. En
un mundo ideal el cliente desarrolla una especificacin de requerimientos del
software completamente por s mismo. Esto se presenta raramente en el mundo
real. En el mejor de los casos, la especificacin se desarrolla conjuntamente entre
el cliente y el tcnico.
Una vez que se hayan descrito las funcionalidades bsicas, comportamiento,
interfase e informacin, se especifican los criterios de validacin para demostrar
una comprensin de una correcta implementacin de los programas. Estos
criterios sirven como base para hacer una prueba durante el desarrollo de los
programas. Para definir las caractersticas y atributos del software se escribe una
especificacin de requerimientos formal. Adems, 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
ingeniera humana y frecuentemente produce el comentario: "La idea es correcta
pero esta no es la forma en que pens que se podra hacer esto". Es mejor
descubrir tales comentarios lo ms tempranamente posible en el proceso.
Los documentos del anlisis de requerimiento (especificacin y manual de
usuario) sirven como base para una revisin conducida por el cliente y el tcnico.
La revisin de los requerimientos casi siempre produce modificaciones en la
funcin, comportamiento, representacin de la informacin, ligaduras o criterios de
validacin. Adems, se realiza una nueva apreciacin del plan del proyecto de
software para determinar si las primeras estimaciones siguen siendo validas
despus del conocimiento adicional obtenido durante el anlisis.

* Obteniendo de la informacin *

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 lgico que para recabarlos haya que obtener la informacin de primera mano.
Esto es, mediante entrevistas con el cliente o recabando documentacin 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
documentacin original del cliente, as como cada revisin o cambio que se haga a
esta documentacin. Como cada necesidad del cliente es tratada de diferente
forma, es necesario clasificar estas necesidades para saber cuales de ellas sern
satisfechas por el software y cuales por algn otro producto del sistema.

* Especificacin de Requisitos de Software *(SRS)

La especificacin de requisitos de software es la actividad en la cual se genera el
documento, con el mismo nombre, que contiene una descripcin completa de las
necesidades y funcionalidades del sistema que ser desarrollado; describe el
alcance del sistema y la forma en como har sus funciones, definiendo los
requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software,
diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte
y gua para fases posteriores.
Es importante destacar que la especificacin de requisitos es el resultado final de
las actividades de anlisis y evaluacin de requerimientos; este documento
resultante ser utilizado como fuente bsica de comunicacin entre los clientes,
usuarios finales, analistas de sistema, personal de pruebas, y todo aquel
involucrado en la implementacin del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se est
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe desarrollarse. El
personal de pruebas elaborar las pruebas funcionales y de sistemas en base a
este documento. Para el administrador del proyecto sirve como referencia y control
de la evolucin del sistema.
La SRS posee las mismas caractersticas de los requerimientos: completa,
consistente, verificable, no ambigua, factible, modificable, rastreable, precisa,
entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno de
los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere
verificable, cada requerimiento definido en ella debe ser verificable; para que una
SRS se considere modificable, cada requerimiento debe ser modificable y as
sucesivamente. Las caractersticas de la SRS son verificadas en la actividad de
Validacin, descrita en el punto.
La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a
facilitar la lectura y escritura de la misma. Ser un documento familiar para todos
los involucrados, adems de asegurar que se cubren todos los tpicos
importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de
crear su propia plantilla.
Clasificacin de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay requerimientos que
por sus caractersticas no pueden ser tratados iguales.
La siguiente es una recomendacin de como pueden ser clasificados los
requerimientos aunque cada proyecto de software pueda usar sus propias
clasificaciones.
Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el
entorno, existen cierto tipo de requerimientos que se clasifican en esta categora
por que:
El sistema usa el entorno y lo necesita como una fuente de los servicios
necesarios para que funcione. Ejemplos del entorno podemos mencionar:
sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el
entorno, tales como congestin en los dispositivos y errores de entrada de datos,
por lo tanto el entorno se debe de considerar dentro de los requerimientos.
Requerimientos "ergonmicos"
l mas conocido de los requerimientos ergonmicos es la interfase con el usuario
o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonmicos
son la forma en que el ser humano interacta con el ser sistema.
Requerimientos de Interfase
La interfase es como interacta el sistema con el ser humano o con otros sistemas
(el enfoque es prcticamente el opuesto a los requerimientos ergonmicos), La
interfase es la especificacin formal de los datos que el sistema recibe o manda al
exterior. Usualmente se especifica el protocolo, el tipo de informacin, el medio
para comunicarse y el formato de los datos que se van a comunicar.
* Actividades de la Ingeniera de Requerimientos *

En el proceso de IR son esenciales diversas actividades. En este documento
sern presentadas, sin embargo, en un proceso de ingeniera de requerimientos
efectivo, estas actividades son aplicadas de manera continua y en orden variado.
Dependiendo del tamao del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero
como en nombres. La tabla #1 muestra algunos ejemplos de las actividades
identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el
conjunto de actividades mostradas en la tabla anterior, podemos identificar y
extraer cinco actividades principales que son:
Anlisis del Problema
Evaluacin y Negociacin
Especificacin
Validacin
Evolucin
* Principios de Especificacin *

La especificacin, independientemente del modo en que se realice, puede ser
vista como un proceso de representacin. Los requerimientos se representan de
forma que conduzcan finalmente a una correcta implementacin del software.
Baltzer y Goldman proponen ocho principios para una buena especificacin:

PRINCIPIO #1. Separar funcionalidad de implementacin.
Primero, por definicin, una especificacin es una descripcin de lo que se desea,
en vez de cmo se realiza (implementa). Las especificaciones pueden adoptar dos
formas muy diferentes. La primera forma es la de funciones matemticas: dado
algn conjunto de entrada, producir un conjunto particular de salida. La forma
general de tales especificaciones es encontrar [un/el/todos] resultado tal que P
(entrada), donde P representa un predicado arbitrario. En tales especificaciones, el
resultado a ser obtenido ha sido expresado enteramente en una forma sobre el
que (en vez de cmo). En parte, esto es debido a que el resultado es una funcin
matemtica de la entrada (la operacin tiene puntos de comienzo y parada bien
definidos) y no esta afectado por el entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificacin de sistemas orientado al
proceso.
Considerar una situacin en la que el entorno sea dinmico y sus cambios afecten
al comportamiento de alguna entidad que interacte con dicho entorno. Su
comportamiento no puede ser expresado como una funcin matemtica de su
entrada. En vez de ello, debe emplearse una descripcin orientada al proceso, en
la cual la especificacin del que se consigue mediante la especificacin de un
modelo del comportamiento deseado en trminos de respuestas funcionales, a
distintos estmulos del entorno.
PRINCIPIO #3. Una especificacin debe abarcar el sistema del cual el software es
una componente.
Un sistema esta compuesto de componentes que interactan. Solo dentro del
contexto del sistema completo y de la interaccin entre sus partes puede ser
definido el comportamiento de una componente especifica. En general, un sistema
puede ser modelado como una coleccin de objetos pasivos y activos. Estos
objetos estn interrelacionados y dichas relaciones entre los objetos cambian con
el tiempo. Estas relaciones dinmicas suministran los estmulos a los cuales los
objetos activos, llamados agentes, responden. Las respuestas pueden causar
posteriormente cambios y, por tanto, estmulos adicionales a los cuales los
agentes deben responder.
PRINCIPIO #4. Una especificacin debe abarcar el entorno en el que el sistema
opera.
Similarmente, el entorno en el que opera el sistema y con el que interacta debe
ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un
sistema compuesto de objetos que interactan, pasivos y activos, de los cuales el
sistema especificado es una agente, Los otros agentes, los cuales son por
definicin inalterables debido a que son parte del entorno, limitan el mbito del
diseo subsecuente y de la implementacin. De hecho, la nica diferencia entre el
sistema y su entorno es que el esfuerzo de diseo e implementacin subsecuente
opera exclusivamente sobre la especificacin del sistema. La especificacin del
entorno facilita que se especifique la interfaz del sistema de la misma forma que el
propio sistema, en vez de introducir otro formalismo.
PRINCIPIO #5. Una especificacin de sistema debe ser un modelo cognitivo.
La especificacin de un sistema debe ser un modelo cognitivo, en vez de un
modelo de diseo o implementacin. Debe describir un sistema tal como es
percibido por su comunidad de usuario. Los objetivos que manipula deben
corresponderse con objetos reales de dicho dominio; los agentes deben modelar
los individuos, organizaciones y equipo de ese dominio; y las acciones que
ejecutan deben modelar lo que realmente ocurre en el dominio. Adems, debe ser
posible incorporar en la especificacin las reglas o leyes que gobiernan los objetos
del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal
como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por
tanto limitan el comportamiento de los agentes o indican la necesidad de una
posterior elaboracin para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificacin debe ser operacional.
La especificacin debe ser completa y lo bastante formal para que pueda usarse
para determinar si una implementacin propuesta satisface la especificacin de
pruebas elegidas arbitrariamente. Esto es, dado el resultado de una
implementacin sobre algn conjunto arbitrario de datos elegibles, debe ser
posible usar la especificacin para validar estos resultados. Esto implica que la
especificacin, aunque no sea una especificacin completa del como, pueda
actuar como un generador de posibles comportamientos, entre los que debe estar
la implementacin propuesta. Por tanto, en un sentido extenso, la especificacin
debe ser operacional.
PRINCIPIO #7. La especificacin del sistema debe ser tolerante con la
incompletitud y aumentable.
Ninguna especificacin puede ser siempre totalmente completa. El entorno en el
que existe es demasiado complejo para ello. Una especificacin es siempre un
modelo, una abstraccin, de alguna situacin real (o imaginada). Por tanto, ser
incompleta. Adems, al ser formulad existirn muchos niveles de detalle. La
operacionalidad requerida anteriormente no necesita ser completa. Las
herramientas de anlisis empleadas para ayudar a los especificadores y para
probar las especificaciones, deben ser capaces de tratar con la incompletitud.
Naturalmente esto debilita el anlisis, el cual puede ser ejecutado ampliando el
rango de comportamiento aceptables, los cuales satisfacen la especificacin, pero
tal degradacin debe reflejar los restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificacin debe ser localizada y dbilmente acoplada.
Los principios anteriores tratan con la especificacin como una entidad esttica.
Esta surge de la dinmica de la especificacin. Debe ser reconocido que aunque
el principal propsito de una especificacin sea servir como base para el diseo e
implementacin de algn sistema, no es un objeto esttico precompuesto, sino un
objeto dinmico que sufre considerables modificaciones. Tales modificaciones se
presentan en tres actividades principales: formulacin, cuando se est creando
una especificacin inicial; desarrollo, cuando la especificacin se esta elaborando
durante el proceso iterativo de diseo e implementacin; y mantenimiento, cuando
la especificacin se cambia para reflejar un entorno modificado y / o
requerimientos funcionales adicionales.
Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es importante que
se describa l Qu? Y no l Cmo?. Estos requerimientos al tiempo que avanza
el proyecto de software se convierten en los algoritmos, la lgica y gran parte del
cdigo del sistema.
Requerimientos de desempeo
Estos requerimientos nos informan las caractersticas de desempeo que deben
de tener el sistema. Que tan rpido?, Que tan seguido?, Cuantos recursos?,
Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de tiempo
real en donde el desempeo de un sistema es tan crtico como su funcionamiento.
Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad,
flexibilidad, contabilidad y capacidad de actualizacin. Este tipo de requerimientos
es tambin muy importante en sistemas de tiempo real puesto que estos sistemas
manejan aplicaciones crticas que no deben de estar fuera de servicio por periodos
prolongados de tiempo.
Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el sistema.
Que tipo de usuarios son?, Que tipo de operadores?, Que manuales se
entregarn y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de
cdigo dentro del sistema, son muy importantes en el proceso de diseo ya que
facilitan la introduccin y aceptacin del sistema en donde ser implementado.
Restricciones de diseo
Muchas veces las soluciones de un sistema de software son normadas por leyes o
estndares, este tipo de normas caen como "restricciones de diseo".
Materiales
Aqu se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de industrializacin del
sistema.

* Manejo de requerimientos *

De acuerdo con el "Capability Maturity Model" (CMM), el manejo de
requerimientos involucra:
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos del
proyecto de software. Este acuerdo son los requerimientos del sistema alojados al
software." ". Este acuerdo cubre requerimientos tcnicos y no tcnicos (como
fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y
monitorear el proyecto de desarrollo de software a travs de todo su ciclo de vida."
"Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma
las medidas necesarias para que los requerimientos que estn bajo su
responsabilidad estn documentados y controlados"
De que manera podemos controlar los requerimientos de software si estos
siempre evolucionan con el tiempo?. El CMM nos proporciona las guas para
lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos revisa los
requerimientos antes de que estos sean incorporados al proyecto de software y
cada vez que los requerimientos cambian los planes, productos, y actividades son
ajustadas para quedar en lnea con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de
requerimientos dbenos de tomar en cuenta dos cosas.
Que los requerimientos deben de ser revisados (y aprobados) por el grupo de
requerimientos, y no son impuestos por en su totalidad por presiones externas
ajenas al proyecto.
El requerimiento tcnico podr ser impuesto por el mercado o presiones de la
competencia, pero entonces los requerimientos no tcnicos (Calidad, Costo y
Tiempo de entrega) debern estar especificados de comn acuerdo con el grupo
de requerimientos del proyecto de software.
Los requerimientos tcnicos y no tcnicos forman un conjunto entre s, si cambia
uno forzosamente debern cambiar los dems. Esto es: ms contenido tcnico
implica o ms costo, o menos calidad o ms tiempo estimado de entrega. De
modo que los cambios tcnicos debern ser aprobados por el grupo de
requerimientos y este grupo estimar los impactos en tiempo, costo, calidad. El
resultado de la estimacin es la entrada a los lderes del proyecto para decidir si el
cambio se acepta o no.

* ORGANIZACIN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *

Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades
de los usuarios, lo cual no resulta posible si no integra y pone al alcance del
consumidor de forma comprensible los fundamentos de todos los aspectos del
desarrollo. Para captar las necesidades especficas de los usuarios es
indispensable que los documentos que recogen los requerimientos se redacten
utilizando mtodos pragmticos.
Se debe utilizar una metodologa detallada de definicin de los requerimientos de
usuario. Organizar entrevistas destinadas a obtener la mxima informacin posible
acerca de los requerimientos de los usuarios. Traducir las oportunidades /
necesidades en requerimientos del proyecto. Comprender el perfil y entorno del
usuario. Evaluar el flujo de trabajo. Crear un documento de requerimientos
generales. Conseguir la participacin y confirmacin del usuario.
Los gerentes y usuarios del sistema tambin poseen un papel importante en le
diseo del sistema; no es solamente el proyecto del analista. Durante el diseo, a
algunos se les pide que revisen los borradores de los informes, que examinen los
formatos de entrada y que ayuden en la escritura de los procedimientos para
decirles a otras personas como utilizar el sistema en forma apropiada.
La participacin del usuario proporciona al analista una retroalimentacin
importante conforme avanza en el diseo; adems asegura a los usuarios tengan
un conocimiento no tcnico de lo realizara o no el nuevo sistema.
Esta visin general del diseo de sistemas subraya los aspectos de diseo que se
vern mas adelante en el diseo de la salida de sistema.

* REQUERIMIENTOS DEL SISTEMA *

Los Sistemas de Informacin por computadora normalmente estn integrados por
muchos componentes. En la mayor parte de los casos, es difcil para los analistas
entender todos estos componentes an mismo tiempo; por lo tanto los
investigadores tienen que comenzar con preguntas de tipo general con relacin al
propsito del sistema sus entradas y salidas de los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una
investigacin en forma seccionada que la distribuye entre ellos mismos, de
manera que cada uno pueda trabajar en forma independiente.
Existen dos estrategias ampliamente utilizadas para determinar los requerimientos
de informacin. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Anlisis de Decisin para el Conocimiento para los Sistema de
Informacin.

* Estrategia del Flujo de Datos *

Cuando se siguen un flujo a travs de los procesos de negocio, que es el
propsito del anlisis del flujo de datos, le indica a los analistas una gran cantidad
de datos sobre como s esta llevando a cabo los objetivos de la compaa. Al
manejar las transacciones y completar las tareas, los datos de entrada se
procesan, almacenan, consultan, utiliza, modifica y se emiten.
El anlisis de flujo de datos que muestra el estudio y el uso de cada actividad,
documenta los hallazgos en los diagramas de flujo de datos.

* Estrategia del Anlisis de Decisiones *

La estrategia del anlisis de decisiones es un complemento del anlisis del flujo de
datos. Esta estrategia realza el estudio de los objetivos de una operacin y de las
decisiones que deben realizarse para cumplir con los objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de alto
nivel gerencial, la estrategia de anlisis de decisin con frecuencia utiliza por parte
de alta gerencia para desarrollar la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de decisiones,
en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja
de forma diferente a la opcin que toma un supervisor de departamento para
aceptar o rechazar pedidos.
La decisin de rechazar pedidos generalmente ocurre con ms frecuencia, de
manera que las condiciones y acciones normalmente se conocen como un
aspecto importante.

* Etapas en la Estrategia del Anlisis del Flujo de Datos *

1. - Estudiar las operaciones y procesos en marcha.
2. - Identificar cmo se procesan los datos al manejar transacciones y terminar las
tareas.
3. - Seguir el flujo de datos:
* Proceso
* Almacenamiento
* Recuperacin
* Salida
4. - Aadir gradualmente detalles a los niveles inferiores.
Etapas en la Estrategia del Anlisis de Decisin
1. -Estudiar los objetivos y decisiones necesarias.
2. - Desarrollar un modelo del proceso de decisin.
3. - Probar el modelo con datos de prueba.
4. - Identificar los requerimientos del proceso para los datos.

* Requerimientos De Entrada *

Es el enlace que une al sistema de informacin con el mundo y sus usuarios, en
esta existen aspectos generales que todos los analistas deben tener en cuenta
estos son:
Objetivos del Diseo de Entrada.
Captura de Datos para la Entrada.

Objetivo del Diseo de Entrada
Consiste en el desarrollo de especificaciones y procedimientos para la preparacin
de datos, la realizacin de los procesos necesarios para poner los datos de
transaccin en una forma utilizable para su procesamiento as como la entrada de
los datos se logra al instruir a la computadora para que lea ya sea documentos
escritos, impresos por personas que los escriben directamente al sistema.
Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los
retrasos, controlar los errores y mantener la sencillez de los pasos necesarios,
estos son:
Control de la Calidad de Entrada
Evitar los Retrasos
Evitar los errores en los datos
Evitar los pasos adicionales
Mantener la Sencillez del Proceso
Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseador debe controlar la
cantidad de datos en la entrada:
- Las Operaciones de preparacin y entrada dependen de las personas dado que
los costos de mano de obra son altos y la preparacin de ingreso de los datos
tambin lo son.
-
La fase de entrada puede ser un proceso lento que toma mucho ms tiempo que
el que necesitan las computadoras para realizar sus tareas.

Evitar los Retrasos:
Tambin conocido con el nombre de cuello de botella son siempre uno de los
objetivos que el analista evita al disear la entrada, una forma de evitarle es
utilizar los documentos de retorno.

Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre ms pequea
sea esta menores sern las oportunidades para cometer errores. Es comn
encontrar en las operaciones de ventas por lo menos un 3% de errores en las
operaciones de entrada de datos.
Evitar los Pasos Adicionales:
Algunas veces el volumen de transacciones y la cantidad de datos en preparacin
es algo que no se puede controlar por ello el analista experimentado, evitara
diseos para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea
aadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso
de un da.

Mantener la sencillez del Proceso:
El sistema mejor diseado se ajusta a las personas que lo utilizarn y al mismo
tiempo proporcionarn mtodos para el control de los errores, la simplicidad
funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios
acepten sistemas complejos o confusos y que no exista ninguna garanta para el
xito al instalar un sistema complejo y que domine.
Captura de Datos para la Entrada:
En una transaccin existen datos importantes y otros que no, el analista debe
saber cuales utilizar y cuales en realidad deben formar la entrada. Existen dos
tipos de datos:
datos variables
datos de identificacin
Datos Variables:

Son aquellos que cambian para cada transaccin o toman de decisin.
Datos de Identificacin:
Estos son los que identifican en forma nica el artculo que esta siendo
procesado.

* Requerimientos De Salida *

Niveles de diseo
El diseo de sistema se representa a travs de dos fases: el diseo lgico y el
diseo fsico.
Cuando los analistas formulan un diseo lgico; escriben las especificaciones
detalladas del nuevo sistema; esto es, describen sus caractersticas: las salidas,
entradas, archivos y bases de datos y procedimientos; todos de manera que
cubran los requerimientos del proyecto.
El diseo lgico de un sistema de informacin es como el plano de un ingeniero
para armar un automvil: muestra las caractersticas principales(motor,
transmisin y rea para los pasajeros)y como se relacionan unas con otras(donde
se conectan entre s los componentes del sistema, o por ejemplo, cuan separadas
estn las puertas.
Los informes y la produccin del analista son los componentes de todo el
mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y
entonces se produce un sistema que trabaje.
El diseo lgico tambin especifica las formas de entrada y las descripciones de
las pantallas de todas las transacciones y archivos a fin de mantener los datos de
inventario, los detalles de las transacciones y los datos del proveedor. Las
especificaciones de los procedimientos describen mtodos para introducir los
datos, corridas de informes copiados de archivos y deteccin de problemas.
El diseo fsico, actividad que sigue el diseo lgico, produce programas de
software, archivos y un sistema en marcha, las especificaciones del diseo indican
a los programadores que debe hacer el sistema. Los programadores a su vez
escriben los programas que aceptan entradas por parte de los usuarios, procesan
los datos, producen los informes y almacenan estos datos en los archivos.
Utilizacin de los Datos de Requerimientos:
El alcance del diseo de sistemas se gua por el marco de referencia para el
nuevo sistema desarrollado durante el anlisis. Los datos de los requerimientos,
recopilados durante la investigacin, conforman las actividades y componentes del
sistema. Los analistas formulan un diseo lgico que apoya los procesos y
decisiones, los contenidos del sistema pueden cambiar como resultado de un
nuevo diseo.
El diseo lgico va de arriba hacia abajo, como lo hizo la determinacin de
requerimientos.
En primer lugar se identifican las caractersticas generales, como informes y
entradas; en el diseo de la salida por ejemplo, los analistas deben conocer la
longitud de campo de un dato especfico para establecer cuanto espacio dejar en
la informacin, en la pantalla de despliegue visual o archivo.
A lo largo de los aos hemos visto una evolucin de ideas y tcnicas en el campo
del anlisis de sistemas. La cual cabe en tres perodos amplios segn Yourdon:
1. El anlisis de sistema convencional, anterior a los aos 70s, caracterizado por
especificaciones tipo novela victoriana que eran difciles de leer y entender, y casi
imposibles de mantener.
2. El anlisis estructurado clsico, de mediados de los aos 70s, a mediados de
los aos 80s. Esto se caracteriz por primeras versiones de modelos grficos, y
nfasis en el modelado de las implementaciones actuales de un sistema antes de
modelar el nuevo.
3. El anlisis estructurado moderno, en el cual se introducen mejoras sobre todo
para modelar sistemas de tiempo real y relaciones de situaciones complejas.
Aumentando por ende la comunicacin entre el analista y el sistema.
En la actualidad las tcnicas modernas estn siendo fusionadas, para as lograr un
mejor mtodo que pueda hacerle frente a las necesidades de las diferentes fases
del ciclo de vida del sistema, incluyendo a la fase de anlisis. Obteniendo de est
manera mejores resultados que pueda interpretar el analista en forma rpida y
precisa.
En primera instancia debemos decir que el anlisis estructurado segn Senn
"permite al analista conocer un sistema o proceso (actividad) en una forma lgica y
manejable al mismo tiempo que proporciona la base para asegurar que no se
omite ningn detalle pertinente". El objetivo que persigue el anlisis estructurado
es organizar las tareas asociadas con la determinacin de requerimientos para
obtener la comprensin completa y exacta de una situacin dada. Se puede decir
adicionalmente que los componentes del anlisis estructurado son los siguientes:
smbolos grficos, diccionarios de datos, descripciones de procesos y
procedimientos, reglas.
Despus de relacionarnos brevemente con la terminologa bsica, podemos entrar
en aspectos relacionados con los cambios del anlisis estructurado.
Podemos decir que para finales de los aos 60s e inicios de los 70s el anlisis
estructurado surge de la necesidad de buscar una forma interpretativa ms rpida
y eficiente, de tal manera que se pudiesen definir los requerimientos del usuario y
las especificaciones funcionales del sistema. Pero esto no se daba porque lo que
exista eran grandes volmenes de informacin que haba que leer por completo y
que acarreaban una serie de problemas de: monolitismo, redundancia,
ambigedad e imposibilidad de mantener. Es por ello que surge una amplia
variedad de diagramas que permiten representar las especificaciones funcionales
en forma sencilla y rpida, aumentando por ende el grado de comunicacin entre
las especificaciones funcionales y el usuario final (analista, programador,
diseador).
Posteriormente, a mediados de los aos 70s estando el anlisis estructurado
clsico en su apogeo aparecen una serie de dificultades que limitan al analista
hacer un buen desempeo de sus actividades. Entre estos problemas segn
Yourdon podemos mencionar:
Distincin difusa y poca, definida entre los modelos lgicos y los modelos fsicos.
Limitacin para modelar sistemas en tiempo real.
El modelo de datos se haca de una manera primitiva.

Estas y otras razones dieron nacimiento a ciertas mejoras en el anlisis
estructurado clsico tales como: diagramas de entidad-relacin, diagramas de
transicin de estados, divisin de eventos, modelos esenciales y modelos de
implantacin. Pero a pesar de esto segn Yourdon se siguieron dando ms
problemas como los siguientes:
Tras la segunda y tercera correcciones de un diagrama, el analista se volva
cada vez ms apuesto y renuente a hacer ms cambios.
Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el
modelo del sistema en modelos de menor nivel, quedando por ende, funciones
primitivas.
A menudo no se incorporaban en el modelo del sistema los cambios en los
requerimientos del usuario sino hasta despus de la fase de anlisis del proyecto.
Inclusive las correcciones de los diagramas haba que hacerlas en forma manual,
para asegurar que fuesen consistentes y estuviesen completas; lo cual era
bastante tedioso y dejaba por fuera muchos errores que deban de encontrarse.
Pero para mediados de los 80s aparecieron las herramientas CASE que trataron
de subsanar estos problemas. Las herramientas CASE (Ingeniera de software
auxiliada por computadora) se utilizan para dibujar diagramas de flujo de datos y
otros adems de llevar a cabo una variedad de labores de revisin de errores.
Finalmente, algunos usuarios tenan dificultades al tratar con los modelos grficos
del anlisis estructurado y preferan alguna otra forma de modelar los
requerimientos y comportamiento del sistema; es por ello que aparecen las
herramientas de generacin de prototipos (mediados de los 80s) que son
considerados como una alternativa al anlisis estructurado para tales usuarios.
Tambin se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo
largo de todo el desarrollo del sistema, para no perder la secuencia de lo que se
est realizando.
En la actualidad muchas de estas herramientas se estn utilizando para facilitar la
fase de anlisis, e inclusive se estn elaborando o fusionando lo mejor de cada
una de las tcnicas que atienden las necesidades de todas las fases del ciclo de
vida del sistema; para as obtener un mejor aprovechamiento, entendimiento, y
rendimiento al momento que se ponga a correr el sistema. Disminuyendo de esta
manera la serie de errores que se cometan anteriormente, con la introduccin de
herramientas ms especializadas y fciles de utilizar.
Diversos aspectos del anlisis estructurado han cambiado gradualmente a lo largo
de los ltimos aos. Las principales reas de cambio incluyen lo siguiente segn
Yourdon:
Cambios de terminologa.
Particin de acontecimientos.
La desenfatizacin del modelado fsico actual.
Herramientas de modelado en tiempo real.
Integracin ms cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darn, si es que ya no se estn
dando, los siguientes cambios o pautas en el mbito total en lo que se refiere a
anlisis segn Yourdon:
Mayor difusin del anlisis de sistemas, sobre todo en los siguientes grupos: los
niveles superiores de administracin en organizaciones gubernamentales y de
negocios, los nios, y profesionales de la computacin en los pases del tercer
mundo.
Impacto sobre la industria de software del tercer mundo.
Proliferacin de las herramientas automatizadas, aunque no todos los analistas
tienen acceso a las ltimas herramientas de anlisis.
Impacto de los desastres de mantenimiento.
Integracin del anlisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del anlisis estructurado va a depender mucho
tambin de que tan rpido pueda ajustarse el mismo a los cambios tecnolgicos
que se viven hoy en da. Debido a que han estado surgiendo otras tcnicas en
otras reas como lo es la orientada a objetos, la cual prev un buen futuro y
muchas mejoras para los sistemas actuales.

* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*

Fue la aparicin del diseo y la programacin estructurada alrededor de los aos
60s la que dieron cabida al surgimiento del anlisis estructurado, ya que exista la
necesidad de utilizar una notacin grfica para representar los datos y los
procesos que los transforman". Es por ello que surgen una serie de temas afines
tales como: herramientas automatizadas (CASE), prototipos, diagramas de
entidad-relacin etc.
ndice de Trminos relacionados: CASE (Ingeniera de Software auxiliada por
computadora), elaboracin de prototipos, smbolos grficos, diccionarios de datos,
descripciones de procesos y procedimientos, reglas, diagramas de estados,
diagramas de entidad-relacin, diagramas de transicin de eventos, divisin de
eventos, modelos esenciales y modelos de implantacin.

* Mtodos de Anlisis Orientados al Flujo de Datos *

La informacin se transforma como un flujo a travs de un sistema basado en
computadora. El sistema acepta entrada de distintas formas; aplica un hardware,
software y elementos humanos para transformar la entrada en salida; y produce
una salida en distintas formas. La entrada puede ser una seal de control
transmitida por un transductor, una serie de nmeros escritos por un operador
humano, un paquete de informacin transmitido por un enlace a red, o un
voluminoso archivo de datos almacenado en memoria secundaria. La
transformacin puede comprender una sencilla comparacin lgica, un complejo
algoritmo numrico, o un mtodo de inferencia basado en regla de un sistema
experto. La salida puede encender un sencillo led o producir un informe de 200
pginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier
sistema basado en computadora independientemente del tamao o complejidad.

La funcin global del sistema se representa como una transformacin sencilla de
la informacin, representada en la figura como una burbuja. Una o ms entradas.
Representadas como flechas con etiqueta, conducen la transformacin para
producir la informacin de salida. Puede observarse que el modelo puede
aplicarse a todo el sistema o solo a un elemento de software. La clave es
representar la informacin dada y producida por la transformacin.