http://www.pmoinformatica.com/2018/05/que-es-requerimiento-funcional.

html

miércoles, 30 de mayo de 2018

¿Qué es un requerimiento funcional?
Buscas formación en técnicas para identificar, analizar y gestionar los requerimientos de
software. Curso Online de Ingeniería de requisitos: Software orientado a negocio. Asegurando el
éxito de la producción de software. Para mayor información visita la página del curso.

La identificación, análisis y gestión de los requerimientos funcionales es una actividad crítica en

la ingeniería del software. Por ello, a continuación te contaremos qué es un requerimiento
funcional y por qué su gestión adecuada es fundamental para asegurar el éxito de tus
proyectos.

La gestión de los requerimientos funcionales deficiente, es citada como una de las causas más
frecuentes en el fracaso de los proyectos, es por ello que es importante entender que son los
requerimientos funcionales, bajo qué metodologías deben identificarse y gestionarse para
asegurar el logro de los objetivos.

En este artículo se explica qué son los requerimientos funcionales, cual es la importancia de
definirlos sin ambigüedades y cómo se realiza la gestión de los requerimientos después de que
han sido identificados, bajo enfoques predictivos y metodologías ágiles de gestión de proyectos
de software.

Te presentamos a continuación nuestro artículo sobre que es un requerimiento funcional.

¿Qué son los requerimientos funcionales?

La guía del Business Analysis Body of Knowledge (BABOK) en su version 3, proporciona la

siguiente definición para los requerimientos funcionales de una solución:

“Los requerimientos funcionales son las descripciones explicitas del comportamiento que debe
tener una solución de software y que información debe manejar.”

Por lo tanto, los requerimientos funcionales:

Expresan las capacidades o cualidades que debe tener la solución para satisfacer los
requerimientos de los interesados de proyecto.
Se expresan en términos de cuál debe ser el comportamiento de la solución y que información
debe manejar.
Deben proporcionar una descripción lo suficientemente detallada para permitir el desarrollo e
implementación de la solución.
Son los que más influyen en si la solución será aceptada o no por los usuarios.
Importancia de definir los requerimientos funcionales

Los problemas y errores en la gestión de requerimientos funcionales son citados como una de
las causas más frecuentes que ocasionan insatisfacción de las expectativas de los interesados en
proyectos de software.

Profundizando en las causas de estos problemas, las situaciones observadas con mayor
frecuencia son:

Requerimientos funcionales con descripciones muy ambiguas, produciendo interpretaciones

inadecuadas por parte del equipo de desarrollo.
El requerimiento funcional no fue entendido adecuadamente cuando fue levantado con el
interesado, pasando información incorrecta al equipo de desarrollo.
En su forma original, el requerimiento funcional no era factible técnicamente y el equipo de
desarrollo realizó modificaciones que no fueron aprobadas por los interesados.

Es fundamental la aplicación de metodologías probadas de gestión de requerimientos

funcionales que eviten que estos problemas sucedan, algunas de las prácticas más
recomendadas son:

Ante la presencia de ambigüedades, solicitar información adicional, mesas de trabajo o

reuniones con los interesados. Es menos costoso esperar a obtener una descripción que aclare
las dudas antes que asumir y avanzar en el desarrollo.
Validar las descripciones escritas de los requerimientos funcionales antes de comenzar su
desarrollo.
Cualquier duda que presente el equipo de desarrollo buscar comunicación con los interesados
para su resolución.
Si durante el desarrollo se presentará la necesidad de modificar algún requerimiento funcional
debido a razones técnicas, solicitar mesas de trabajo o reunir, no proceder con un desarrollo e
implementación que no ha sido validado por los interesados.

Siguiendo estas prácticas podemos asegurar una mejor aceptación de los requerimientos
funcionales cuando llegue el momento de la implementación.

Los requerimientos funcionales en un enfoque predictivo

Bajo un enfoque de proyecto predictivo, esto es, un proyecto de software ejecutado con la
metodología de ciclo de vida de desarrollo de sistema (Cascada), esto es, el desarrollo del
sistema se realiza el fases claramente delimitadas, el Análisis, diseño, desarrollo, pruebas e
implementación de la solución.

En la metodología cascada, el desarrollo de un nuevo sistema o requerimiento funcional

individual siempre comienza con una fase de levantamiento y análisis, caracterizada por los
siguientes aspectos:

Especialistas conocidos como Analistas de negocio (Business Analyst) realizan reuniones con los
interesados (Por ejemplo los usuarios de la nueva solución) para levantar cuáles son sus
requerimientos.
Se utilizan distintas técnicas de levantamiento de requerimientos funcionales, como pueden ser
las entrevistas, mesas de trabajo o tormenta de ideas.
De todo este proceso surge un documento de requerimientos de software que describe la
funcionalidad que se espera de la nueva solución.
Para que el enfoque sea exitoso, el documento debe ser lo más detallado posible. Sin embargo,
un problema es que al tener que ser detallado, los revisores pueden verse abrumados,
ocasionado que ciertos errores no sean identificados.
Una vez aprobado, el documento de requerimientos de software se convierte en un contrato,
cualquier aspecto que el equipo de desarrollo no implemente se convierte en una causa de no
aceptación. Por otro lado, cualquier aspecto adicional o cambio solicitado por los interesados
debe llevar un proceso de cambio de alcance.

¿Bajo este enfoque que es un requerimiento funcional? Pues es un comportamiento o

funcionalidad que debe ser cumplida con rigurosidad y exactitud por la solución implementada.

Como se sabe, el surgimiento de las metodologías ágiles ha devenido en muchas críticas al

enfoque predictivo, sin embargo, es necesario que entendamos que existen situaciones en las
que de hecho el enfoque predictivo es el más recomendable.

En situaciones donde tenemos una solución conocida, los estándares para implementar nuevos
requerimientos funcionales están definidos y existe claridad en las reglas por todas las partes, el
enfoque predictivo es el que da los mejores resultados.

Los requerimientos funcionales en las metodologías ágiles

Las metodologías ágiles establecen un enfoque más flexible sobre lo que es un requerimiento
funcional, los proyectos son ejecutados en iteraciones cortas se fomenta una mayor constante
interacción entre usuario y desarrolladores abrazando el cambio en lugar de rechazarlo.

Por ejemplo en el marco de trabajo Scrum:

El dueño de producto (Product Owner) es el que tiene la responsabilidad de la gestión de los

requerimientos funcionales.
Sostiene reuniones con los interesados e identifica los requerimientos funcionales los cuales
luego lleva al equipo de desarrollo de software.
Para las reuniones con los interesados también pueden aplicarse técnicas de levantamiento de
requerimientos, como por ejemplo las entrevistas, mesas de trabajo, entre otras.
Una de las formas de documentar los requerimientos funcionales en metodologías agiles es la
historia de usuario.
La intención es que las historias de los usuarios sean el inicio y no el final de las conversaciones
entre usuarios e interesados sobre la funcionalidad que debe tener el software.
El enfoque ágil fomenta la constante comunicación entre interesados y usuarios, los
requerimientos funcionales se van elaborando progresivamente, priorizando para el desarrollo
los que estén definidos sin ambigüedades.
¿Bajo este enfoque Qué es un requerimiento funcional? Pues es un elemento que se
documenta como una historia de usuario que puede ser elaborado progresivamente y
modificado en función de las necesidades del negocio.

Técnicas para el levantamiento y análisis de requerimientos funcionales

Independientemente de si se aplica un enfoque predictivo o una metodología ágil las técnicas

para el levantamiento y análisis los requerimientos son similares.

¿Te gustaría saber más acerca de cuáles son estas técnicas? te recomendamos los siguientes
artículos:

> 7 Técnicas para el levantamiento de requerimientos

> 8 Técnicas de análisis de requerimientos de software

Gestionar los requerimientos funcionales

Un aspecto que es primordial entender cuando definimos qué es un requerimiento funcional es

la gestión del mismo no finaliza cuando se identifican, analizan y documentan. La gestión de
requerimientos se extiende a largo del ciclo de vida del proyecto e inclusive trasciende a este.

La guía del Business Analysis Body of Knowledge (BABOK) en su version 3, define las actividades
involucradas en la gestión de requerimientos, a saber:

Trazabilidad de requerimientos.
Mantenimiento de requerimientos.
Priorizar requerimientos.
Evaluar cambios en los requerimientos.
Aprobar requerimientos.

En los enfoques predictivos de gestión de proyectos, la gestión de requerimientos es una

especialidad, integrada por una gerencia de requerimientos funcionales y analistas de negocio.
La priorización y aprobación forman parte del proceso de planificación y los cambios en
requerimientos se procesan utilizando un proceso de cambio de alcance.

Por otra parte, las metodologías ágiles como por ejemplo Scrum, integran la gestión de
requerimientos dentro del enfoque, por ejemplo la priorización de requerimientos ocurre de
forma natural manejando un product bakclog que se prioriza de acuerdo al avance que tenga la
elaboración de requerimientos funcionales y su valor para el negocio. Por otro lado, la
evaluación de cambios a los requerimientos se realiza en las reuniones Sprint Review que
ocurren al final de cada iteración.
lunes, 6 de febrero de 2017
Requerimientos funcionales: Ejemplos
Los requerimientos funcionales de un sistema, son aquellos que describen cualquier actividad
que este deba realizar, en otras palabras, el comportamiento o función particular de un sistema
o software cuando se cumplen ciertas condiciones.

Por lo general, estos deben incluir funciones desempeñadas por pantallas específicas,
descripciones de los flujos de trabajo a ser desempeñados por el sistema y otros requerimientos
de negocio, cumplimiento, seguridad u otra índole.

En este artículo, te presentamos ejemplos de requerimientos funcionales, relacionados con

funciones del negocio, datos que deben ingresarse en las pantallas del sistema (interfaz gráfica),
los relacionados con control de acceso o emisión de reportes requeridos por entes reguladores,
entre otros.

PMOInformatica presenta: 40 Ejemplos de requerimientos funcionales de un sistema.

¿Buscas formación en técnicas para identificar, analizar y gestionar los requerimientos de

software? Curso Online de Ingeniería de requisitos: Software orientado a negocio. Asegurando
el éxito de la producción de software. Para mayor información visita la página del curso.

Como se describen y clasifican los requerimientos funcionales

Los requisitos funcionales de un software se suelen registran en la matriz de trazabilidad de

requerimientos y en la especificación de requerimientos de software, este último, documenta
las operaciones y actividades que el sistema debe poder desempeñar.

Entre los posibles requerimientos funcionales de un sistema, se incluyen:

Descripciones de los datos a ser ingresados en el sistema.

Descripciones de las operaciones a ser realizadas por cada pantalla.
Descripción de los flujos de trabajo realizados por el sistema.
Descripción de los reportes del sistema y otras salidas.
Definición de quien puede ingresar datos en el sistema.
Como el sistema cumplirá los reglamentos y regulaciones de sector o generales que le sean
aplicables.

Al igual que otros tipos de requerimientos de software, como por ejemplo los requerimientos
no funcionales, los requerimientos funcionales se pueden clasificar según su finalidad, como por
ejemplo requerimientos de negocio, requerimientos originados en aspectos regulatorios, de
seguridad, entre otros.
http://www.pmoinformatica.com/2015/05/requerimientos-no-funcionales-ejemplos.html

miércoles, 6 de mayo de 2015

Requerimientos no funcionales: Ejemplos

Imagen de: Epicentre

Presentamos la tercera parte de la serie sobre los requerimientos no funcionales, con algunos
ejemplos que puedan servir de guía en su definición.

Los requerimientos no funcionales representan características generales y restricciones de la

aplicación o sistema que se esté desarrollando.

Suelen presentar dificultades en su definición dado que su conformidad o no conformidad

podría ser sujeto de libre interpretación, por lo cual es recomendable acompañar su definición
con criterios de aceptación que se puedan medir.

Entre los ejemplos de requerimientos no funcionales presentados, tenemos los referidos a

atributos como la eficiencia, seguridad, dependibilidad y usabilidad del sistema. También
presentamos ejemplos de requerimientos no funcionales organizacionales y externos.

PMOInformatica presenta: Ejemplos de requerimientos no funcionales.

¿Que son los requerimientos no funcionales y como se clasifican?

Si buscas más información sobre el concepto de requerimientos no funcionales, te

recomendamos la primera parte de esta serie Requerimientos no funcionales: Porque son
importantes

En un primer nivel, los requerimientos no funcionales pueden clasificarse en requerimientos de

producto, organizacionales y externos, tal como te mostramos en el artículo sobre clasificación
de los requerimientos no funcionales.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de

usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales
pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo,
los requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y
legislativos.

Cuando se realizan las fases de levantamiento y análisis de requerimientos, los requisitos no

funcionales se pueden registrar en un documento de requerimientos de software. A
continuación te compartimos una plantilla:

Algunos ejemplos de requerimientos no funcionales

Como mostramos en el artículo sobre clasificación de los requerimientos no funcionales, en un

primer nivel estos pueden clasificarse en requerimientos de producto, organizacionales y
externos.

En un segundo nivel, los requerimientos de producto pueden clasificarse en requerimientos de

usabilidad, eficiencia, dependibilidad y seguridad. A su vez, los requerimientos organizacionales
pueden clasificarse en requerimientos de entorno, organizacionales y de desarrollo. Asimismo,
los requerimientos externos pueden clasificarse en requerimientos regulatorios, éticos y
legislativos.

A continuación presentamos ejemplos de requerimientos no funcionales, clasificados por estas

distintas áreas.

Ejemplos de requerimientos no funcionales de producto

Eficiencia

El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio
de la herramienta SoapUI aplicada al Software Testing de servicios web.
Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos
de 5 segundos.
El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones
concurrentes.
Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que
acceden en menos de 2 segundos.

Seguridad lógica y de datos

Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de
acceso a datos.
El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación
que incrementen la seguridad de datos.
Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser almacenados en
una localidad segura ubicada en un edificio distinto al que reside el sistema.
Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema
deben estar encriptadas utilizando el algoritmo RSA.
Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando
hasta ser desbloqueado por un administrador de seguridad.

Seguridad industrial
El sistema no continuará operando si la temperatura externa es menor a 4 grados Celsius.
El sistema no continuará operando en caso de fuego. (Ej. Un ascensor).

Usabilidad

El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones
totales ejecutadas en el sistema.
El sistema debe contar con manuales de usuario estructurados adecuadamente.
El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario
final.
El sistema debe contar con un módulo de ayuda en línea.
La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada
visualización en múltiples computadores personales, dispositivos tableta y teléfonos
inteligentes.
El sistema debe poseer interfaces gráficas bien formadas.

Dependibilidad

El sistema debe tener una disponibilidad del 99,99% de las veces en que un usuario intente
accederlo.
El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos.
La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación
total.
El promedio de duración de fallas no podrá ser mayor a 15 minutos.
La probabilidad de falla del Sistema no podrá ser mayor a 0,05.

Otros ejemplos de requerimientos de producto

El sistema será desarrollado para las plataformas PC y Macintosh.

La aplicación debe ser compatible con todas las versiones de Windows, desde Windows 95.
La aplicación deberá consumir menos de 500 Mb de memoria RAM.
La aplicación no podrá ocupar más de 2 GB de espacio en disco.
La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español,
Frances, Portugués, Italiano), Arábico y Chino.
La interfaz de usuario será implementada para navegadores web únicamente con HTML5 y
JavaScript.

Ejemplos de requerimientos no funcionales organizacionales

El procedimiento de desarrollo de software a usar debe estar definido explícitamente (en

manuales de procedimientos) y debe cumplir con los estándares ISO 9000.
La metodología de desarrollo de software será Behaviour Driven Development (BDD) apoyada
en Cucumber.
El sistema debe ser desarrollado utilizando las herramientas CASE XYZ.
El proceso de desarrollo se gestionará por medio de una determinada herramienta web para
gestionar el proceso de desarrollo de software.
Debe especificarse un plan de recuperación ante desastres para el sistema a ser desarrollado.
Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre el esfuerzo
invertido en cada uno de los componentes del nuevo sistema.
Las pruebas de software se gestionaran con una herramienta de gestión de software testing.
Las pruebas de software se ejecutarán utilizando Selenium y Ruby como herramienta y lenguaje
Scripting para automatización de software testing.

Ejemplos de requerimientos no funcionales externos

Sistemas de datos médicos: El nuevo sistema y sus procedimientos de mantenimiento de datos

deben cumplir con las leyes y reglamentos de protección de datos médicos.
El nuevo sistema se acogerá a las reglas de las licencias generales públicas (GNU), es decir será
gratuito, código abierto en el que cualquiera podrá cambiar el software, sin patentes y sin
garantías.
Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en condiciones de
igualdad para personas con discapacidad.
El sistema no revelara a sus operadores otros datos personales de los clientes distintos a
nombres y números de referencia.

Requerimientos no funcionales y requerimientos funcionales

Los requerimientos no funcionales suelen expresarse de una manera general y sin hacer
referencia a algún modulo, transacción o característica del sistema, pues sino pasarían a ser
requerimientos funcionales.

Por ejemplo:

El sistema debe asegurar que los datos estén protegidos del acceso no autorizado

Es recomendable acompañar las definiciones de requerimientos no funcionales con criterios de

aceptación que puedan medirse.

Los requerimientos no funcionales pueden a su vez derivar en requerimientos funcionales,

tomando como ejemplo el anterior:

El sistema incluirá un procedimiento de autorización de usuarios, en el cual los usuarios deben

identificarse usando un nombre de usuario y contraseña. Sólo los usuarios autorizados de esta
forma podrán acceder a los datos del sistema.

Escrito de esta forma, el requerimiento pasa a ser funcional.

Sin embargo, no todos los requerimientos no funcionales pueden derivarse en requerimientos

funcionales, por lo cual es muy importante definir los criterios de aceptación.
Requerimientos funcionales de un sistema de ventas
Al definir los requerimientos funcionales de un sistema de ventas, debemos considerar distintos
escenarios que se nos pueden presentar, por ejemplo, si la empresa es un distribuidor o fabrica
que despacha desde un almacén, es un detallista que vende en tienda o por otro lado si lo que
se están vendiendo son servicios.

En este artículo abarcaremos ejemplos de requerimientos funcionales de las distintas etapas de

un sistema de ventas, incluyendo el maestro de clientes, productos que se van a vender, lista de
precios, pedido de venta, ordenes de despacho y facturación.

Te presentamos a continuación el artículo: Requerimientos funcionales de un sistema de ventas.

Proceso de ventas a definir por medio de requerimientos funcionales

Antes de definir los requerimientos funcionales de un sistema de ventas, es importante obtener

un entendimiento de los pasos del proceso de negocio a representar. Es por esto que el
flujograma en la gerencia de proyectos es fundamental.

Previamente a que un sistema de ventas entre en funcionamiento, es necesario registrar los

productos que se van a vender y sus precios. Estos registros se podrán modificar
posteriormente. Luego de esto, ante cada transacción de cliente, primero es necesario registrar
sus datos, por ejemplo el nombre, número fiscal y dirección, para luego registrar lo que desea
pedir.

Luego del registro del pedido, se procede a registrar un despacho de mercancía y la factura.

En la siguiente figura, mostramos un flujograma general para un proceso de ventas.

Pueden existir variantes a este proceso, por ejemplo, en un sistema de ventas al detal, el
pedido, entrega y factura es una sola transacción. Por otra parte, si lo que estamos vendiendo
es un servicio, no manejamos un pedido sino un convenio, solicitud de servicio o contrato
establecido previamente.

Requerimientos funcionales de un sistema de ventas

Los requisitos funcionales de un software se suelen registran en la matriz de trazabilidad de

requerimientos y en la especificación de requerimientos de software, este último, documenta
las operaciones y actividades que el sistema debe poder desempeñar.

Al igual que otros tipos de requerimientos de software, como por ejemplo los requerimientos
no funcionales, los requerimientos funcionales se pueden clasificar según su finalidad, como por
ejemplo requerimientos de negocio, requerimientos originados en aspectos regulatorios, de
seguridad, entre otros.

Para los ejemplos nos enfocaremos en un proceso de ventas de un distribuidor o fabrica,

compuesto por transacciones de pedido, despacho y facturación. Clasificaremos los
requerimientos por el subproceso de negocio al cual corresponden.

A continuación te presentamos los ejemplos de requerimientos funcionales para un sistema de

ventas:

El proceso de ventas en el sistema abarcará los siguientes pasos: Ingreso de pedido de venta,
emisión de orden de entrega (despacho), facturación y cobranza.
El sistema enviará un correo electrónico cuando se registre alguna de las siguientes
transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de factura
a cliente y registro de pago de cliente.

Maestro de clientes

El sistema manejará un registro maestro de clientes. Sólo los usuarios autorizados podrán
ingresar nuevos clientes, modificar los datos o eliminarlos.
Para crear un registro maestro de cliente, se solicitará como mínimo el nombre del cliente y su
número de identificación fiscal.
Se permitirán asociar varias direcciones al registro de cliente y se le podrá asignar a cada
dirección un propósito, por ejemplo dirección fiscal, dirección de despacho, entre otros. Al crear
el registro maestro, el sistema asignará un código de cliente.
Se permitirá ingresar clientes sin número de identificación fiscal o dirección, sin embargo, no se
podrán procesar pedidos a dichos clientes hasta que cuenten con esa información.
El registro maestro de clientes tendrá asociado un límite de crédito.

Maestro de materiales (ítems) y lista de precios

El sistema permitirá manejar un maestro de materiales y productos, en el cual se registrarán

todos los ítems que se pueden vender. Cada item debe tener al menos su nombre, unidad de
medida y descripción.
El sistema debe manejar listas de precios. El usuario podrá agregar, modificar o eliminar listas
de precios.
Las listas de precios tendrán un período de vigencia (fecha inicial y fecha final).
Al crear la lista de precios se agregarán los materiales e ítems, los cuales deben estar registrados
previamente en el maestro de materiales. Para cada uno deberá especificarse un precio.
El acceso a la lista de precios estará restringido solamente a un grupo de usuarios autorizados.
Se podrán crear listas de precios convenidos con un cliente. La misma tendrá fechas inicio y fin
de vigencia del convenio y se le podrán agregar ítems del maestro de materiales y definir su
precio convenido.

Pedidos de venta

Al ingresar un pedido de venta se deberá asignar un cliente. El cliente deberá estar creado en el
maestro de clientes, se permitirá realizar búsquedas por nombre de cliente o número fiscal.
Al ingresar el pedido de venta, se podrán ingresar una o más líneas al pedido. El usuario podrá
seleccionar el item a agregar de una lista que proviene de un registro maestro de materiales y
lista de precios.
Al seleccionar un item, se mostrará su descripción y su precio. Se podrán realizar búsquedas por
nombre o familia de material. Para finalizar el registro de la línea, es obligatorio especificar la
cantidad.
Al seleccionar un item de pedido, el precio será determinado a partir de las listas de precio
autorizado. Si existe un convenio vigente para el item con el cliente seleccionado, se tomará el
precio del convenio, si no existe un convenio se tomará el precio de la lista general de precios.
El precio no podrá ser modificado.
La dirección de facturación y despacho del pedido se obtendrá del maestro de cliente
seleccionado. El usuario no podrá modificar las direcciones.
El límite de crédito se verificará al momento de ingresar un pedido, en caso de existir pedidos
abiertos para el cliente por montos superiores al límite de crédito, se mostrará un mensaje de
alerta y no se permitirá registrar el pedido en definitivo, pero si lo podrá registrar como
borrador.
En todo momento, el pedido se podrá registrar en borrador, pudiendo ser modificado y
registrado en definitivo posteriormente.
El sistema llevará un control de las cantidades que se están pidiendo, en relación con las
cantidades existentes en inventario. Al registrar un pedido, en caso que exista inventario
suficiente el sistema dará de alta al pedido y registrará una reserva de ese material o producto
reservada para ese pedido.
Al ingresar el pedido en definitivo, el sistema verificará línea por línea las cantidades pedidas vs.
Cantidades de materiales existentes en inventario. Si la cantidad pedida excede las cantidades
existentes en inventario más las cantidades que ya están reservadas para otros pedidos, la línea
de pedido afectada será colocada en una cola de pedidos pendientes.
Mientras existan líneas de pedido en una cola, las líneas de pedidos subsecuentes del mismo
material serán colocadas también en la cola.
Un proceso automatizado revisará periódicamente las líneas de pedido que se encuentran en
cola, si ya existe material o productos para poder pasar la línea a definitiva el sistema lo
realizará automáticamente. El sistema dará de alta al pedido y registrará una reserva de ese
material o producto reservada para ese pedido.

Ordenes de entrega (Despacho)

A cada orden se le asignará un identificador único, que será utilizado para reconocerla en todos
los procesos subsecuentes que se realicen sobre esta.
Una vez registrado el encabezado, se procederá a registrar las líneas de la orden de entrega.
Toda línea de orden de entrega deberá estar asociada a una línea de pedido a la cual ya se le dio
de alta en el sistema. Esto es, que ya ha superado el proceso de verificación (descrito en los
requerimientos funcionales de pedido), que garantiza que exista cantidad en inventario
reservada para el mismo.
Las cantidades de entrega se tomarán del pedido de venta asociado, no se podrán asignar
materiales o ítems diferentes a los del pedido.
El sistema permitirá órdenes de entrega parciales.
Se permitirán líneas de orden de entrega asociadas a distintos pedidos, siempre y cuando estos
sean del mismo cliente.
Al registrar la orden de entrega, se realizará la rebaja de los inventarios de materiales o
productos.

Facturación de pedidos de venta

La facturación de pedidos de venta se realizara en lotes, por medio de una pantalla de pedidos
pendientes de facturación, la cual mostrará los pedidos no facturados. Una vez facturados los
pedidos no se mostrarán en esta lista.
Para factura asociada a pedido, sus líneas serán determinadas exclusivamente a partir del
pedido, con las cantidades y precios definidos previamente. No se podrán modificar ni
cantidades ni precios.
Se permitirá incluir varios pedidos de venta en una misma factura. La línea de la factura
mostrará el número de pedido al que esté asociado.
El sistema también permitirá el registro de facturas manuales no asociadas a pedidos, sin
embargo, estas requerirán autorización por parte del grupo de Gerentes antes de ser
contabilizadas.
El libro de venta será emitido en el formato establecido por las autoridades tributarias de dicha
materia.
La contabilización de transacciones de facturas de venta podrá configurarse para realizarse de
forma automatizada a su registro, o manualmente en lotes (Proceso Batch).

Al realizar un levantamiento de los requerimientos funcionales de un sistema de ventas, es

necesario contar con una plantilla para su documentación, te compartimos una en el siguiente
enlace:

Cuando se realizan las fases de levantamiento y análisis de requerimientos, los requisitos no

funcionales se pueden registrar en un documento de requerimientos de software. A
continuación te compartimos una plantilla

Metodología Gestión de Requerimientos. Cap. 2. Técnicas para Identificar Requerimientos.

https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-
funcionales-y-no-funcionales

Técnicas para Identificar Requisitos Funcionales y No Funcionales

Contenidos

1 Identificación de Requerimientos funcionales

2 Identificación de Requerimientos no funcionales
3 Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no
funcionales
4 Identificación de elementos
5 Preguntas generales:

Ya que los requerimientos de sistemas de software se clasifican en funcionales y no funcionales,

se deben tener en cuenta las siguientes técnicas para la identificación correcta.

Identificación de Requerimientos funcionales

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la
manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos
funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la

especificación de requerimientos. Para un desarrollador de sistemas es natural dar
interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin
embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos
requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e
incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa

y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están
definidos. La consistencia significa que los requerimientos no tienen definiciones
contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de

consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente
del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades
inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por
primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se
hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se
deben corregir en el documento de requerimientos.

Identificación de Requerimientos no funcionales

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que
entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta
en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones
del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos
que se utiliza en la interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones
en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con
otros sistemas de software o hardware o a factores externos como los reglamentos de
seguridad, las políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los

requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se
requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de
portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la

organización del cliente y en la del desarrollador: estándares en los procesos que deben
utilizarse; requerimientos de implementación como los lenguajes de programación o el método
de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el
producto y su documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de

desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el
sistema interactúa con los otros sistemas de la organización; los requerimientos legales que
deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos.
Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es
posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de
mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma
objetiva los requerimientos no funcionales cuantitativos es muy alto.

En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de

requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de
forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se
declaran con los requerimientos funcionales, es difícil separar las condiciones funcionales y no
funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe
hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin embargo, los
requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben
resaltar. Esto se hace colocándolos en una sección aparte o diferenciándolos, de alguna forma,
de los otros requerimientos del sistema.

Aspectos a tener en cuenta en la identificación de requerimientos funcionales y no funcionales

Requerimientos básicos: se estructura su identificación al buscar respuestas a preguntas como:

• ¿Cuál es el proceso básico de la empresa?

• ¿Qué datos utiliza o produce este proceso?

• ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?

• ¿Qué controles de desempeño utiliza?

Siempre se debe comenzar con lo básico. Cuando se hacen preguntas y se reciben respuestas,
se proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que
sirven para describirlo.

Las siguientes preguntas son de utilidad para adquirir la comprensión necesaria:

• ¿Cuál es la finalidad de la actividad dentro de la empresa?

• ¿Qué pasos se siguen para realizarla?

• ¿Dónde se realizan estos pasos?

• ¿Quiénes los realizan?

• ¿Cuánto tiempo tardan en efectuarlos?

• ¿Con cuánta frecuencia lo hacen?

• ¿Quiénes emplean la información resultante?

Identificación de elementos
Durante esta, se debe identificar muy claramente los siguientes elementos:

• Procesos

• Flujos de datos entre procesos

• Datos de cada flujo de datos

• Bases de datos

• Datos de las bases de datos

Preguntas generales:
• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el
sistema; o sea, cuántos tienen relación directa con el proyecto

• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?

• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?

• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño documentados

oficial o no oficialmente?. Si los hay, ¿Se cumplen en forma cabal en el 100% de las ocasiones?,
es decir, ¿se respetan dichos procedimientos?

• ¿Existen métodos para evadir el sistema?, ¿Por qué se presentan?

• ¿Qué áreas necesitan un control específico?

• ¿Qué criterios se emplean para medir y evaluar el desempeño?

file:///C:/Downloads/Anexo%201B.%20Requerimientos%20Detallados%20No
%20Funcionales.pdf