Reglas de Negocio

Las reglas de negocio complementan los procesos de negocio y las máquinas de estado. Por
ejemplo, si existe una condición con una variable, puede utilizar una regla de negocio para cambiar
el valor de esa variable en tiempo de ejecución.

Si hay una condición con una variable, por ejemplo, una regla de negocio puede cambiar el valor
de dicha variable durante la ejecución. Creada a través de un lenguaje de programación visual, una
regla de negocio toma una decisión basada en el contexto. La decisión puede ser simple o
compleja. Las reglas de negocio no son de procedimientos y se pueden cambiar con independencia
de una aplicación. Las reglas de negocio determinan el resultado de un proceso basándose en un
contexto.

Los reglas de negocio se utilizan en las situaciones de negocio cotidianas para tomar una decisión
en un conjunto específico dado de circunstancias. Esta decisión puede requerir muchas reglas para
cubrir todas las circunstancias. Las reglas de negocio dentro de un proceso de negocio permiten
que las aplicaciones respondan rápidamente a condiciones empresariales cambiantes. En una
empresa de seguros, por ejemplo, una regla de negocio para aprobar el seguro de un coche a un
solicitante podría ser: si el solicitante es hombre y mayor de 25 años, y la categoría del coche es
deportivo y, durante los últimos 5 años tiene el seguro del coche con nuestra empresa, se aprueba
la solicitud de seguro a una tarifa de 100 euros al mes.

Puede utilizar varios métodos diferentes cuando cree reglas de negocio. Puede crear reglas if-then
o tablas de decisiones, que conforman todas ellas el resultado del proceso. Tenga en cuenta que
estas reglas son independientes del propio proceso, lo que significa que puede cambiar las reglas
en cualquier momento sin tener que rehacer el proceso. Por ejemplo, basándose en la ubicación
de la empresa, es posible que tenga una regla que indique: si la fecha está entre el 26 de
diciembre y el 1 de enero, ofrezca una descuento del 20% post vacacional. Sin embargo, si el
descuento sigue siendo demasiado bajo, lo podría modificar en cualquier momento a un
descuento de 40%.
Las reglas de negocio no se pueden utilizar en un módulo de mediación.

Metodología Gestión de Requerimientos

El éxito de un proyecto de software radica, entre otros factores, en la elección correcta de un

proceso que conduzca a desarrollar un buen sistema de software. La elección de la metodología
adecuada es más importante que utilizar las mejores y más potentes herramientas

La metodología propuesta para la Gestión de Requerimientos contiene los siguientes procesos, los
cuales estan definidos en cada uno de los capítulos que hacen parte de esta metodología.
Capítulo 1 "IDENTIFICACIÓN DE NECESIDADES CON EL 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 u obteniendo la documentación que describa la manera que el cliente desea como
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.

Para que la metodología sea efectiva en los puntos descritos se definieron las siguientes
actividades que se deben desarrollar para la correcta identificación de necesidades de los clientes:

Obtener y Analizar información de las necesidades del cliente.

Para hacer una correcta identificación de los clientes y poder realizar un análisis de manera
asertiva se pueden implementar una serie de técnicas de acuerdo al cliente con el que se esté
tratando. Como apoyo a esta etapa la metodología presenta algunas técnicas con las que se
pueden identificar las necesidades de manera tal que el análisis sea apropiado para satisfacer las
expectativas del cliente. Estas técnicas se encuentran en el Capitulo 2. Técnicas para identificar
requerimientos.

Definición del alcance.

La definición del alcance tiene como propósito describir y delimitar claramente las necesidades del
cliente, las cuales pretenden ser cumplidas con el proyecto.

Es importante para la definición del alcance la identificación de los siguientes aspectos:

 Los entregables que hacen parte del alcance. Se recomienda describir y listar los
entregables finales, principalmente los que deben ser aprobados por el cliente.

Nota: no mencionar documentos propios del proyecto como cronograma, estimaciones, entre
otros.

 Los tipos de datos que están en el alcance y fuera de él. Los “tipo de datos” se refieren a la
categoría del negocio de los entregables tales como datos financieros, datos de ventas,
datos de los empleados, etc.

 Las fuentes de datos (bases de datos) que están en el alcance y fuera de él. Esto es similar
a los tipos de datos, excepto que ahora se está refiriendo a los datos agregados tales como
base de datos de clientes, Contabilidad general, sistema de facturación y cobranza, etc.

 Áreas involucradas en el alcance y fuera de él. En algunos casos, las áreas involucradas en
el proyecto ayudan a delimitar el alcance.
  Condiciones fuera del alcance. Se recomienda como punto de claridad y contraste al
describir entregables que no serán creados, qué organizaciones no serán impactadas, qué
facilidades y funciones no serán incluidas, entre otros aspectos.

Fuentes de información claves.

Cualquier información creada anteriormente debe ser usada como base para definir el alcance de
manera mas detallada. Si por alguna razón no se cuenta con suficiente información para la
definición del alcance, se debe buscar apoyo con el patrocinador para reunir información
adicional.

Si se tienen objetivos del proyecto, se recomienda tenerlos en cuenta para ayudar a afinar el
alcance. Por definición, se deben crear uno o más entregables para cumplir cada objetivo, y definir
los entregables del proyecto es uno de los aspectos principales del alcance del proyecto.

Recomendaciones para definir el alcance.

Algunas recomendaciones para la definición del alcance son:

 Desarrollar un escrito o documento formal.

 Detallar claramente qué actividades y procesos son parte del proyecto, es decir, el trabajo
que debe ser realizado con el fin de entregar un producto con las características y
especificaciones solicitadas.
 Definir los criterios que se utilizarán para determinar si el proyecto o fase ha finalizado
exitosamente, es decir, los criterios de aceptación.
 Al definir el alcance, tener en mente que lo que no esté en el alcance está fuera del
proyecto.
 Formalizar la aceptación del alcance con el cliente.
Beneficios de una buena definición.

El alcance marca la pauta para la toma de decisiones futuras y realización de actividades a nivel
Operativo y nos ayuda a:

 Mejorar la precisión en las estimaciones de tiempo, costo y recursos.

 Facilitar la asignación clara de recursos y responsabilidades.
 Definir la línea base para la medición del desempeño y control
 Identificar, tanto el equipo de proyecto como el cliente, el objetivo final del proyecto y sus
entregables.
 Desarrollar y confirmar un entendimiento común del proyecto entre ambas partes, cliente
y equipo de proyecto.
 Asegurar que el proyecto incluye todo el trabajo requerido y solamente el trabajo
requerido para terminar exitosamente. "Asegurar que el proyecto incluye todo el trabajo
requerido para terminar exitosamente."

Entregable de Identificación de Necesidades.

El presente documento será trabajado de la mano del cliente, principalmente cuando no se cuenta
con documentación previa que sirva como base para aclarar las necesidades del cliente.
Capítulo 2 TÉCNICAS PARA IDENTIFICAR REQUERIMIENTOS.

En la actualidad las organizaciones enfocadas al desarrollo de aplicaciones de software utilizan

diferentes herramientas que permiten facilitar la fase de identificación de requerimientos, puesto
que se presta mayor atención a las necesidades que se identifican en todas las fases del ciclo de
vida del sistema; para así obtener un mejor aprovechamiento, entendimiento, y rendimiento al
momento que entre en ejecución el sistema que se esté desarrollando.

Las organizaciones actuales utilizan múltiples herramientas para el apoyo de la identificación de

los requerimientos, sin pensar si son las más convenientes para el proyecto que se esté
desarrollando, por lo tanto a continuación se encontraran las técnicas que apoyen una correcta
identificación de los requerimientos para los proyectos de desarrollo de software.

A continuación se especifican cada una de las técnicas utilizadas:

 Técnicas generales para la identificación de requerimientos

 Técnicas específicas para la identificación de requerimientos
 Técnicas para Identificar Requisitos Funcionales y No Funcionales
 Técnicas de investigación de los atributos de las necesidades de los clientes

A continuación se presenta documento de uso opcional como apoyo para identificación y

definición de requerimiento:

1. Técnicas generales para la identificación de requerimientos

Contenidos

1. Entrevista
2. Lluvia de ideas
3. Cuestionarios

Las técnicas agrupadas como generales son las que permiten investigar aspectos generales para
posteriormente ser especificados con un mayor detalle con el apoyo de técnicas más específicas.
Estas técnicas son más abiertas y requieren ser adecuadamente orientadas para cubrir la
información que se requiere capturar, es importante que para sacar el mayor provecho de estas
técnicas se debe tener un dialogo lo más abierto posible entre las organizaciones de desarrollo de
software y las empresas cliente.

Entrevista

Estas técnicas son muy utilizadas para la recolección de opiniones, criterios o descripciones sobre
diferentes actividades. Se lleva a cabo mediante conversaciones estructuradas donde es
fundamental que la relación con el cliente este basada en la confianza para dar a conocer la
información de la manera mas detallada.

Antes de iniciar una entrevista es importante tener en cuenta los siguientes Tips a tener en cuenta,
no es obligación realizarlas todas pero si es recomendable estudiar cuales son las que más se
aplica para cada organización o cada proyecto.

1. Estudiar el tipo de personas a las cuales se les realizará la entrevista.

2. Estudiar como será el entorno donde se llevara a cabo la entrevista para identificar que
tan confortables estarán las personas y así obtener la información de la manera más
eficiente.
3. Estudiar como es la manera de hablar de las personas individualmente o en un equipo de
trabajo.
4. Verificar que las personas tengan la disponibilidad para dar a conocer las necesidades que
posterior a esto se puedan convertir en requerimientos.
5. Revisar como es la relación del cliente con la organización que realizará la identificación de
los requerimientos, esto con el fin de facilitar el trabajo y la disposición de ambas partes.
6. Entender que es importante obtener la mayor información para la definición de los
requerimientos, teniendo en cuenta que nada es obvio para las organizaciones de
desarrollo de software.

Lluvia de ideas
Esta técnica es abierta y se utiliza para explorar necesidades iniciales con la ayuda de la
identificación de ideas de todas las personas que hacen parte del equipo de apoyo para la
identificación de los requerimientos. Es utilizada para investigar nuevos servicios o necesidades
que no son claramente identificadas.

Algunos Tips para tener en cuenta cuando se realice una lluvia de ideas:

1. Escoger un sitio tranquilo que permita que las personas involucradas se sientan cómodas y
dispuestas para dar a conocer sus ideas.
2. Tomar la iniciativa para iniciar una reunión enfocada en la confianza.
3. Tomar nota de las ideas que las personas expresan en los equipos de trabajo.

Tener una preparación sobre el tema que se va a desarrollar en la lluvia de ideas.

Cuestionarios

Esta técnica puede ir dirigida a un público específico o general, lo que permite obtener una
información mayor, ya que se tiene la posibilidad de involucrar más personas para el desarrollo de
los cuestionarios y que estos tengan diferentes puntos de vista. Lo importante es tener en cuenta
que se debe tener un mayor cuidado en la selección de los encuestados y de la forma en que se
pregunta para obtener respuestas concretas y confiables.

2. Técnicas específicas para la identificación de requerimientos.

Las técnicas agrupadas como especificas son las que permiten complementar las técnicas
generales, para así obtener mayor detalle y eliminar ambigüedad en la información inicial.

Observación
Esta técnica permite obtener información directa sobre la forma en que se realizan las actividades.
Es una técnica que sirve para revisar que no existen omisiones o interpretaciones erróneas sobre
el proceso que se realiza. Hay que tener en cuenta que se debe utilizar si el cliente lo permite y si
el proyecto así lo amerita.

Escenarios

Esta técnica permite conocer el comportamiento del producto ante determinados eventos
considerando los datos, acciones y excepciones que se pueden presentar. El análisis de casos de
uso es un ejemplo de aplicación de esta técnica.

3. Técnicas para Identificar Requisitos Funcionales y No Funcionales.

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?

Técnicas de investigación de los atributos de las necesidades de los clientes.

En realidad, quien conoce sus necesidades es el cliente y, consecuentemente, lo que se hace es

preguntarle a él sobre cada una de ellas, con el objeto de clasificar y ponderar su importancia.

Este proceso de investigación debe ser suficientemente inteligente para conseguir respuestas que
permitan elevar realmente el nivel de competitividad de la solución buscada.

En definitiva, se recomienda escuchar y entender lo que los estudiosos de la calidad llaman la voz
del cliente.

Bajo una perspectiva de innovación proactiva, para la identificación de necesidades, se requieren

métodos en los cuales el cliente pueda compartir su esfera de conocimientos de aplicación con
mayor riqueza y detalle que en los simples informes de reclamación. Entre estos métodos están:

Grupos focales

Los grupos focales se conforman reuniendo a un grupo seleccionado de clientes, conjuntamente

con un moderador que va a conducir un debate de grupo sobre una serie de aspectos y cuestiones
concretas en las que se focaliza la discusión. Esta técnica de investigación alcanza mayor
profundidad que la encuesta y que los informes anteriores.
En la reunión se establece, de por sí, una relación de afinidad por la que todas las respuestas giran
en torno a la situación a analizar. El contexto de uso y aplicación del producto y las características
que se estudian van quedando claros para todos, más si desde el principio el moderador tiene la
habilidad de exponer el propósito de la reunión con nitidez.

Se elimina, pues, uno de los problemas de la encuesta. Al mismo tiempo, se consigue más
información y de mayor calidad que en los informes. Primero, porque se cuenta con expertos
elegidos e identificados, que pueden matizar y contrastar las respuestas entre ellos, aportando
puntos de vista específicos de sus ámbitos de aplicación y segundo, porque en todo momento se
pueden aclarar dudas y profundizar en el tema hasta lograr su total comprensión.

La habilidad para conducir el debate, sugerir y plantear los temas, atemperar las discusiones sobre
aspectos banales y centrarla en los relevantes, es una cuestión que va a determinar la cantidad y
calidad de la información a obtener.

Entrevista individual

Una técnica de investigación más eficaz que la anterior es la entrevista individual entre un experto
del cliente y un entrevistador cualificado del equipo de análisis. Esta tiene alguna ventaja
adicional sobre el grupo focal, como el que se pueden matizar, en un ambiente de mayor
privacidad, los aspectos con mayores atributos de impacto.

Si el moderador, en el caso de los grupos focales, era importante, el entrevistador juega aquí un
papel crítico. No sólo tiene que dominar las técnicas de la entrevista, como el saber preguntar, el
crear un clima de cooperación, sino que, además debe reunir la experiencia y dominio suficiente
sobre el tema a discutir para generar en el cliente una motivación positiva, en el sentido de que se
está tratando de descubrir los conocimientos de uso del producto que pueden realmente incidir
en innovaciones que mejoren el rendimiento de su actividad y su satisfacción.

Análisis contextual

En la medida en que el conocimiento del cliente cobra importancia para el diseño del nuevo
requerimiento, la comprensión de los detalles y particularidades de uso comienza a ser vital para
la innovación proactiva.

Con esta técnica, lo que se hace es, no sólo pedir al cliente que cuente su experiencia de uso y
responda a las sagaces y hábiles preguntas de los métodos anteriores, sino que se le solicita,
además, ver cómo utiliza el producto para comprender el por qué de su necesidad y discutir sobre
el terreno cada uno de los detalles y particularidades de uso. En esta técnica de análisis, la
colaboración del cliente pasa de contar y relatar su experiencia y opinión, desde luego en sus
expresiones y en sus propios términos, a dejar ver al fabricante cómo realmente se construye esa
opinión y se acumula esa experiencia.

Clientes piloto
Un método de investigación más sofisticado es utilizar clientes piloto. Clientes de alto prestigio y
conocimiento que pueden ofrecer un formidable campo de pruebas para el nuevo producto. Claro
está que no es fácil encontrar este tipo de clientes piloto, pero también es claro que los beneficios
de esta técnica son elevados. Si el cliente es un colaborador más a la hora de descubrir atributos
de impacto y de mejorar los de rendimiento, se está contando realmente con una ayuda
especializada, con una opinión experta, que aconseja y valida diseños, que contrasta y mide
rendimientos y que, de alguna manera, se involucra en el desarrollo.

Arthur D. Little llama a este tipo de clientes «lead adopters» y señala algunas condiciones que
deben cumplir con ese papel de cliente piloto. En primer lugar, se espera que sean empresas
exigentes en aquellos aspectos del producto que se quiere verificar. Se está solicitando que sean
más exigentes que la media de los demás clientes, para estar seguros de que el proceso trata con
rigor y profundidad, incluso con severidad, las características a estudiar.

En segundo lugar, se les pide liderazgo en el producto, es decir, se trata de clientes de reconocido
prestigio por su conocimiento y experiencia en su campo de actividad. Se induce, pues, que su
potencial para aplicar el nuevo producto y sugerir cambios, corregir defectos o completar
características, es elevado.

Con la aplicación de esta técnica se busca dar el primer paso hacia la tendencia actual de
integración de la empresa en amplias redes de cooperación. En la red, clientes y proveedores
colaboran, no sólo en la generación de valor, sino también en su gestión, contribuyendo a crear
estructuras operativas eficaces, consistentes y dinámicas con las que afrontar la creciente
diversidad y dificultad de los mercados.

Capítulo 3 DEFINICIÓN REQUERIMIENTOS.

Para tener una buena definición de requerimientos es necesario realizar una buena identificación
de los mismos, posterior a esto es importante definirlos de manera detallada, donde se involucre
la información aportada por los usuarios

Para realizar una correcta definición de los requerimientos del proyecto y que éstos satisfagan las
necesidades verdaderas del cliente, se deben tener en cuenta las siguientes actividades.

Definición de Requisitos.
Para realizar con éxito la definición de los requerimientos es importante conseguir que los
requerimientos sean claramente definidos para minimizar la ambigüedad de los requerimientos,
para esto es importante tener en cuenta lo siguiente:

 Definir los requerimientos teniendo en cuenta la información identificada con la

perspectiva del usuario
 Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen
material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que
un requisito ha sido especificado satisfactoriamente para un producto y que el producto
ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las
veces que se desee teniendo en cuenta los derechos de autor.
 Se debe documentar los requerimientos de una forma clara y correcta. En la mayoría de
los proyectos se observa que la documentación de los requerimientos puede parecer una
tarea tediosa, pero es la única manera de asegurar que la esencia de los requisitos ha sido
capturada correctamente, y que esto pueda ser probado.

Clasificación de requerimientos.

Estos requerimientos se utilizan para determinar que hará el Software, definiendo las relaciones
de su operación y su implementación, sin olvidar que deben ser explícitos también en lo que el
sistema no debe hacer y que validaciones se deben realizar, teniendo en cuenta cual será el
comportamiento del sistema.

Los Requerimientos funcionales se pueden dividir en dos puntos de vista: El primero tiene relación
con el usuario, donde se identifica la relación del usuario con el sistema desde el punto de vista del
mismo; El segundo tiene relación con el sistema dando respuesta al usuario, es decir desde el
punto de vista de lo que realiza el sistema.

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 con lo solicitado por el usuario

Requerimientos no funcionales

Estos requerimientos se basan en las restricciones de los servicios o funciones ofrecidos por el
sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, usabilidad,
portabilidad, entre otros.

Los Requerimientos funcionales son los 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.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones
en el presupuesto, a las herramientas utilizadas, 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, etcétera.

Los dos tipos de requerimientos especificados son de gran importancia para el desarrollo de una
aplicación en software, por lo tanto siempre deben ser escritos con claridad, contener la mayor
especificación de las necesidades expuestas por el cliente, esto con el fin de tener un soporte base
desde el cual se trabajaran y no presentar ambigüedades en la definición y el resultado del
producto. La figura a continuación muestra los inconvenientes que se pueden presentar cunado
no se hace una identificación correcta de los requerimientos.

Verificación de Requisitos.

Para la verificación de requisitos se deben añadir criterios de aceptación por cada requisito, una
tarea de la calidad es asegurarse de que cada requisito cumple con los criterios asignados, este
criterio es una medida del requisito que lo hace entendible y con capacidad de ser probado.

Para la verificación de requisitos se debe validar lo siguiente:

Revisión de Requisitos Vs Especificación:

Una vez ya identificado los requerimientos, documentados y verificados se procede a realizar la
revisión de los mismos con base a la información recolectada con los usuarios del sistema, en esta
revisión participa los analistas del equipo de trabajo y los usuarios necesarios para esta revisión
de debe chequear que:

A continuación se presenta el proceso para la verificación de los requerimientos.

Preparar plan de revisión:

En la preparación del plan de reunión de debe planear quienes deben asistir que se va a hablar y
cuánto tiempo se va a gastar.

Documentos de requisitos a revisar:

Identificar cuáles son los documentos de especificación de requisitos que se va a revisar

Preparar reunión:

Se debe confirmar el lugar en el cual realizará la reunión y se deben prepara los materiales
necesarios para la reunión (lápices, hojas, elementos visuales… etc).

Realizar reunión:

Se revisa el entendimiento de la especificación por parte de los interesados y se valida que lo

especificado si cumple con la necesidad del cliente y con lo solicitado.

Identificar de defectos de la especificación:

Si revisa si se encuentran defectos con respecto a lo solicitado o si hace falta alguna especificación
requerida.

Realización de correcciones a los documentos:

Si en la etapa anterior se encuentran defectos en la especificación el analista del sistema debe

realizan las debidas correcciones al documento.

Informar modificaciones a los interesados:

Una vez los defectos en la especificación han sido subsanados, se debe enviar un breve resumen
informando las tareas realizadas para la corrección de los documentos especificados junto con los
documentos corregidos a los participantes en la reunión para dar su aprobación

Cierre de los requerimientos:

Por último se da por cerrado y entendido la el requerimiento se firma la aprobación por parte de
los interesados y se procede a enviarse un correo con la aprobación del requerimiento.
Capítulo 4 TÉCNICAS PARA DEFINIR REQUISITOS.

Para obtener los requisitos del cliente se pueden emplear varias técnicas. Históricamente, esto ha
incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos.
Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el
analista empleará una combinación de estos métodos para establecer los requisitos exactos de las
personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

De acuerdo a las necesidades de los clientes específicos a los cuales se va a aplicar la metodología
propuesta, se han definido las siguientes:

Definición de diagramas

Cuando se inicia con el desarrollo de un sistema por lo general nos encontramos con la dificultad
de no saber como dar inicio a la especificación y descripción de la funcionalidad en general que
buscamos apoyar con dicha herramienta, para ello hay muchas herramientas en el mercado que
buscan apoyar dicha tarea.

De manera general se recomienda el uso de los diagramas UML, pero cuándo utilizar diagramas
UML? y cuándo no hacerlo?.

Veamos de manera didáctica cuándo utilizar y no utilizar los diagramas UML

Cuando no Utilizar Diagramas

 No dibujar diagramas porque el proceso te lo dice

  Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo.
Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es
necesario.
 Dibujar diagramas para que otra persona codifique

Cuando Utilizar los Diagramas

 Utilizar los diagramas cuando varias personas necesiten entender la estructura de una
parte particular del diseño, porque todos ellos lo estarán trabajando simultáneamente.
Deténgase cuando todos ellos estén de acuerdo que lo han entendido
 Cuando dos o mas personas estén en desacuerdo con un elemento particular que debería
ser diseñado, y quieres un consenso del equipo. Detente cuando la decisión haya sido
tomada
 Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a
entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar
 Cuando necesites exponer una estructura de alguna parte del código a alguien más o a ti
mismo.

Los diagramas que se utilizan son los siguientes:

De estados:

Estos diagramas nos muestra los diferentes estados de un objeto durante su vida.

De secuencia:

Estos nos muestran el intercambio de mensajes (es decir la forma en que se invocan) en un
momento dado.Los diagramas de secuencia ponen especial énfasis en el orden y el momento en
que se envían los mensajes a los objetos.

De caso de uso:

Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos
de uso y los actores participantes en el proceso. Los diagramas de casos de uso describen qué es lo
que debe hacer el sistema, pero no cómo.

Definición de Casos de uso.

Para la correcta definición de los casos de uso a emplear en la especificación de los requisitos, se
deben tener en cuenta algunos aspectos como:

La identificación de actores:

Esto nos permite categorizar los diferentes grupos de actores, es decir identificar características
comunes de los actores que intervienen en el sistema, en esta identificación de actores debemos
tener en cuenta que dichos actores pueden llegar a ser un usuario, un humano u otro sistema o
dispositivo de hardware, también debemos hacernos las siguientes preguntas:

 Quién o qué inicia eventos con el sistema?

  Quién proveerá, usará o quitará información?
 Quién usará esta funcionalidad?
 Quién está interesado en cierto requerimiento?
 En que parte de la organización será usado el sistema?
 Quién dará soporte y mantendrá el sistema?
 Cuales son los recursos externos del sistema?
 Qué otros sistemas necesitarán interactuar con este sistema?

Al definir los actores que intervienen en un caso de uso se debe considerar que una persona
puede ejecutar distintos roles en el sistema. Hay actores principales, que son los que usan el
sistema directamente; para quienes desarrollamos el sistema. Y hay actores secundarios, que son
aquellos de los que el sistema necesita ayuda para poder cumplir con el objetivo del caso de uso

Intereses de los actores:

La identificación de estos intereses nos permite priorizar desarrollo de los casos de uso, planificar
mejor las interacciones y reconocer cuales son los usuarios con los que debemos levantar los casos
de uso.

La identificación de eventos y escenarios que este podría llegar a tener:

La identificación de eventos y escenarios es necesarios para poder determinar cual es la

interacción entre el sistema y los actores, que puede ser descrito mediante una secuencia de
mensajes, es una descripción narrativa de lo que la gente hace al intentar utilizar la aplicación.

Especificación de Casos de uso

Los casos de uso deben ser relatos secuenciales que especifiquen una funcionalidad determinada
del sistema que se desea desarrollar, así que debe describir como inicia y termina el caso de uso,
que datos se intercambian entre el actor y el caso de uso, el flujo de eventos, no solo la
funcionalidad, para reforzar esto debe comenzar cada acción con la frase “El actor...”, describir
solo los eventos que pertenecen a ese caso de uso, y no lo que pasa en otros casos de uso o fuera
del sistema.

De la misma manera se debe tener especial cuidado de no utilizar los siguientes detalles:

 No describir detalles de la interfaz del usuario, a menos que sea necesario para entender
el comportamiento del sistema.
 Evitar terminología vaga tal como “por ejemplo” “etc” “información”.
 Evite dejar en el texto del caso de uso ambigüedades o preguntas que se debieron resolver
en el levantamiento de información.

Los casos de uso deben contar con los siguientes elementos

 El conjunto de todos los casos de uso, debe cubrir los requerimientos del sistema en su
totalidad.
  Se pueden definir casos de uso en diferentes niveles.
1. A nivel de sistema de Negocio
2. A nivel de sistema de Software
 Las descripciones de los casos de uso son cruciales para la comprensión del sistema.
 Debe contar con Pre y Post Condiciones, una Pre-Condición es una restricción sobre
cuando un caso de uso puede empezar. que necesita para poder ser ejecutado, la Post-
Condición para un caso de uso debe ser verdadera, independientemente de cual flujo sea
ejecutado. Si algo puede fallar, debería cubrirse en la post condición diciendo: “La acción
se ha completado o si algo ha fallado, la acción no se ha realizado”, en lugar de decir “La
acción se ha completado”.

Prototipos.

Los prototipos son modelos a escala o facsímil de lo real, pero no tan funcional para que equivalga
a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema
final.

Es importante definir un objetivo para los prototipos, ya que puede ser útil en diferentes fases del
proyecto, por ello su objetivo debe ser claro. Es decir durante diferentes etapas del ciclo de vida se
pueden utilizar para diferentes necesidades, por ejemplo durante la fase de análisis se usa para
obtener los requerimientos del usuario, en la fase de diseño se usa para ayudar a evaluar muchos
aspectos de la implementación seleccionada y así de acuerdo a la necesidad de cada etapa.

Características de un prototipo

 El prototipo es una aplicación que puede no funcionar(conjunto de dibujos por ejemplo,

una presentación de escenarios) o que puede funcionar (conjunto de pantallas que
proporcionan un modelo dinámico).
 Los prototipos se crean con rapidez
 Los prototipos evolucionan a través de un proceso iterativo.
 Los prototipos tiene un costo bajo desarrollo.

Definición de criterios de aceptación.

Estos criterios nos permiten asegurar que los requisitos satisfacen la funcionalidad requerida y al
mismo tiempo que el producto es de calidad, nos ayuda a obtener un nivel de aceptación realista
tanto para el cliente como la empresa que los desarrolla.

Para la definición de criterios de aceptación se presenta el siguiente modelo:

 Se debe encontrar el documento de requisito terminado, revisado y aprobado por las

diferentes partes, implicadas.
 El requisito no debe tener escenarios ambiguos
 El requisito debe hacer que dice el documento de especificación ni mas, ni menos y
cumplir con todos los escenarios.
 El requisito debe ser medible, es fácil identificar si cumple o no cumple.
 No existe contraindicaciones con otros requisitos
  El requisito debe haber sido probado y aceptado por este proceso.
 Se debe entregar el requisito dentro de las fechas establecidas.
 El requisito aparte de cumplir con los anteriores pasos, puede haber otros criterios que el
cliente solicite.

Capítulo 5 PRUEBAS DE REQUERIMIENTOS.

El objetivo de las pruebas de verificación es buscar discrepancias entre los requerimientos y la

ejecución del software.

Partiendo de lo anterior se proponen las siguientes actividades para que las pruebas realizadas a
los productos desarrollados mediante esta metodología sean correcta, se tendrán en cuenta las
siguientes fases:

Planeación.

En esta fase se define el alcance y limitaciones de la prueba, la estrategia utilizada para la

ejecución de la prueba, los requerimientos para poder realizar las pruebas (documentación,
recurso humano y recurso tecnológico), los tiempos de estimados de duración de la misma y los
criterios para terminación.

Diseño de casos de prueba

En esta fase se define el checklist con las características a evaluar del requerimiento. A
continuación se presenta algunas de las características para evaluar dichos requerimientos.
Ejecución de casos de prueba.

En esta fase se evaluara cada uno de los requerimientos (casos de uso) de acuerdo al checklist
definidos como casos de prueba (conciso, contraposición, ambigüedad y completitud, entre otras)
se reportaran las consideraciones, errores, sugerencias, y se realizaran reuniones para hacer
aclaraciones y definir si las consideraciones planteadas van a ser solucionadas o si el
requerimiento es correcto como esta.

Cierre

En esta fase una vez se haya completados la ejecución con resultados satisfactorios y ajustes
correspondientes, se realizara el cierre de la prueba donde se dará el visto bueno sobre los
requisitos evaluados.

A continuación se presentan los entregables o documentos de soporte de la etapa de pruebas del

requerimientos de la metodología:
Capítulo 6 GESTIÓN DE CAMBIOS

La gestión de cambio en los proyectos debe ser una coordinación planificada de las actividades
que conlleve el logro de los objetivos o propósitos comunes a través de una comunicación clara y
eficiente.

A continuación se presenta el proceso de gestión de cambios con las actividades que se deben
llevar a cabo:
Identificación Control de cambios

Identificación Control de cambios

Para una correcta identificación de lo controles de cambios de los requerimientos de las

organizaciones de desarrollo de software, se identifican las siguientes actividades:
Análisis de la Solicitud:

La solicitud es recibida por parte del cliente interno o externo, esta debe ser recibida por parte del
líder de implementación para ser analizada. Uno de los puntos importantes para analizar son el
Alcance y el Tiempo, esto con el fin de identificar si la solicitud es viable realizarla sobre el mismo
requerimiento o si por el contrario es mejor manejarla como un requerimiento nuevo.

Con respecto al análisis con relación al alcance es recomendable buscar colaboración con las áreas
involucradas en la solicitud, para identificar de mejor manera el impacto y los elementos que se
ven afectados con la solicitud.

Valorar el cambio

Otro punto importante es valorar la factibilidad de la solicitud realizada ya sea por un cliente
interno o uno externo. Para ello se deberá ir recorriendo todo el árbol de requisitos viendo como
les afecta el cambio, y aquí es donde entra la trazabilidad de los requisitos.

Analizar Modificación

El líder de implementación debe realizar el análisis de la solicitud para saber que tanto impacta la
modificación e identificar puntualmente las modificaciones solicitadas que afectan el
requerimiento completo y así identificar si el cambio afecta mas de un requerimiento.

Documentar Cambio

Para tener un mejor control sobre los cambios solicitados es recomendable realizar una
documentación clara para evitar ambigüedades en las modificaciones que se van a realizar a los
requerimientos. Este punto apoya también a tener un control de las modificaciones que se
realizan sobre un documento de requerimiento esto con el fin de mantener informado al grupo de
trabajo y al cliente que actualizaciones se han realizado sobre los documentos, cual es la razón del
cambio y quien lo aprobó.

Aprobación Control de Cambios

Aprobar Cambios

Una vez se ha analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el
cambio, tras negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En
caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.
Planear Cambio

Después de tener una aprobación formal del cambio aceptado se planea el tiempo necesario y los
recursos necesarios para llevar a cabo el cambio aprobado.

Realizar Cambio

Una vez se planea el cambio aprobado se debe realizar las modificaciones necesarias a todos los
productos que resulten afectados por dicho cambio.

Revisar Cambio

Una vez se realice el cambio es recomendable hacer una verificación por parte del líder para
identificar que el requerimiento incluye todos los cambios solicitados y que fueron aprobados.

Actualizar Línea Base

Es recomendable utilizar el nuevo requerimiento como línea base, esto con el fin de trabajar
siempre sobre la última versión del requerimiento.

Informar

Una vez se realice la modificación de la solicitud se debe informar a los interesados que el cambio
ya esta realizado para que sea verificado por el cliente.

Entregable Control de Cambios.

Como se especifico en los puntos anteriores es importante utilizar el documento que apoye a la
identificación de la solicitud realizada por los clientes internos o externos. Esta documentación no
debe ser ambigua y debe ser validada por las dos partes, el cliente y las empresas de desarrollo de
software.

El formato necesario para la documentación del control de cambios se encuentra en el capitulo

ocho “Formatos de la Metodología”
Capítulo 7 GESTIÓN DE REQUERIMIENTO.

Para que la gestión de los requerimientos sea realmente aplicable al cliente en pro de la
satisfacción de las necesidades y control del proyecto en general, se debe cumplir con las
siguientes acciones:

Matrices de Trazabilidad

Matriz de relación de documentos

La siguiente Matriz nos muestra cuales son las relaciones de documentación de cada requisito su
clasificación si es de negocio, usuario o sistema y si es funciona o no funcional, su respectivo caso
de uso, sus casos de prueba asociados, la dependencia con otros requerimientos y las peticiones
de cambio en caso que las tenga.

Matriz de valoración y aprobación de los requisitos

La siguiente matriz de trazabilidad es la que nos permite valorar si el requisito cumple con todas
las etapas llevadas a cabo en la metodología, en caso que todos los criterios se cumplan se dará
por cerrado y aprobado el requisito.

Modo de desarrollo, la persona encargada de revisar la lista de chequeo deberá tener en cuenta
todo el proceso y documentación de la metodología para así dar un dictamen correcto, el manejo
es el siguiente.

Cumple=C, esto nos indica que el requisito cumple con el criterio correctamente, se encuentra en
color verde.
No Cumple= N, El color rojo es para dar una señal de alerta informando que el requisito no está
cumpliendo correctamente con el criterio de aceptación y que se debe revisar porque razón esto
pasando esto y tomar las medidas de control necesarias.

No aplica= En caso que el criterio no aplique en ese caso para el requisito se mostrar en amarillo
informando que no hay problema.

Matriz de Control de cambios

La matriz de control de cambios nos permite registrar los controles de cambios que se van
presentando, en esta matriz podremos registrar el número de control de cambio que se tiene
asignado, la referencia a la documentación de dicho control, quien aprobó el control, quien lo
llevo a cabo o quien lo está realizando, por quien fue revisado en caso que ya se encuentre
revisado, su porcentaje de ejecución hasta llegar al 100%, el o los requisitos afectados y una
descripción breve del control de cambios.

Esta matriz nos permitirá llevar un control detallado de los controles de cambios solicitados y su
estado actual.