3.

2 ANLISIS DE REQUERIMIENTOS Y DISEO INICIAL

ANLISIS-DETERMINACIN DE LOS REQUERIMIENTOS
Esta etapa consiste en una investigacin descriptiva del sistema actual,
mediante hechos, para conocerlo en profundidad e inferir cules son los
requerimientos que debe satisfacer el nuevo sistema. (Cceres, 2014)
Hechos: Para llegar a un sistema mejor que el actual, debemos conocerlo
adecuadamente. Sintticamente, debemos saber qu hace bien, qu hace mal, qu le
sobra y qu le falta. El nuevo sistema deber incluir lo que hace bien, hacer bien lo
que hace mal, eliminar lo que sobra, incorporar lo que falta.
Mientras mejor se conozca el sistema actual, mejor ser el nuevo sistema. La nica
forma de conocer adecuadamente el sistema actual es mediante hechos. Recordemos
que un hecho es un dato verificado. La despreocupacin por obtener hechos produce
muchos inconvenientes, que podemos resumir como sigue.

Conocimiento incierto del sistema actual. Si los datos no son verificados pero

se los toma como ciertos, el conocimiento del sistema actual no ser cierto.
Requerimientos inciertos. El nuevo sistema resultar de requerimientos que se
deducen del sistema actual. Pero si ste no se conoce con certeza, los
requerimientos sern inciertos, lo que llevar a disear un nuevo sistema sobre

bases inciertas.
Desperdicio. El trabajo del analista basado en opiniones tendr poco valor, con
lo cual se habr malgastado tiempo y dinero.
Con respecto a la calidad de hechos a recolectar, deben estar en funcin del
objetivo del proyecto, es decir, deben ser pertinentes. Hay que recolectar no
cualquier hecho, sino aqullos que contribuyan a conocer el sistema actual.
Con respecto a la cantidad de hechos a recolectar, deben ser suficientes. Esto
significa que no deben ser menos de los necesitados para conocer el sistema,
pues el conocimiento sera incompleto; pero tampoco ms, pues el costo de
conseguirlos aumentara innecesariamente, sin aportar conocimiento relevante.
Ac vale el criterio que se aplica en la investigacin preliminar: detener la
investigacin de un aspecto cuando la informacin adicional que se obtenga
redunde con la informacin ya obtenida. Para recolectar los hechos se puede
aplicar cualquier tcnica de recoleccin de datos o combinaciones de ellas. El
tipo de hecho determina la tcnica a usar.

Hechos a buscar No hay una forma estipulada para buscar hechos, pero
conviene comenzar por las salidas. Identificadas stas, se pueden identificar
los procesos que las producen, las entradas que brindan los datos y los
archivos donde se almacenan stos.

Salidas. La forma ms habitual de las salidas son los tabulados, sean impresos
o en pantalla. Otras formas tambin usuales son grficos y textos
personalizados. Muchas de las salidas que produce el sistema actual son
naturales, por lo que resulta fcil conseguirlas. En un sistema de ventas, por
ejemplo, seguramente hay facturas, listas de precios, resmenes de ventas en
cantidades y pesos. Otras salidas, que usan confidencialmente los jefes, son
ms difciles de obtener.
Sea para ejemplificar un informe mensual que usa el gerente de ventas, donde
se resume por cada empleado cuntos das trabaj, cunto y cules rubros
vendi, cuntas devoluciones y reclamos hubo. El informe es confidencial,
porque sirve para calificar a cada vendedor. La manera de conocer estas
salidas confidenciales es que el analista cuente con la colaboracin efectiva y
motivada de quienes las usan, para que las hagan conocer.
Observando las salidas, se puede saber si sus aspectos formales son
adecuados y se pueden reconocer los datos utilizados para producirlas. Pero
su validez funcional debe evaluarse en relacin a las necesidades de los
usuarios. Ellos son la clave para saber si las salidas actuales sirven o no, si
deben modificarse y si se necesitan otras, ahora inexistentes. Con respecto a
estas ltimas, el analista y los usuarios afectados deben definir su contenido.
Esto permitir conocer los datos y establecer los procesos que las producirn.

Procesos. Como las salidas resultan de procesos, conociendo las salidas

actuales se determinan los procesos generadores. Los procesos son una
secuencia de pasos y pueden ser manuales o automticos. Por procesos
manuales queremos decir procedimientos de oficina, representables por
cursogramas. Los procesos automticos estn contenidos en programas de
computadora.
El analista debe entender bien los procesos actuales, porque no son evidentes
como las salidas y pueden ser complicados. Esto har que pueda
perfeccionarlos o eliminarlos en el diseo del nuevo sistema. Las salidas
inexistentes actualmente, pero necesitadas, van a requerir nuevos procesos en
el nuevo sistema. La obtencin de hechos sobre procesos debe centrarse en

aquellos que sean complejos, requieran clculos complicados y cundo deben

realizarse.

Entradas. Hay que determinar todos los datos que entran al sistema actual y
cules documentos los soportan. Las salidas ayudan a encontrar la mayora de
esos datos, pero no todos. Muchos datos de salida son simples transcripciones
de los datos de entrada, tal como fueron capturados; por ejemplo los nombres
y domicilios de los clientes. Otros datos de salida resultan de clculos con
datos de entrada, como el total vendido en una semana, que es la suma de los
productos entre cantidad y precio de cada factura.

Archivos. En sistemas computarizados, los datos de entrada se guardan en

archivos a travs de captura. Es fcil obtener listados de los archivos del
sistema actual, sus campos de datos y los ndices que emplean. Si estos
archivos usan campos que guardan cdigos, es necesario conocer la ley de
formacin y si se llenan manual o automticamente. Si hay campos que
guardan datos de control llenados por procesos posteriores a la captura, hay
que averiguar en qu consisten esos controles.
En lo posible, los archivos del sistema actual debern ser reciclados para
obtener los archivos del nuevo sistema. Esto a veces es sencillo y otras veces
necesita programas complejos para convertirlos.

Circunstancias. Adicionalmente a los hechos sobre salidas, procesos, entradas

y archivos, hay otros que tambin van a influir en el diseo del nuevo sistema.
Slo podemos dar ejemplos de tales hechos, ya que dependen de las
circunstancias en que se desarrolla cada proyecto. As, la normativa legal que
regula la actividad de la empresa; la decisin ya tomada de vender por Internet,
cobrar a los clientes mediante dbitos bancarios automticos o abrir nuevas
sucursales, etc.

DISEO INICIAL
Concluido el anlisis del sistema actual, se tiene suficiente conocimiento de l como
para describirlo. Sin embargo, el propsito no es describir algo que va a dejar de
existir, sino concluir qu caractersticas de l deben sobrevivir en el nuevo sistema y
qu nuevas caractersticas debe tener ste. Algunas de las nuevas caractersticas
surgen por la comprobacin de su inexistencia en el sistema actual, siendo que
debera poseerlas necesariamente; otras nacen de la imaginacin, el conocimiento y la
experiencia del analista y de los usuarios.

Generalmente, stos necesitan que el nuevo sistema no sea un remiendo del actual,
sino una creacin original, para circunstancias internas y ambientales quizs muy
diferentes a aqullas que dieron origen al sistema actual. Esto hace necesario la
incorporacin de muchas caractersticas nuevas. El analista deber tener
presentes los requerimientos cuando disee el nuevo sistema (Bentley, 2015).
Hay requerimientos comunes a cualquier sistema, de modo que no es necesario
registrarlos. Otros, especficos al sistema a disear, deben ser anotados, para no
olvidarlos.

3.2.1 Dimensionamiento de volmenes y sistemas

Requerimientos

comunes:

Los

sistemas

deben

cumplir

con

ciertos

requerimientos comunes, de modo que son una gua para cualquier analista.
Veamos algunos.

Calidad. El nuevo sistema debe ser valioso en cuanto a calidad de informacin,

redundancia mnima, facilidad operativa, controles suficientes y eficiencia.
Mientras mejor cumpla estos aspectos, ms calidad tendr el nuevo sistema en
s mismo y ms calidad tendr el servicio que preste a los usuarios directos e
indirectos. Las consideraciones realizadas al analizar los hechos del sistema
actual contribuyen a aplicar este criterio.

Flexibilidad. Los cambios internos y externos de la institucin pueden ser

radicales, convirtiendo en obsoleto el sistema actual de un momento para otro.
Pero la mayora de los cambios son menores, de modo que el nuevo sistema
debe ser lo suficientemente flexible para poder adaptarse a ellos. Veamos un
ejemplo. Sea un proceso de un sistema que liquida un impuesto.
Si las escalas de montos y tasas se introducen como instrucciones de
programacin, cuando se produzca un cambio en las escalas el proceso el
programa quedar inutilizado. Esto se da porque el sistema tiene una rigidez
en tal proceso. En cambio, si las escalas se registran en una tabla que puede
ser modificada en otro proceso, los cambios de escala obligarn a modificar
esa tabla, pero no afectarn el proceso de liquidacin. Este sencillo recurso ha
introducido flexibilidad, permitiendo que el sistema resista el golpe.

Adaptacin tecnolgica. La calidad del nuevo sistema depende de la tecnologa

empleada. La disponibilidad de tecnologa en hardware y software puede
cambiar radicalmente la forma de encarar el nuevo sistema. Si la tecnologa

ideal tiene un precio inalcanzable, habr que considerar la mejor tecnologa

dentro de la capacidad financiera de la institucin, que se adecue a los
requerimientos. La carencia de tecnologa adecuada puede hacer imposible un
nuevo sistema de calidad.

Realismo. Los requerimientos deben adecuarse a la realidad de la empresa.

No es posible pensar en procesos que exijan lenguajes desconocidos por los
programadores disponibles; en el manejo de software complejo por empleados
cuyo nivel intelectual es insuficiente; en formas de trabajo que impongan
cambios culturales improbables; etc.

3.2.2 Incorporacin de controles

Los controles son esenciales en los sistemas de informacin. Hay distintos tipos, de
los que veremos algunos. Estudiar los controles que emplean los procesos
actuales sirve para descubrir fallas que hay que subsanar y mecanismos
seguros que deben ser mantenidos en el nuevo sistema (CIAMPAGNA, 2011).
Sin embargo, esto no basta. La importancia de los datos y los procesos puede
llevar a establecer nuevos controles futuros.

Controles de datos. Son los que hemos visto como validacin simultnea o
posterior, mediante cdigos, rangos, consistencia, dgitos verificadores,
integridad referencial, etc. Se aplican a la captura o transcripcin de datos,
procurando reducir el ingreso de errores al sistema. Como esos datos
originales son la materia prima para la elaboracin de datos calculados y de
informacin, es vital controlarlos.

Controles de procesos. Se aplican cuando se deben realizar distintos

procesos segn un orden prefijado, sin omitir ninguno. En los sistemas
manuales, por ejemplo, son los vistos buenos que se incorporan a un
formulario, a medida que se va procesando en distintas unidades
funcionales. Permiten saber si falta alguna intervencin. En sistemas
computarizados, los procesos se pueden controlar mediante una tabla
diseada al efecto.
Por ejemplo, sea una empresa que fabrica a pedido productos que requieren
tres etapas sucesivas de diseo, fabricacin y pintura. Al recibir un pedido,
la Gerencia Industrial da de alta un registro en una tabla de productos en
proceso, con el nmero de pedido, otros datos complementarios y tres

campos de fecha de terminacin, uno para cada etapa. Cuando el sector

Diseo completa su trabajo, manda un parte a Gerencia Industrial, que llena
la fecha de cumplimiento de diseo en el registro correspondiente.
Cuando el sector Fabricacin completa su trabajo, manda un parte a
Gerencia, que llena la fecha de fabricacin. Cuando el sector Pintura
completa su trabajo, manda un parte a Gerencia, que llena la fecha de
pintura. Si Fabricacin comunicara haber terminado un producto todava no
diseado o Pintura haber pintado un producto todava no diseado o no
fabricado, el programa de carga debe detectar la anormalidad y no permitir
llenar la fecha correspondiente.
El gerente puede consultar el registro de un pedido particular para ver su
estado de avance, obtener un informe de todos los productos en proceso,
etc.

Controles de seguridad. Son los que permiten acceder al sistema a quienes

tienen autorizacin para hacerlo, impidiendo el ingreso de extraos. En
sistemas manuales, por ejemplo, para ingresar al tesoro de un banco, se
establece que la clave para abrir la puerta sea conocida solamente por el
tesorero y el gerente general, quienes pueden tener dos llaves que en
conjunto abran la puerta. En sistemas computarizados en red se usan

claves de usuario para entrar a ellos.

El supervisor del sistema, que tiene acceso total a l, define a cada persona
autorizada en una tabla de usuarios. La definicin incluye: (1) datos del
usuario; (2) una clave invariable que lo identifica, accesible al supervisor
pero inaccesible al usuario; (3) una clave personal del usuario, que por
razones de seguridad puede o debe cambiar peridicamente; (4) los
permisos otorgados al usuario: leer archivos, modificarlos, copiarlos,
destruirlos, imprimirlos, etc.
Para ingresar, cada usuario debe proporcionar su clave personal, que est
asociada a la clave invariable. Si hay correspondencia entre ambas, la
persona puede ingresar, con los permisos que tiene otorgados.
Adems de la tabla de usuarios, suele llevarse otra tabla de conexiones.
Cada vez que un usuario se conecta a la red, se agrega un registro a esta
tabla, llenando su clave invariable y la hora de conexin. Cuando termina su
trabajo, en el registro que le corresponde se llena la hora de desconexin.
Esta tabla permite saber quines han estado conectados un da y a una

hora determinados. Como el lector puede inferir, mantener usuarios y

permisos es una tarea de administracin delicada.
El supervisor de este sistema debe ser cuidadosamente elegido, porque se
le exige confidencialidad mxima.

Controles de responsabilidad. Son los que permiten conocer quin intervino

en un proceso. En sistemas manuales, por ejemplo, son el agregado de las
iniciales de quien escribi una nota o llen un formulario, o la firma y el sello
de quien dio una autorizacin. En sistemas informatizados, cuando es
importante controlar quin realiz una tarea riesgosa, se desarrolla un
mecanismo de control ms refinado.

Controles de autenticidad. Son los que procuran que los datos, informes,
credenciales, etc., no sean alterados o falsificados. Veamos algunos
ejemplos. Para asegurar la autenticidad de una nota, es comn el uso de
membretes y la aclaracin de las firmas mediante sellos.
En los documentos donde se escriben importes y otros datos importantes,
se pueden usar tramados para dejar en evidencia si el papel ha sido
borrado; asteriscos de proteccin en lugar de espacios izquierdos, como en
***.**7.247,29; signos flotantes adheridos al dgito izquierdo de una cifra,
como en $7.247,29 o $5.744.300,00; impresin de importes en nmeros y
en palabras; etc.
En los mensajes y documentos enviados por correo electrnico, se usan
firmas digitales que garantizan la autenticidad del remitente y la no
adulteracin del mensaje.

Controles de funcionamiento. Son los que comprueban que las distintas

actividades de un sistema funcionen correctamente. No son parte
constitutiva del sistema, sino que forman una auditora sobre l. Se aplican
intensamente durante la etapa de pruebas, sometiendo el sistema a datos
simulados, correctos y errneos. Debido que estas simulaciones, por
meticulosas que sean, pueden no agotar todas las combinaciones de
circunstancias, quizs queden casos sin probar.

3.3 Especificaciones detalladas/Documentacin

Segn los estndares de la IEEE el documento de especificacin de requerimientos de

software deben tener los siguientes tems:

Descripcin de la Funcionalidad de la Aplicacin.

Descripcin de la relacin de la Aplicacin con Sistemas e Interfaces Externas.
Descripcin de las mtricas de Desempeo del Sistema (Velocidad,

disponibilidad, tiempos de respuesta y mantenibilidad).

Limitaciones de la implementacin (Lenguaje de desarrollo, polticas de Base
de Datos, Sistemas Operativos y otros Recursos utilizados).

Adems tiene que cumplir con las siguientes caractersticas:

Debe ser correcta.

No debe ser ambigua.
Debe ser completa.
Debe ser consistente.
Debe ser verificable.
Debe ser modificable.
Debe proveer trazabilidad.

Para lograr los objetivos y resultados anteriormente mencionados, el grupo de trabajo

propone el seguimiento de un proceso estructurado que culminar con la elaboracin y
verificacin de los artefactos de salida mencionados a continuacin:

Documento de definicin de Requerimientos Funcionales.

Documento de definicin de Requerimientos No Funcionales.

A CRITERIOS DE INICIO O CRITERIOS DE ENTRADA: Este proceso se inicia

inmediatamente despus de la aprobacin del acta de inicio del proyecto para
el desarrollo del sistema para el seguimiento de la gestin de proyectos de
software.

Adicionalmente se cuenta con el enunciado general de

requerimientos del proyecto, a partir del cual se desarrollar el proceso de

especificacin.
B OBJETIVO DEL PROCESO: El objetivo principal del proceso de especificacin
es lograr definir de forma clara y precisa cada uno de los requerimientos del
Sistema para el seguimiento de la gestin de proyectos de desarrollo de
Software.

El seguimiento adecuado del proceso adems nos permitir:

Disminuir el nmero de defectos encontrados en la fase de
implementacin del producto de software.

Realizar la fase de implementacin de forma gil y con la seguridad de

estar desarrollando exactamente las necesidades del cliente.

Lograr un dimensionamiento adecuado del tamao del sistema.
Como resultado final del proceso de especificacin deben quedar
elaborados, validados y verificados los siguientes entregables:

Documento de definicin de Requerimientos Funcionales

Documento de definicin de Requerimientos No Funcionales

C RESPONSABLES DEL PROCESO: El proceso de especificacin ser

desarrollado conjuntamente por todo el equipo de trabajo, realizando una
distribucin equitativa de cargas de trabajo. El proceso estar dirigido por el
lder del proyecto y el aseguramiento de la calidad estar a cargo del Lder de
Calidad.
D Entradas: Las siguientes son las actividades que se deben ejecutar durante el
proceso de Especificacin de Requerimientos.

Enunciado del trabajo del Proyecto: El enunciado del trabajo es la entrada que
describe la oportunidad o necesidad de negocio que la organizacin ha
identificado y por la cual se dio origen al proyecto. Adicionalmente, indica el
alcance y los requisitos del producto los cuales servirn de apoyo para los
procesos posteriores principalmente al proceso de planeacin.

Acta de constitucin: El acta de constitucin, contiene informacin de los

objetivos, alcance, restricciones y dems, que se deben tener en cuenta para la
planeacin del proyecto.
Formatos establecidos para la especificacin: Son las plantillas definidas para
construir los documentos involucrados en este proceso. Las plantillas son:

Plantilla de especificacin de requerimientos funcionales: En esta

plantilla se especifica de forma detallada el formato de cada uno de los
casos de uso que componen el sistema.
formato.

(Formato

basado

requerimientos, siglo21)

en

el

Para esto se propone el

documento

de

especificacin

de

Documento de especificacin de requerimientos no funcionales: En

este documento se especificarn los requerimientos no funcionales del
sistema Este documento contar con las siguientes secciones:

REQUERIMIENTOS NO FUNCIONALES MANIFIESTOS.

Desempeo
Disponibilidad
Usabilidad

REQUERIMIENTOS NO FUNCIONALES OPERACIONALES

Robustez
Escalabilidad
Seguridad
Interoperabilidad

REQUERIMIENTOS NO FUNCIONALES DE DESARROLLO

Base De Datos
Servidor Web De Aplicaciones
Navegador Web
Mquina Virtual De Java

E ACTIVIDADES: Las siguientes son las actividades que se deben ejecutar

durante el proceso de Especificacin de Requerimientos.

Anlisis del mundo del sistema

Descripcin: Realizar un anlisis preliminar del mundo del sistema.
Resultado: Descripcin del mundo del sistema.
Responsable: Lder del Proyecto
Participantes: Lder de Soporte.

Identificacin de Mdulos del Sistema y/o Procesos de Negocio

Descripcin: Identificar los mdulos que conforman el sistema y
elaborar el documento que los describe.
Resultado: Documento de Mdulos del Sistema
Responsable: Lder del Proyecto
Participantes: Lder de Soporte.
Identificacin de todos los actores que componen el Sistema
Descripcin: Identificar los actores que intervienen en el sistema y
elaborar el correspondiente Documento de Actores del Sistema
Resultado: Documento de Actores del Sistema.
Responsable: Lder del Proyecto
Participantes: Lder de Desarrollo, Lder de Soporte, Lder del Proyecto.

Especificacin detallada de Requerimientos Funcionales

Descripcin: Elaboracin de los documentos de especificacin
detallada de Casos de Uso.
Resultado: Documento de Especificacin detallada de Casos de Uso.
Responsable: Lder del Proyecto.
Participantes: Lder de Desarrollo, Lder de Soporte, Lder del Proyecto
Especificacin de Requerimientos No Funcionales
Descripcin: Elaboracin del Documento de Especificacin de
Requerimientos No Funcionales del Sistema.
Resultado: Documento de Especificacin de Documentos No
Funcionales del Sistema
Responsable: Lder de Desarrollo
Acta de Aprobacin
Descripcin: En este documento se aprueba por parte del Cliente
(Profesor y Monitor) y por parte del Equipo de Trabajo el proceso de
especificacin de requerimientos del Sistema.
Resultado: Acta de Aprobacin de la Especificacin del Sistema,
firmada por el Cliente y por el equipo de trabajo.
Responsable: Lder del Proyecto.
Participantes: Lder del Proyecto, Profesor, Monitor
F

SALIDAS: Las siguientes son las salidas del proceso de Especificacin de

Requerimientos.
Documento de Especificacin de Mdulos del Sistema:
En este documento se identifican los mdulos que componen el
Sistema de Informacin y se da una descripcin de cada uno de ellos,
indicando sus caractersticas y principales responsabilidades.
Documento de Especificacin de Requerimientos Funcionales:
En este documento se especifica de forma detallada cada uno de los
casos de uso que componen el sistema.
Documento de Requerimientos No Funcionales del Sistema:
En este documento se especificarn los requerimientos no funcionales
del sistema.

G CRITERIOS DE TERMINACIN DEL PROCESO: El proceso finaliza una vez

se hayan ejecutado todas las actividades definidas y como resultado de la
revisin del mismo, se firmar la correspondiente Acta de Aprobacin de la
Especificacin del Sistema.

3.3.1 Diseo de pantallas e informes

La sola recoleccin de hechos, no los hace directamente analizables. Para
apreciarlos con claridad, detectar fallas e idear soluciones, normalmente hay que
describirlos mediante textos o grficos, ordenarlos, contarlos, resumirlos, tabularlos,
etc. Estas son soluciones de sentido comn, que inventa el analista en cada
ocasin. Por otro lado y complementariamente, existen herramientas con propsitos
especficos, que han sido desarrolladas por acadmicos y especialistas.
Son ejemplo de ellas los cursogramas, adecuados para exponer grficamente
procedimientos manuales, y las tablas de decisin, que sintetizan procesos para
realizar distintas acciones, dependiendo del estado de varias condiciones. Las
herramientas tienen la ventaja de ser precisas y sintticas. Son tambin verstiles,
porque pueden aplicarse en varios momentos del proyecto, como se explica a
continuacin.

EXPOSICIN DE HECHOS. Permiten expresar con claridad un hecho o un

conjunto relacionado de ellos, constituyendo una forma de documentarlos.

ANLISIS DE HECHOS. Facilitan el anlisis de los hechos del sistema

actual, posibilitando el hallazgo de errores, complicaciones y carencias.

DISEO DEL NUEVO SISTEMA. Sirven para disear el nuevo sistema, ya

sea en forma general o en aspectos particulares.

PROGRAMACIN. Permiten expresar con exactitud muchas de las
instrucciones que el analista debe escribir para los programadores.

En lo que sigue, veremos algunas de las herramientas. Advierta que hay muchas
ms que las tratadas aqu. Tenga tambin en cuenta que, por ser herramientas,
sirven de ayuda al analista, pero no reemplazan por s solas el esfuerzo, la agudeza
ni la inventiva requerida de este especialista.
Lenguaje estructurado: Esta herramienta consiste en usar estructuras lgicas y
sintcticas para controlar la ejecucin de un conjunto de acciones. Las estructuras
lgicas se refieren a modos eficientes de controlar la ejecucin de acciones. Las
estructuras sintcticas son la traduccin de las estructuras lgicas a frmulas
lingsticas precisas, en la lengua nativa del pas. Las estructuras sirven para
controlar rigurosamente la ejecucin de las acciones.
La herramienta fue inicialmente desarrollada para lenguajes de programacin, pero
dada su potencia ha sido ampliada a otros mbitos. El lenguaje estructurado sirve
para documentar y analizar procedimientos de cualquier grado de complejidad.

Tambin es til como herramienta de diseo, para dar instrucciones a los

programadores.
Estructuras lgicas: Tras aos de programar computadoras, se concluy que
todos los programas pueden ejecutar sus comandos siguiendo tres modalidades.
Estas fueron llamadas estructuras lgicas de secuencia, seleccin e iteracin. Gran
parte de las complicaciones y fallas de programacin se deban a no haberlas
respetado adecuadamente. A partir de all, cambi no slo la forma de escribir los
programas, sino que fueron modificados los mismos lenguajes de programacin
para incluir comandos explcitos que materializaran estas estructuras.
Un programa que observa las estructuras lgicas es ms fcil de escribir y menos
propenso a fallar, porque ellas controlan mejor el funcionamiento y facilitan hallar
errores debidos a la mala ubicacin de un comando. Como los comandos de
programacin no son sino condiciones y acciones, las estructuras lgicas pueden
aplicarse tambin a cualquier conjunto de condiciones y acciones para realizar un
procedimiento.
3.3.2 Diagramacin de flujo de requerimientos de hardware y software
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 cmo 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. (SENN, Enero 1990 )
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.
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.

CLCULO DE LAS CARGAS DE TRABAJO

El prximo paso en la determinacin de las necesidades de hardware es
calcular las cargas de trabajo. As, los analistas de sistemas establecen
cifras que representan las cargas de trabajo actuales y proyectadas para el

sistema con el fin de que cualquier hardware que se adquiera cuente con la
capacidad para manejar las cargas de trabajo actuales y futuras.
Si las estimaciones se realizan adecuadamente, la empresa no debe
reemplazar el hardware tan slo por el crecimiento inesperado en el uso del
sistema. (Sin embargo, otros eventos, como innovaciones tecnolgicas
superiores, pueden dictar el reemplazo del hardware si la empresa quiere
mantener su ventaja competitiva.)
Aparte de la necesidad, las cargas de trabajo se muestrean en lugar de
completarlas realmente en varios sistemas de cmputo. Los lineamientos
sobre el muestreo proporcionados en el captulo 5 pueden ser tiles aqu, ya
que en el muestreo de las cargas de trabajo el analista de sistemas toma
una muestra de las tareas necesarias y los recursos de cmputo requeridos
para completarlas.
La siguiente figura es una comparacin de los tiempos requeridos por un
sistema de informacin actual y uno propuesto que se supone manejan una
carga de trabajo dada.

Observe que la compaa est usando actualmente un sistema manual para

preparar un resumen mensual de los envos a sus almacenes de
distribucin, y se est sugiriendo un sistema de cmputo. La comparacin

de las cargas de trabajo toma en cuenta el costo por hora de cada sistema,
cundo y cmo se realiza cada proceso, cunto tiempo humano se requiere
y cunto tiempo de la computadora se necesita.

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".
(crea tu web Alojado en Galeon.com Hispavista) 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

modelos

de

implantacin.
3.3.3 Definicin de requerimientos tcnicos
Comprende los recursos tcnicos y tecnolgicos que debes estar disponibles para
desarrollar la aplicacin, perfil del personal tcnico para dar mantenimiento a la
aplicacin, sistema operativo, herramienta para programacin, base de datos, etc.
Adquisicin de software para la administracin de LOGs y monitoreo de seguridad,
que incluya la configuracin, pruebas, instalacin, administracin, soporte y
mantenimiento. La solucin a contratar debe permitir identificar de manera
anticipada eventos de acceso, disponibilidad e integridad del hardware, software e
informacin y teniendo como premisa principal que estos sistemas (software) deben
garantizar una correcta integracin con el sistema COBIS con el fin de no poner en
riesgo la operacin y rendimiento del sistema.

3.4 Evaluacin y adquisicin de hardware

EVALUACIN DEL HARDWARE DE CMPUTO

La evaluacin del hardware de cmputo es una responsabilidad compartida de
los directivos, usuarios y analistas de sistemas. Aunque los fabricantes

proporcionarn detalles acerca de los productos que ofrezcan, los analistas

necesitan supervisar personalmente el proceso de evaluacin porque ellos se
preocuparn por los mejores intereses del negocio.
Adems, tal vez los analistas de sistemas tengan que ensear a los usuarios y
a los directivos las ventajas y desventajas generales del hardware para que
puedan evaluarlo de manera eficaz.
Con base en el inventario actual del equipo de cmputo y en las estimaciones
adecuadas de las cargas de trabajo actuales y futuras, el siguiente paso en el
proceso es considerar los tipos de equipo disponibles que parezcan satisfacer
las necesidades proyectadas. La informacin que los fabricantes ofrezcan
acerca de los posibles sistemas y las configuraciones de stos ser ms
apropiada en esta fase y debe revisarse de manera conjunta con los directivos
y los usuarios.
Adems, las cargas de trabajo se pueden simular y ejecutar en diferentes
sistemas, incluyendo los que ya se usan en la organizacin. Este proceso se
llama benchmarking (evaluacin comparativa). Entre los criterios que los
analistas de sistemas y los usuarios deben usar para evaluar el desempeo de
los diferentes sistemas de hardware estn los siguientes:
1. El tiempo requerido para las transacciones promedio (incluyendo cunto
tiempo toma la entrada de datos y cunto obtener la salida).
2. La capacidad de volumen total del sistema (cunto se puede procesar al
mismo tiempo antes de que ocurra un problema).
3. El tiempo que la unidad central de procesamiento se mantiene inactiva.
4. El tamao de la memoria proporcionada.
Algunos criterios se presentarn en demostraciones formales; algunos no se
pueden simular y es necesario obtenerlos de las especificaciones de los
fabricantes. Durante las demostraciones es importante estar seguro de cules
son las funciones requeridas y cules las deseadas antes de analizar
detalladamente las afirmaciones de los fabricantes. Una vez que se conocen
los requerimientos funcionales y que se comprenden los productos actuales
disponibles y se comparan con los que ya existen en la organizacin, los
analistas de sistemas deciden en conjunto con los usuarios y los directivos si
es necesario obtener nuevo hardware.
Se puede considerar que las opciones van desde utilizar nicamente equipo
disponible en el negocio hasta adquirir equipo totalmente nuevo. Entre estos

dos puntos hay opciones intermedias como la de hacer modificaciones

menores, o mayores, al sistema de cmputo actual.
Tamao y uso de la computadora: El rpido avance de la tecnologa obliga a
los analistas de sistemas a investigar qu tipos de computadoras estn
disponibles en el momento especfico en que se escribe la propuesta de
sistemas. El tamao de las computadoras va desde las pequeas
computadoras Palm que caben en una mano hasta las supercomputadoras que
podran ocupar toda una sala. Cada una tiene atributos diferentes que se
deben considerar al decidir cmo implementar un sistema de cmputo.

ADQUISICIN DEL EQUIPO DE CMPUTO

Las tres opciones principales para la adquisicin de hardware de cmputo son
la compra, el arrendamiento financiero o el alquiler. Como se muestra en la
siguiente figura, hay ventajas y desventajas que se deben analizar para cada
una de las decisiones.

Algunos de los factores que se deben tomar en cuenta al momento de

determinar cul opcin es mejor para una instalacin en particular incluyen los
costos iniciales versus los costos a largo plazo, si la empresa se puede dar el
lujo de invertir capital en el equipo de cmputo y si desea tener el control total y
la responsabilidad sobre el equipo de cmputo.
La compra implica que la empresa poseer el equipo. Uno de los principales
factores que determinan la compra es la vida proyectada del sistema. Si el
sistema se usar por ms de cuatro a cinco aos (con todos los dems
factores constantes), normalmente se toma la decisin de comprar. Observe

que en el ejemplo de la siguiente figura el costo de compra despus de tres

aos es ms bajo que el del arrendamiento financiero o el alquiler.

Conforme los sistemas se hacen ms pequeos y aumenta la popularidad de

los sistemas distribuidos, la mayora de las empresas se decide por comprar
equipo. Otra posibilidad distinta a la compra es el arrendamiento financiero del
hardware. Arrendar el equipo al fabricante o a una compaa de arrendamiento
de terceros es ms prctico cuando la vida proyectada del sistema es menor a
cuatro aos. Adems, si es inminente un cambio significativo en la tecnologa,
el arrendamiento financiero constituye una mejor opcin. Este esquema
tambin permite a la empresa poner su dinero en otra parte, donde puede ser
ms rentable para la compaa en lugar de invertirlo en bienes de capital.
Sin embargo, el arrendamiento a largo plazo no es una forma econmica de
adquirir equipo de cmputo. La tercera opcin para la adquisicin de
computadoras es el alquiler del hardware de cmputo. Una de las ventajas
principales del alquiler es que no se invierte el capital de la compaa y por lo
tanto no se requiere ningn financiamiento. Tambin, alquilar el hardware de
cmputo facilita cambiar el hardware del sistema. Por ltimo, el mantenimiento
y el seguro se incluyen por lo general en el contrato de alquiler. Sin embargo,
debido a los altos costos que implica y al hecho de que la compaa no ser
duea del equipo alquilado, el alquiler slo se debe considerar como un
movimiento a corto plazo para satisfacer necesidades no recurrentes o
limitadas de cmputo o los tiempos voltiles de la tecnologa
3.4.1

Seleccin

relacionados

implementacin

de

computadores

componentes

Siempre se deben considerar en conjunto los costos y beneficios del sistema de

cmputo propuesto, debido a que con frecuencia estn vinculados y dependen uno
del otro. Aunque el analista de sistemas est intentando proponer un sistema que
cumple los diversos requerimientos de informacin, las decisiones de continuar con
el sistema propuesto se basarn en el anlisis de costo-beneficio, no en los
requerimientos de informacin. En gran medida, los beneficios se miden por los
costos.

CMO PRONOSTICAR LOS COSTOS Y BENEFICIOS

Se necesita que los analistas de sistemas pronostiquen ciertas variables
importantes antes de enviar la propuesta al cliente. Hasta cierto punto, un
analista de sistemas se apoyar en un anlisis de qu pasa si, tal como,
Qu pasa si los costos de mano de obra suben slo 5 por ciento por ao
durante los prximos tres aos, en lugar de 10 por ciento? Sin embargo, el
analista de sistemas debe entender que l o ella no se pueden apoyar
nicamente en un anlisis del tipo qu pasa si si quieren que la propuesta sea
creble, significativa y valiosa. El analista de sistemas tiene disponibles muchos
modelos de prediccin. La condicin principal para escoger un modelo es la
disponibilidad de los antecedentes. Si no estn disponibles, el analista debe
volver a uno de los mtodos de discernimiento: las estimaciones de la fuerza
de ventas, estudios para estimar la demanda del cliente, estudios Delphi (un
pronstico del acuerdo general desarrollado independientemente por un grupo
de expertos a travs de una serie de iteraciones),
Crear guiones o dibujar las analogas histricas. Si los antecedentes estn
disponibles, la siguiente diferencia entre las clases de tcnicas involucra si el
pronstico es condicional o incondicional. El condicional implica que hay una
asociacin entre las variables en el modelo o que dicha relacin causal existe.
Los mtodos comunes en este grupo incluyen correlacin, regresin,
indicadores principales, econometra y modelos de entrada/salida. El
pronstico incondicional significa que no se necesita del analista para encontrar
o identificar cualquier relacin causal. Por consiguiente, los analistas de
sistemas encuentran que estos mtodos son alternativas econmicas y de fcil
implementacin. En este grupo se incluyen el juicio grfico, medias mviles y
anlisis de datos de serie de tiempo. Debido a que estos mtodos son simples,
fiables y rentables, el resto de la seccin se enfoca en ellos.

IDENTIFICACIN DE BENEFICIOS Y COSTOS

Los beneficios y costos se pueden representar como tangibles o intangibles.

Cuando se consideran los sistemas se deben tener en cuenta los beneficios y
costos tangibles e intangibles.

Beneficios tangibles: Los beneficios tangibles son ventajas que se pueden medir en
dlares que se acreditan a la organizacin mediante el uso del sistema de informacin.
Los ejemplos de beneficios tangibles son un aumento en la velocidad del
procesamiento, acceso de otra forma a la informacin inaccesible, acceso a la
informacin en una forma ms oportuna, ventaja por el poder de clculo de la
computadora y las disminuciones en el tiempo del empleado necesario para cumplir
tareas especficas.
Beneficios intangibles: Algunos beneficios que se acreditan a la organizacin
mediante el uso del sistema de informacin son difciles de medir pero aun as son
importantes. stos se conocen como beneficios intangibles. Los beneficios intangibles
incluyen mejorar el proceso de toma de decisiones, incrementar la exactitud, ser ms
competitivo en el servicio al cliente, mantener una buena imagen del negocio e
incrementar la satisfaccin del trabajo para los empleados eliminando las tareas
tediosas.
Aunque los beneficios intangibles de un sistema de informacin son factores
importantes que se deben considerar al decidir proceder con un sistema, un sistema
construido nicamente por sus beneficios intangibles no tendr xito. Debe discutir los
beneficios tangibles e intangibles en su propuesta, debido a que presentar ambos
permitir a tomadores de decisiones del negocio tomar una decisin bien
documentada acerca del sistema propuesto.

COMPARACIN DE LOS COSTOS Y BENEFICIOS

Se conocen muchas tcnicas para comparar los costos y beneficios del
sistema propuesto. Dichas tcnicas incluyen anlisis del punto de equilibrio,
anlisis del tiempo de recuperacin de la inversin, anlisis de flujo de efectivo

y anlisis de valor presente. Todas estas tcnicas proporcionan formas directas

de producir informacin para los tomadores de decisiones sobre el valor del
sistema propuesto.

CMO EXAMINAR LAS ALTERNATIVAS DE SISTEMAS

Con el uso del anlisis del punto de equilibrio, anlisis del tiempo de
recuperacin de la inversin, anlisis de flujo de efectivo y el anlisis de valor
presente, es posible comparar las alternativas para el sistema de informacin.
Como se mostr anteriormente, es importante usar anlisis mltiples para
cubrir adecuadamente las limitaciones de cada enfoque.
Aunque considerar varias alternativas, la propuesta en s recomendar slo
una. De tal manera, que habr hecho un anlisis comparativo sobre qu
sistema hace el mejor sentido econmico antes de que se escriba la propuesta.
Dichos anlisis se pueden incluir para proporcionar apoyo para el sistema que
est recomendando. No piense que slo hay una solucin correcta del
sistema para ayudar a un negocio a resolver sus problemas y alcanzar su
meta.

INTRODUCCION
El desafo es tomar las teoras y aplicarlas considerando las caractersticas especficas
del contexto de trabajo de cada organizacin. Estudios realizados muestran que ms
del 53% de los proyectos de software fracasan por no realizar una adecuada gestin
de requerimientos. Algunos de los motivos ms habituales para llegar a esta situacin
suelen ser la falta de participacin del usuario, la presencia de requerimientos
incompletos o que se modifican en forma permanente sin poder estabilizarse. El costo
de solucionar un error en la etapa de mantenimiento es aproximadamente 200 veces
mayor que solucionarlo en la etapa de requerimientos.

CONCLUSIONES
El anlisis de los requerimientos es una herramienta imprescindible para que el
profesional contable, hoy en da gestor de proyectos medianos y grandes en donde
desarrollan muchos procesos y funciones, y as poder tomar decisiones sobre las
necesidades de sistemas de informacin o detectar alguna falla de las existentes en
base al anlisis de los hechos de todos los equipos de las organizaciones.

Tomar la decisin de seleccionar equipos de cmputo y otros es una tarea un poco

difcil, ya que para ello el gestor de negocios realiza un estudio aplicando diferentes
mtodos como el flujo de caja y algunas proyecciones para evaluar la rentabilidad que
generaran la incursin en la compra de un tipo de hardware para su utilizacin en la
empresa.

BIBLIOGRAFA
Bentley, J. L. (2015). Anlisis de sistemas. Diseo y mtodos . 7ma edicin.
Cceres, E. A. (2014). Anlisis y Diseo de Sistemas de Informacin.
CIAMPAGNA, J. M. (2011). ADMINISTRACION SIG . CURSO ADMINISTRACION
SIG , (pgs. 7-15).
crea tu web Alojado en Galeon.com Hispavista. (s.f.). Obtenido de crea tu
web Alojado en Galeon.com Hispavista:
http://requerimientos.galeon.com/
Formato basado en el documento de especificacin de requerimientos.
(siglo21). Informtica, FO-DS-0011.
SENN, J. A. (Enero 1990 ). Anlisis y Diseo de Sistema de Informacin. Mc
Graw Hill.