ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE

INTRODUCCION

¿Qué son Requerimientos?

Normalmente, un tema de la Ingeniería de Software tiene diferentes

significados. De las muchas definiciones que existen para
requerimiento, ha continuación se presenta la definición que aparece
en el glosario de la IEEE .
(1) Una condición o necesidad de un usuario para resolver un problema
o alcanzar un objetivo. (2) Una condición o capacidad que debe estar
presente en un sistema o componentes de sistema para satisfacer un
contrato, estándar, especificación u otro documento formal. (3) Una
representación documentada de una condición o capacidad como en (1)
o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y

requerimientos no funcionales. Los requerimientos funcionales definen
las funciones que el sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para
producir salidas.
Los requerimientos no funcionales tienen que ver con características
que de una u otra forma puedan limitar el sistema, como por ejemplo,
el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento,
seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades
principales. Un conjunto de requerimientos en estado de madurez,
deben presentar una serie de características tanto individualmente
como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser reemplazados
por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo
en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar
detalles en su redacción, es decir, si se proporciona la información
suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio
con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación.
Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes
métodos de verificación: inspección, análisis, demostración o pruebas.

* Dificultades para definir los requerimientos *

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

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de
detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de
manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más
importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos
es particular para cada proyecto.

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

*

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

para un sistema es llamado Ingeniería de Requerimientos. La meta de
la ingeniería de requerimientos (IR) es entregar una especificación de
requisitos de software correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de
desarrollo de software, es ellos se basan muchos participantes del
proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de
proyecto usan los requerimientos como una base para la estimación del
esfuerzo necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al
sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta
norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el
sistema. Los requerimientos son la base sobre la cual se decide si un
caso de prueba fue ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos
documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y
manejados de la forma mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un
sistema de software entonces debemos de definir que características
deben de poseer los requerimientos adecuadamente formulados.

Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos

partes
Posibles de probar o verificar. Si un requerimiento no se puede
comprobar, entonces ¿cómo sabemos si cumplimos con él o no?
Descritos como una característica del sistema a entregar. Esto es: que
es lo que el sistema debe de hacer (y no como debe de hacerlo)
Lo más abstracto y conciso posible. Para evitar malas interpretaciones.

* Fundamentos del Análisis de Requerimientos *

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

permiten conocer los elementos necesarios para definir un proyecto de
software.
Es la etapa más crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el
usuario para resolver un problema o alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema
par satisfacer un contrato, un estándar, una especificación u otro
documento formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una
especificación completa de los requerimientos de los mismos.
Independientemente de lo bien diseñado o codificado que esté, un
programa pobremente especificado decepcionará al usuario y hará
fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de
descubrimiento y refinamiento, El ámbito del programa, establecido
inicialmente durante la ingeniería del sistema, es refinado en detalle.
Se analizan y asignan a los distintos elementos de los programas las
soluciones alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel
activo en la especificación de requerimientos. El cliente intenta
reformular su concepto, algo nebuloso, de la función y comportamiento
de los programas en detalles concretos, El que desarrolla el software
actúa como interrogador, consultor y el que resuelve los problemas.
El análisis y especificación de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engañan. Puesto que el
contenido de comunicación es muy alto, abundan los cambios por mala
interpretación o falta de información. El dilema con el que se enfrenta
un ingeniero de software puede ser comprendido repitiendo la
sentencia de un cliente anónimo: "Sé que crees que comprendes lo que
piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea
lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su
conjunto son extensos y detallados, y además contienen múltiples
relaciones entre sí. Lo que nos da a concluir, que el conjunto de
requerimientos de un sistema computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al
documentar especificaciones simples y concisas para el sistema. Esto se
logra mediante al clasificar, estructurar y organizar todo lo que el
sistema debe de hacer. En otras palabras al analizar sus
requerimientos.
El análisis de requerimientos es la tarea que plantea la asignación de
software a nivel de sistema y el diseño de programas. El análisis de
requerimientos facilita al ingeniero de sistemas especificar la función y
comportamiento de los programas, indicar la interfaz con otros
elementos del sistema y establecer las ligaduras de diseño que debe
cumplir el programa. El análisis de requerimientos permite al
ingeniero refinar la asignación de software y representar el dominio de
la información que será tratada por el programa. El análisis de
requerimientos de al diseñador la representación de la información y
las funciones que pueden ser traducidas en datos, arquitectura y diseño
procedimental. Finalmente, la especificación de requerimientos
suministra al técnico y al cliente, los medios para valorar la calidad de
los programas, una vez que se haya construido.

* Tareas del Análisis *

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

1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.

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

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

El analista debe establecer contacto con el equipo técnico y de gestión

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

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

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

Las tareas asociadas con el análisis y especificación existen para dar

una representación del programa que pueda ser revisada y aprobada
por el cliente. En un mundo ideal el cliente desarrolla una
especificación de requerimientos del software completamente por sí
mismo. Esto se presenta raramente en el mundo real. En el mejor de
los casos, la especificación se desarrolla conjuntamente entre el cliente
y el técnico.
Una vez que se hayan descrito las funcionalidades básicas,
comportamiento, interfase e información, se especifican los criterios de
validación para demostrar una comprensión de una correcta
implementación de los programas. Estos criterios sirven como base
para hacer una prueba durante el desarrollo de los programas. Para
definir las características y atributos del software se escribe una
especificación de requerimientos formal. Además, para los casos en los
que se desarrolle un prototipo se realiza un manual de usuario
preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa
tan temprana del proceso de desarrollo, Pero de hecho, este borrador
del manual de usuario fuerza al analista a tomar el punto de vista del
usuario del software. El manual permite al usuario / cliente revisar el
software desde una perspectiva de ingeniería humana y
frecuentemente produce el comentario: "La idea es correcta pero esta
no es la forma en que pensé que se podría hacer esto". Es mejor
descubrir tales comentarios lo más tempranamente posible en el
proceso.
Los documentos del análisis de requerimiento (especificación y manual
de usuario) sirven como base para una revisión conducida por el cliente
y el técnico. La revisión de los requerimientos casi siempre produce
modificaciones en la función, comportamiento, representación de la
información, ligaduras o criterios de validación. Además, se realiza una
nueva apreciación del plan del proyecto de software para determinar si
las primeras estimaciones siguen siendo validas después del
conocimiento adicional obtenido durante el análisis.

* Obteniendo de la información *

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

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

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

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

Las necesidades y / o requerimientos del cliente evolucionan con el

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

* Especificación de Requisitos de Software *(SRS)

La especificación de requisitos de software es la actividad en la cual se
genera el documento, con el mismo nombre, que contiene una
descripción 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 información que sirva
de soporte y guía para fases posteriores.
Es importante destacar que la especificación de requisitos es el
resultado final de las actividades de análisis y evaluación de
requerimientos; este documento resultante será utilizado como fuente
básica de comunicación entre los clientes, usuarios finales, analistas de
sistema, personal de pruebas, y todo aquel involucrado en la
implementación 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 evolución del sistema.
La SRS posee las mismas características de los requerimientos:
completa, consistente, verificable, no ambigua, factible, modificable,
rastreable, precisa, entre otras. Para que cada característica 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 características de la SRS son verificadas en la
actividad de Validación, descrita en el punto.
La estandarización 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, además de asegurar que se cubren
todos los tópicos importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la
potestad de crear su propia plantilla.
Clasificación de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay
requerimientos que por sus características no pueden ser tratados
iguales.
La siguiente es una recomendación 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 categoría 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 congestión en los dispositivos y errores de
entrada de datos, por lo tanto el entorno se debe de considerar dentro
de los requerimientos.
• Requerimientos "ergonómicos"
Él mas conocido de los requerimientos ergonómicos es la interfase con
el usuario o GUI (Graphic User Interface). En otras palabras, los
requerimientos ergonómicos son la forma en que el ser humano
interactúa con el ser sistema.
• Requerimientos de Interfase
La interfase es como interactúa el sistema con el ser humano o con
otros sistemas (el enfoque es prácticamente el opuesto a los
requerimientos ergonómicos), La interfase es la especificación formal
de los datos que el sistema recibe o manda al exterior. Usualmente se
especifica el protocolo, el tipo de información, el medio para
comunicarse y el formato de los datos que se van a comunicar.
* Actividades de la Ingeniería de Requerimientos *

En el proceso de IR son esenciales diversas actividades. En este

documento serán presentadas, sin embargo, en un proceso de
ingeniería de requerimientos efectivo, estas actividades son aplicadas
de manera continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de
software utilizado para el ciclo de desarrollo, las actividades de la IR
varían tanto en número 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:
• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución
* Principios de Especificación *

La especificación, independientemente del modo en que se realice,

puede ser vista como un proceso de representación. Los
requerimientos se representan de forma que conduzcan finalmente a
una correcta implementación del software.
Baltzer y Goldman proponen ocho principios para una buena
especificación:

PRINCIPIO #1. Separar funcionalidad de implementación.

Primero, por definición, una especificación es una descripción de lo
que se desea, en vez de cómo se realiza (implementa). Las
especificaciones pueden adoptar dos formas muy diferentes. La
primera forma es la de funciones matemáticas: dado algún 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 cómo). En parte,
esto es debido a que el resultado es una función matemática de la
entrada (la operación 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 especificación de sistemas
orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus
cambios afecten al comportamiento de alguna entidad que interactúe
con dicho entorno. Su comportamiento no puede ser expresado como
una función matemática de su entrada. En vez de ello, debe emplearse
una descripción orientada al proceso, en la cual la especificación del
que se consigue mediante la especificación de un modelo del
comportamiento deseado en términos de respuestas funcionales, a
distintos estímulos del entorno.
PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el
software es una componente.
Un sistema esta compuesto de componentes que interactúan. Solo
dentro del contexto del sistema completo y de la interacción entre sus
partes puede ser definido el comportamiento de una componente
especifica. En general, un sistema puede ser modelado como una
colección de objetos pasivos y activos. Estos objetos están
interrelacionados y dichas relaciones entre los objetos cambian con el
tiempo. Estas relaciones dinámicas suministran los estímulos a los
cuales los objetos activos, llamados agentes, responden. Las respuestas
pueden causar posteriormente cambios y, por tanto, estímulos
adicionales a los cuales los agentes deben responder.
PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el
sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que
interactúa debe ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio
entorno es un sistema compuesto de objetos que interactúan, pasivos y
activos, de los cuales el sistema especificado es una agente, Los otros
agentes, los cuales son por definición inalterables debido a que son
parte del entorno, limitan el ámbito del diseño subsecuente y de la
implementación. De hecho, la única diferencia entre el sistema y su
entorno es que el esfuerzo de diseño e implementación subsecuente
opera exclusivamente sobre la especificación del sistema. La
especificación 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 especificación de sistema debe ser un modelo
cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez
de un modelo de diseño o implementación. 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. Además, debe ser posible incorporar
en la especificación 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 elaboración para prevenir que
surjan estos estados.
PRINCIPIO #6. Una especificación debe ser operacional.
La especificación debe ser completa y lo bastante formal para que
pueda usarse para determinar si una implementación propuesta
satisface la especificación de pruebas elegidas arbitrariamente. Esto es,
dado el resultado de una implementación sobre algún conjunto
arbitrario de datos elegibles, debe ser posible usar la especificación
para validar estos resultados. Esto implica que la especificación,
aunque no sea una especificación completa del como, pueda actuar
como un generador de posibles comportamientos, entre los que debe
estar la implementación propuesta. Por tanto, en un sentido extenso, la
especificación debe ser operacional.
PRINCIPIO #7. La especificación del sistema debe ser tolerante con la
incompletitud y aumentable.
Ninguna especificación puede ser siempre totalmente completa. El
entorno en el que existe es demasiado complejo para ello. Una
especificación es siempre un modelo, una abstracción, de alguna
situación real (o imaginada). Por tanto, será incompleta. Además, al ser
formulad existirán muchos niveles de detalle. La operacionalidad
requerida anteriormente no necesita ser completa. Las herramientas de
análisis empleadas para ayudar a los especificadores y para probar las
especificaciones, deben ser capaces de tratar con la incompletitud.
Naturalmente esto debilita el análisis, el cual puede ser ejecutado
ampliando el rango de comportamiento aceptables, los cuales
satisfacen la especificación, pero tal degradación debe reflejar los
restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificación debe ser localizada y débilmente
acoplada.
Los principios anteriores tratan con la especificación como una entidad
estática. Esta surge de la dinámica de la especificación. Debe ser
reconocido que aunque el principal propósito de una especificación sea
servir como base para el diseño e implementación de algún sistema, no
es un objeto estático precompuesto, sino un objeto dinámico que sufre
considerables modificaciones. Tales modificaciones se presentan en
tres actividades principales: formulación, cuando se está creando una
especificación inicial; desarrollo, cuando la especificación se esta
elaborando durante el proceso iterativo de diseño e implementación; y
mantenimiento, cuando la especificación 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 ¿Cómo?. Estos
requerimientos al tiempo que avanza el proyecto de software se
convierten en los algoritmos, la lógica y gran parte del código del
sistema.
• Requerimientos de desempeño
Estos requerimientos nos informan las características de desempeño
que deben de tener el sistema. ¿Que tan rápido?, ¿Que tan seguido?,
¿Cuantos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas
de tiempo real en donde el desempeño de un sistema es tan crítico
como su funcionamiento.
• Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradación,
potabilidad, flexibilidad, contabilidad y capacidad de actualización.
Este tipo de requerimientos es también muy importante en sistemas de
tiempo real puesto que estos sistemas manejan aplicaciones críticas
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 entregarán y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un
pedazo de código dentro del sistema, son muy importantes en el
proceso de diseño ya que facilitan la introducción y aceptación del
sistema en donde será implementado.
• Restricciones de diseño
Muchas veces las soluciones de un sistema de software son normadas
por leyes o estándares, este tipo de normas caen como "restricciones de
diseño".
• Materiales
Aquí se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de
industrialización 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 técnicos y no técnicos (como fechas de entrega).
El acuerdo forma las bases para estimar, planear, ejecutar y monitorear
el proyecto de desarrollo de software a través 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 están bajo su responsabilidad estén documentados
y controlados"
¿De que manera podemos controlar los requerimientos de software si
estos siempre evolucionan con el tiempo?. El CMM nos proporciona las
guías 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 línea con los nuevos requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en
manejo de requerimientos débenos 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 técnico podrá ser impuesto por el mercado o
presiones de la competencia, pero entonces los requerimientos no
técnicos (Calidad, Costo y Tiempo de entrega) deberán estar
especificados de común acuerdo con el grupo de requerimientos del
proyecto de software.
• Los requerimientos técnicos y no técnicos forman un conjunto entre
sí, si cambia uno forzosamente deberán cambiar los demás. Esto es:
más contenido técnico implica o más costo, o menos calidad o más
tiempo estimado de entrega. De modo que los cambios técnicos
deberán ser aprobados por el grupo de requerimientos y este grupo
estimará los impactos en tiempo, costo, calidad. El resultado de la
estimación es la entrada a los líderes del proyecto para decidir si el
cambio se acepta o no.

* ORGANIZACIÓN 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 específicas de los usuarios es indispensable que los
documentos que recogen los requerimientos se redacten utilizando
métodos pragmáticos.
Se debe utilizar una metodología detallada de definición de los
requerimientos de usuario. Organizar entrevistas destinadas a obtener
la máxima información 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 participación y confirmación del usuario.
Los gerentes y usuarios del sistema también poseen un papel
importante en le diseño del sistema; no es solamente el proyecto del
analista. Durante el diseño, 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 participación del usuario proporciona al analista una
retroalimentación importante conforme avanza en el diseño; además
asegura a los usuarios tengan un conocimiento no técnico de lo
realizara o no el nuevo sistema.
Esta visión general del diseño de sistemas subraya los aspectos de
diseño que se verán mas adelante en el diseño de la salida de sistema.

* REQUERIMIENTOS DEL SISTEMA *

Los Sistemas de Información por computadora normalmente están

integrados por muchos componentes. En la mayor parte de los casos,
es difícil para los analistas entender todos estos componentes aún
mismo tiempo; por lo tanto los investigadores tienen que comenzar con
preguntas de tipo general con relación al propósito del sistema sus
entradas y salidas de los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una
investigación 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 información. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Análisis de Decisión para el Conocimiento para los
Sistema de Información.

* Estrategia del Flujo de Datos *

Cuando se siguen un flujo a través de los procesos de negocio, que es el

propósito del análisis 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 compañía. Al manejar las transacciones y completar las tareas, los
datos de entrada se procesan, almacenan, consultan, utiliza, modifica y
se emiten.
El análisis 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 Análisis de Decisiones *

La estrategia del análisis de decisiones es un complemento del análisis

del flujo de datos. Esta estrategia realza el estudio de los objetivos de
una operación 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 análisis de decisión 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 opción que toma un
supervisor de departamento para aceptar o rechazar pedidos.
La decisión de rechazar pedidos generalmente ocurre con más
frecuencia, de manera que las condiciones y acciones normalmente se
conocen como un aspecto importante.

* Etapas en la Estrategia del Análisis del Flujo de Datos *

1. - Estudiar las operaciones y procesos en marcha.

2. - Identificar cómo se procesan los datos al manejar transacciones y
terminar las tareas.
3. - Seguir el flujo de datos:
* Proceso
* Almacenamiento
* Recuperación
* Salida
4. - Añadir gradualmente detalles a los niveles inferiores.
Etapas en la Estrategia del Análisis de Decisión
1. -Estudiar los objetivos y decisiones necesarias.
2. - Desarrollar un modelo del proceso de decisión.
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 información con el mundo y sus

usuarios, en esta existen aspectos generales que todos los analistas
deben tener en cuenta estos son:
• Objetivos del Diseño de Entrada.
• Captura de Datos para la Entrada.

Objetivo del Diseño de Entrada

Consiste en el desarrollo de especificaciones y procedimientos para la
preparación de datos, la realización de los procesos necesarios para
poner los datos de transacción 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 diseñador debe controlar
la cantidad de datos en la entrada:
- Las Operaciones de preparación y entrada dependen de las personas
dado que los costos de mano de obra son altos y la preparación de
ingreso de los datos también lo son.
-
La fase de entrada puede ser un proceso lento que toma mucho más
tiempo que el que necesitan las computadoras para realizar sus tareas.

Evitar los Retrasos:

También conocido con el nombre de cuello de botella son siempre uno
de los objetivos que el analista evita al diseñar 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 más
pequeña sea esta menores serán las oportunidades para cometer
errores. Es común 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
preparación es algo que no se puede controlar por ello el analista
experimentado, evitara diseños para la entrada que traigan una mayor
cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se
alimenta un proceso muchas veces al transcurso de un día.

Mantener la sencillez del Proceso:

El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al
mismo tiempo proporcionarán métodos 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 garantía para el éxito al instalar un sistema complejo
y que domine.
Captura de Datos para la Entrada:
En una transacción 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 identificación
Datos Variables:

Son aquellos que cambian para cada transacción o toman de decisión.

Datos de Identificación:
Estos son los que identifican en forma única el artículo que esta siendo
procesado.

* Requerimientos De Salida *

Niveles de diseño
El diseño de sistema se representa a través de dos fases: el diseño
lógico y el diseño físico.
Cuando los analistas formulan un diseño lógico; escriben las
especificaciones detalladas del nuevo sistema; esto es, describen sus
características: las salidas, entradas, archivos y bases de datos y
procedimientos; todos de manera que cubran los requerimientos del
proyecto.
El diseño lógico de un sistema de información es como el plano de un
ingeniero para armar un automóvil: muestra las características
principales(motor, transmisión 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 están las puertas.
Los informes y la producción 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 diseño lógico también 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 métodos para introducir los datos, corridas
de informes copiados de archivos y detección de problemas.
El diseño físico, actividad que sigue el diseño lógico, produce
programas de software, archivos y un sistema en marcha, las
especificaciones del diseño 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.
Utilización de los Datos de Requerimientos:
El alcance del diseño de sistemas se guía por el marco de referencia
para el nuevo sistema desarrollado durante el análisis. Los datos de los
requerimientos, recopilados durante la investigación, conforman las
actividades y componentes del sistema. Los analistas formulan un
diseño lógico que apoya los procesos y decisiones, los contenidos del
sistema pueden cambiar como resultado de un nuevo diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación
de requerimientos.
En primer lugar se identifican las características generales, como
informes y entradas; en el diseño de la salida por ejemplo, los analistas
deben conocer la longitud de campo de un dato específico para
establecer cuanto espacio dejar en la información, en la pantalla de
despliegue visual o archivo.
A lo largo de los años hemos visto una evolución de ideas y técnicas en
el campo del análisis de sistemas. La cual cabe en tres períodos amplios
según Yourdon:
1. El análisis de sistema convencional, anterior a los años 70´s,
caracterizado por especificaciones tipo novela victoriana que eran
difíciles de leer y entender, y casi imposibles de mantener.
2. El análisis estructurado clásico, de mediados de los años 70´s, a
mediados de los años 80´s. Esto se caracterizó por primeras versiones
de modelos gráficos, y énfasis en el modelado de las implementaciones
actuales de un sistema antes de modelar el nuevo.
3. El análisis 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 comunicación entre el
analista y el sistema.
En la actualidad las técnicas modernas están siendo fusionadas, para
así lograr un mejor método que pueda hacerle frente a las necesidades
de las diferentes fases del ciclo de vida del sistema, incluyendo a la fase
de análisis. Obteniendo de está manera mejores resultados que pueda
interpretar el analista en forma rápida y precisa.
En primera instancia debemos decir que el análisis estructurado según
Senn "permite al analista conocer un sistema o proceso (actividad) en
una forma lógica y manejable al mismo tiempo que proporciona la base
para asegurar que no se omite ningún detalle pertinente". El objetivo
que persigue el análisis estructurado es organizar las tareas asociadas
con la determinación de requerimientos para obtener la comprensión
completa y exacta de una situación dada. Se puede decir
adicionalmente que los componentes del análisis estructurado son los
siguientes: símbolos gráficos, diccionarios de datos, descripciones de
procesos y procedimientos, reglas.
Después de relacionarnos brevemente con la terminología básica,
podemos entrar en aspectos relacionados con los cambios del análisis
estructurado.
Podemos decir que para finales de los años 60´s e inicios de los 70´s el
análisis estructurado surge de la necesidad de buscar una forma
interpretativa más rápida 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 existía eran grandes
volúmenes de información que había que leer por completo y que
acarreaban una serie de problemas de: monolitismo, redundancia,
ambigüedad e imposibilidad de mantener. Es por ello que surge una
amplia variedad de diagramas que permiten representar las
especificaciones funcionales en forma sencilla y rápida, aumentando
por ende el grado de comunicación entre las especificaciones
funcionales y el usuario final (analista, programador, diseñador).
Posteriormente, a mediados de los años 70´s estando el análisis
estructurado clásico en su apogeo aparecen una serie de dificultades
que limitan al analista hacer un buen desempeño de sus actividades.
Entre estos problemas según Yourdon podemos mencionar:
• Distinción difusa y poca, definida entre los modelos lógicos y los
modelos físicos.
• Limitación para modelar sistemas en tiempo real.
• El modelo de datos se hacía de una manera primitiva.

Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis

estructurado clásico tales como: diagramas de entidad-relación,
diagramas de transición de estados, división de eventos, modelos
esenciales y modelos de implantación. Pero a pesar de esto según
Yourdon se siguieron dando más problemas como los siguientes:
• Tras la segunda y tercera correcciones de un diagrama, el analista se
volvía cada vez más apuesto y renuente a hacer más 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 después de la fase de
análisis del proyecto.
Inclusive las correcciones de los diagramas había 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 debían de encontrarse. Pero para mediados de los 80´s
aparecieron las herramientas CASE que trataron de subsanar estos
problemas. Las herramientas CASE (Ingeniería de software auxiliada
por computadora) se utilizan para dibujar diagramas de flujo de datos
y otros además de llevar a cabo una variedad de labores de revisión de
errores.
Finalmente, algunos usuarios tenían dificultades al tratar con los
modelos gráficos del análisis estructurado y preferían alguna otra
forma de modelar los requerimientos y comportamiento del sistema; es
por ello que aparecen las herramientas de generación de prototipos
(mediados de los 80´s) que son considerados como una alternativa al
análisis estructurado para tales usuarios. También 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 están utilizando para
facilitar la fase de análisis, e inclusive se están elaborando o fusionando
lo mejor de cada una de las técnicas 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 cometían anteriormente, con la introducción de
herramientas más especializadas y fáciles de utilizar.
Diversos aspectos del análisis estructurado han cambiado
gradualmente a lo largo de los últimos años. Las principales áreas de
cambio incluyen lo siguiente según Yourdon:
• Cambios de terminología.
• Partición de acontecimientos.
• La desenfatización del modelado físico actual.
• Herramientas de modelado en tiempo real.
• Integración más cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darán, si es que ya no se
están dando, los siguientes cambios o pautas en el ámbito total en lo
que se refiere a análisis según Yourdon:
• Mayor difusión del análisis de sistemas, sobre todo en los siguientes
grupos: los niveles superiores de administración en organizaciones
gubernamentales y de negocios, los niños, y profesionales de la
computación en los países del tercer mundo.
• Impacto sobre la industria de software del tercer mundo.
• Proliferación de las herramientas automatizadas, aunque no todos los
analistas tienen acceso a las últimas herramientas de análisis.
• Impacto de los desastres de mantenimiento.
• Integración del análisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del análisis estructurado va a
depender mucho también de que tan rápido pueda ajustarse el mismo
a los cambios tecnológicos que se viven hoy en día. Debido a que han
estado surgiendo otras técnicas 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 aparición del diseño y la programación estructurada alrededor

de los años 60´s la que dieron cabida al surgimiento del análisis
estructurado, ya que existía la necesidad de utilizar una notación
gráfica 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-relación etc.
Índice de Términos relacionados: CASE (Ingeniería de Software
auxiliada por computadora), elaboración de prototipos, símbolos
gráficos, diccionarios de datos, descripciones de procesos y
procedimientos, reglas, diagramas de estados, diagramas de entidad-
relación, diagramas de transición de eventos, división de eventos,
modelos esenciales y modelos de implantación.

* Métodos de Análisis Orientados al Flujo de Datos *

La información se transforma como un flujo a través 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 señal de control transmitida por un transductor, una
serie de números escritos por un operador humano, un paquete de
información transmitido por un enlace a red, o un voluminoso archivo
de datos almacenado en memoria secundaria. La transformación puede
comprender una sencilla comparación lógica, un complejo algoritmo
numérico, o un método de inferencia basado en regla de un sistema
experto. La salida puede encender un sencillo led o producir un
informe de 200 páginas. En efecto, un modelo de flujo de datos puede
aplicarse a cualquier sistema basado en computadora
independientemente del tamaño o complejidad.

La función global del sistema se representa como una transformación

sencilla de la información, representada en la figura como una burbuja.
Una o más entradas. Representadas como flechas con etiqueta,
conducen la transformación para producir la información 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 información
dada y producida por la transformación.

* Diagramas de Flujos de Datos *

Conforme con la información se mueve a través del software, se

modifica mediante una serie de transformaciones. Un diagrama de
flujos de datos (DFD), es una técnica grafica que describe el flujo de
información y las transformaciones que se aplican a los datos,
conforme se mueven de la entrada a la salida. El diagrama es similar en
la forma a otros diagramas de flujo de actividades, y ha sido
incorporado en técnicas de análisis y diseños propuesto por Yourdon y
Constantine, DeMarco y Gane y Sarson. También se le conoce como un
grafo de flujo de datos o un diagrama de burbujas.

* Diccionario de Datos *

Un análisis del dominio de la información puede ser incompleto si solo

se considera el flujo de datos. Cada flecha de un diagrama de flujo de
datos representa uno o más elementos de información. Por tanto, el
analista debe disponer de algún otro método para representar el
contenido de cada flecha de un DFD.
Se ha propuesto el diccionario de datos como una gramática casi
formal para describir el contenido de los elementos de información y
ha sido definido da la siguiente forma:
El diccionario de datos contiene las definiciones de todos los datos
mencionados en el DFD, en una especificación del proceso y en el
propio diccionario de datos. Los datos compuestos (datos que pueden
ser además divididos) se definen en términos de sus componentes; los
datos elementales (datos que no pueden ser divididos) se definen en
términos del significado de cada uno de los valores que puede asumir.
Por tanto, el diccionario de datos esta compuesto de definiciones de
flujo de datos, archivos [datos almacenados] y datos usados en los
procesos [transformaciones]...
* Descripciones Funcionales *

Una vez que ha sido representado el dominio de la información

(usando un DFD y un diccionario de datos), el analista describe cada
función (transformación) representada, usando el lenguaje natural o
alguna otra notación estilizada. Una de tales notaciones se llama ingles
estructurado (también llamado lenguaje de diseño del programa o
proceso(LDP)). El ingles estructurado incorpora construcciones
procedimentales básicas –secuencia, selección y repetición- junto con
frases del lenguaje natural, de forma que pueden desarrollarse
descripciones procedimentales precisas de las funciones representadas
dentro de un DFD.

* Métodos Orientados a la Estructura de Datos *

Hemos ya observado que el dominio de la información para un

problema de software comprende el flujo de datos, el contenido de
datos y la estructura de datos. Los métodos de análisis orientados a la
estructura de datos representan los requerimientos del software
enfocándose hacia la estructura de datos en vez de al flujo de datos.
Aunque cada método orientado a la estructura de datos tiene un
enfoque y notación distinta, todos tienen algunas características en
común: 1) todos asisten al analista en la identificación de los objetos de
información clave (también llamados entidades o ítems) y operaciones
(también llamadas acciones o procesos); 2)todos suponen que la
estructura de la información es jerárquica; 3)todos requiere que la
estructura de datos se represente usando la secuencia, selección y
repetición; y 4) todos dan una conjunto de pasos para transformar una
estructura de datos jerárquica en una estructura de programa.
Como los métodos orientados al flujo de datos, los métodos de análisis
orientados a la estructura de datos proporcionan la base para el diseño
de software. Siempre puede extenderse un método de análisis para que
abarque el diseño arquitectural y procedimental del software.