Publicado por Adam Alami, PhD Fellow, IT University of Copenhagen (traducido del inglés)
INTRODUCCION
Los requisitos no funcionales están ampliamente representados en la literatura. No faltan definiciones y ejemplos de requisitos no funcionales. El Instituto Internacional de Análisis de Negocios (IIBA) define los requisitos no funcionales de la siguiente manera:
Los requisitos no funcionales capturan condiciones que no están directamente relacionadas con el comportamiento o la funcionalidad de la solución, sino que describen las condiciones ambientales bajo las cuales la solución debe permanecer efectiva, o las cualidades que debe poseer el sistema. También se conocen como atributos (indicadores) de calidad o requisitos adicionales. Estos pueden incluir requisitos relacionados con el ancho de banda, la velocidad, la seguridad, la disponibilidad, la arquitectura de la información y la presentación de la interfaz de usuario.
Las palabras clave en esta definición "no están directamente relacionadas con el comportamiento o la funcionalidad de la solución". Estas son "condiciones" o "cualidades".
Condiciones : son restricciones externas o internas. Las restricciones internas son las políticas y la autorregulación de la organización, mientras que las restricciones externas son las reglas gubernamentales, los estándares de la industria y otros parámetros que determinan el entorno empresarial.
Cualidades : estos son requisitos comerciales que definen un comportamiento no sistémico y no están relacionados con el proceso, pero son requisitos para la calidad de la solución.
Ejemplos:
i) Condiciones
a. Marca
b. Privacidad de los datos
s Compatibilidad PCI;
ii) Cualidades
a. Disponibilidad
b. Rendimiento
Incluso el analista de negocios más experimentado hace muchos esfuerzos para identificar los requisitos no funcionales. La razón principal de tales dificultades es que los requisitos no funcionales no son fáciles de identificar y no existe un proceso predeterminado para su identificación. Para definir estos requisitos, debe ser creativo y pensar ampliamente, ¡ir más allá de ciertos límites!
POR QUÉ SE REQUIEREN REQUISITOS NO FUNCIONALES
De acuerdo con todos los tipos de requisitos, la omisión de uno u otro requisito puede poner en peligro la integridad y la integridad de la decisión. Los requisitos funcionales y no funcionales están estrechamente interconectados por múltiples relaciones.
Por lo general, la atención se centra en el aspecto funcional de los requisitos, y la importancia de los requisitos no funcionales a menudo se subestima.
¿Por qué se subestiman los requisitos no funcionales?
1. La atención se centra en los requisitos funcionales, ya que proporcionan rendimientos tangibles. Los requisitos no funcionales contribuyen a la infraestructura y no al comportamiento del sistema. La infraestructura empresarial, que es intangible, parece insignificante.
2. El equipo de entrega de decisiones es recompensado y medido en términos de funciones, procesos y comportamiento del sistema. Los usuarios comerciales ven los requisitos no funcionales como "requisitos de TI", y TI considera cualquier "necesidad" como necesidades comerciales, no tecnología. La tecnología proporciona servicio y el negocio gestiona las necesidades. Durante este proceso, TI a veces olvida que solo tienen un papel "consultivo".
Cada solución logra la eficiencia de una lista exhaustiva de requisitos, recopilados tanto al comienzo como durante el proceso de implementación. Los requisitos se pueden dividir en dos grandes categorías: sustantivos y fundamentales. Los requisitos esenciales se derivan de su analogía con los "requisitos funcionales" y parecen estar directamente relacionados con la solución. Sin embargo, los llamados requisitos fundamentales pueden no estar directamente relacionados con la solución, pero son fundamentales para crear un entorno sostenible en el que se mantengan los requisitos funcionales esenciales. Por lo tanto, estos "requisitos no funcionales" constituyen la estructura y la infraestructura que soportan las soluciones del sistema.
¿Qué es la escalabilidad?
La escalabilidad es la capacidad de un sistema o proceso para manejar un mayor volumen de operaciones sin restricciones o cuellos de botella estructurales. Cada modelo de negocio es de suma importancia para generar un negocio, lo que conduce a un aumento en el volumen de transacciones y un aumento posterior en las actividades operativas. Las operaciones de escalado para manejar la actividad comercial en expansión son inherentes e integradas en el diseño del sistema. La escalabilidad se puede dividir en dos categorías: física e intangible.
1. escalabilidad física
Se refiere a aquellos parámetros que son críticos para asegurar que una organización esté equipada con herramientas (posiblemente opcionales) para manejar un número creciente de operaciones. Esto implica estabilidad física. Esto indica la presencia de factores necesarios desde el punto de vista de los componentes físicos del proceso para garantizar la estabilidad (es decir, almacenamiento de datos, ancho de banda de red, hardware, etc.).
¿Qué significa ser sostenible? Cumple con los requisitos actuales sin comprometer la capacidad de satisfacer las necesidades futuras. Por ejemplo, si las características de una solución de red respaldan las necesidades actuales, también deberían poder satisfacer las necesidades futuras en los próximos tres a cinco años. En general, la sostenibilidad se determina y evalúa utilizando pronósticos de tres a cinco años.
¿Por qué es necesario determinar la necesidad de sostenibilidad al desarrollar un modelo / solución de negocios? Un modelo de negocio sostenible se basa en su diseño y estructura, que son los más adecuados para lograr una solución a través de sistemas, procesos e infraestructura estables y confiables. La estabilidad física tiene como objetivo lograr dos características principales: estabilidad y confiabilidad de las soluciones empresariales y tecnológicas.
Estabilidad : eso permite que el negocio permanezca estable, resistente a las influencias externas. La infraestructura de TI es resistente y garantiza el soporte para las operaciones comerciales durante el período previsto en el futuro.
Fiabilidad : si el negocio está en constante crecimiento durante cinco años, mientras la infraestructura se mantiene estable. La fiabilidad permite a las empresas centrarse en sus competencias básicas en una infraestructura sostenible.
2. Escalabilidad intangible
Esto se refiere a la capacidad inherente de apoyar el crecimiento no físico. El crecimiento empresarial es fundamental para mantener la cuota de mercado y la competitividad. El crecimiento puede ser tanto interno como externo, en función de los impulsores y estrategias aceptados. A continuación hay algunos ejemplos:
* Nuevos productos que se alojarán en la misma plataforma / solución
* Marcas adicionales (para organizaciones multimarca)
* Procesos comerciales adicionales
¿Cuál es la diferencia entre físico e intangible? Aunque ambos pueden parecer similares, no son idénticos. La solución puede ser físicamente sostenible, pero puede no ser compatible con el crecimiento intangible. Por ejemplo, si el volumen de operaciones aumenta, entonces la solución debe ser físicamente estable. Si una empresa presenta nuevos productos, se clasifica como crecimiento intangible, y la solución debe tener funciones y procesos escalables (no físicos) para respaldar este crecimiento.
¿Por qué necesitamos definir requisitos de escalabilidad intangible? La necesidad de definir requisitos para la escalabilidad intangible se está volviendo necesaria porque es un requisito previo que apoya el crecimiento. Los requisitos de escalabilidad, de hecho, son un reflejo del deseo de crecimiento de la organización y la necesidad de una solución para apoyar el crecimiento con cambios mínimos y la interrupción de las actividades diarias.
¿CÓMO DETERMINAR LOS REQUISITOS DE ESCALABILIDAD?
No existe una explicación simple o una metodología simple para determinar los requisitos de escalabilidad. Es extremadamente subjetivo y relativamente difícil determinar las condiciones y características necesarias para tomar una decisión sostenible. Esta es una de las razones por las cuales esto se llama "análisis". A continuación se muestra un enfoque que siempre ha funcionado para el autor. Sin embargo, esto no es adecuado para todas esas situaciones.
Escalabilidad física:1. Identifique los componentes físicos de la solución que desea escalar.
2. Definir funciones que pueden hacer que un componente particular sea escalable.
3. Definir parámetros para las funciones de medición.
4. Defina los valores de cada parámetro definido anteriormente. Estos son requisitos no funcionales (definición de parámetros).
Las respuestas a estas preguntas deben formularse desde el punto de vista del negocio, y no desde el punto de vista de TI.
Un ejemplo:Situación: su organización es una institución financiera que emite tarjetas de crédito a los clientes. Ella está haciendo esfuerzos para transformar su tecnología y sistemas.
¿Qué preguntas deben hacerse para comenzar a analizar la identificación de la escalabilidad física? Para simplificar, reducimos el alcance. Los siguientes son algunos ejemplos:
1. ¿Cuál es el volumen actual de clientes, transacciones, cuentas, etc.?
2. ¿Qué volúmenes se esperan de los sistemas el primer día?
3. ¿Cuál es el crecimiento anual en volumen (clientes, transacciones, etc.) esperado en los próximos tres a cinco años?Se debe hacer la pregunta 1 para determinar el estado actual.
La pregunta 2 determina el requerimiento inmediato desde el primer día de vida (operación).
La pregunta 3 es una contribución para determinar el requisito de escalabilidad de una solución. Por ejemplo, si una organización predice un aumento del 10% en nuevos clientes por año y un crecimiento anual del 15% en las transacciones, entonces los requisitos de escalabilidad pueden ser los siguientes:
1. La solución debe respaldar el crecimiento anual del 10% de los nuevos clientes.
2. La solución debe respaldar un crecimiento anual del 15% del número anterior de transacciones.
Sin embargo, en este ejemplo, sugeriría definir mejor las expectativas de que el requisito implica "apoyo" (es decir, la tecnología no requiere ningún cambio para manejar el crecimiento).
Escalabilidad intangible:Este es el crecimiento del negocio, no el desarrollo de tecnología, infraestructura o logística. Esto variará de un negocio a otro y depende de los detalles del área temática. Por lo tanto, el conocimiento de los negocios y la industria, desarrollado a través de la investigación experta, es la clave para determinar los parámetros de escalabilidad a nivel de detalle. Sin embargo, una estrategia comercial de alto nivel se formula sobre la base de los detalles de la definición de la visión de la organización.
Un ejemplo:Situación: su organización es una institución financiera que emite tarjetas de crédito a sus clientes. Ella está haciendo esfuerzos para transformar su tecnología y sistemas.
¿Qué preguntas deben hacerse para comenzar el análisis de la identificación de escalabilidad intangible? Para simplificar, reducimos el alcance. Los siguientes son algunos ejemplos:
1. ¿La organización planea lanzar nuevos productos (por ejemplo, pagos móviles, productos como Apple Pay o Bitcoin)?
2. ¿Hay adquisiciones o fusiones futuras con entidades similares?
3. ¿Cuál es la estrategia de la organización (es decir, nuevos canales de distribución, acceso a nuevos mercados, etc.)?
Estas preguntas ayudan a determinar el crecimiento intangible. Por ejemplo, si una organización planea lanzar una nueva marca de productos de tarjetas de crédito, los requisitos de escalabilidad son los siguientes:
1. La solución debería poder colocar dos marcas diferentes: Marca A y Marca B.
2. Ambas marcas deberían poder utilizar los mismos sistemas y procesos.Estos requisitos son de alto nivel y se dan solo a modo de ejemplo. En un escenario real, deben estudiarse con más detalle.
No existe un método simple para determinar los requisitos no funcionales. Es relativamente difícil determinar las condiciones y funciones necesarias para crear una solución escalable.
__________________________________________________________
Publicado por Adam Alami, Ph.D., Copenhagen IT University
Adam Alami es doctor en informática en la Universidad de Copenhague. Adam tiene una rica experiencia en tecnología de la información. Comenzó su carrera como desarrollador de software, luego pasó a análisis de negocios y gestión de proyectos. Sus 20 años de experiencia están asociados con importantes proyectos de transformación empresarial y mejora de procesos. Ha acumulado buenas prácticas en grandes proyectos en el campo de la transformación empresarial, integración, migración y modernización de sistemas.
Tiene varios logros académicos. Tiene una licenciatura en ingeniería de software de la Universidad de Quebec en Montreal (UQÀM) y una maestría en ingeniería informática de la Universidad de Tecnología de Sydney (UTS).
Correo electrónico: adamalami2016@gmail.com
Publicado en
Modernanalyst.com