Por qué los Requisitos Empresariales y Funcionales son Vitales para el Éxito de un Proyecto

37% en septiembre de 1999, la NASA perdió su Orbitador Climático de Marte de 125 millones de dólares cuando trató de entrar en la órbita, a solo 100 kilómetros demasiado cerca de Marte. La misión falló debido a la mala gestión de los requisitos: no se discutió anteriormente en la etapa si el «software de navegación» requería unidades métricas o unidades imperiales.

El Resultado: especificaciones incompatibles; el sistema de control de actitud se especificó utilizando unidades imperiales, pero su software de navegación utilizó unidades métricas.

Por lo tanto, obtener los requisitos correctos y utilizarlos al máximo es crítico para el éxito de un proyecto.

En el campo del desarrollo de productos de software, la importancia y la relevancia de la palabra «Requisitos» está aumentando con la creciente popularidad de las metodologías ágiles de desarrollo de software. Incluso uno de los puntos mencionados en el Manifiesto Ágil explica la metodología como una que valora:

«Software de trabajo sobre documentación completa»

Conseguir los requisitos correctos es fundamental, ya sea que trabaje en metodología Ágil o en cascada.

Requisitos Empresariales frente a Requisitos funcionales: Definición y sus tipos

Antes de profundizar en los Requisitos Empresariales frente a Requisitos Funcionales, veamos la definición y los tipos.

Según el Instituto Internacional de Análisis de Negocios, un requisito es:

• Condición o capacidad que necesita una parte interesada para resolver un problema o lograr un objetivo.
• Una condición o capacidad que debe cumplir o poseer un sistema o componente del sistema para satisfacer un contrato, norma, especificación u otros documentos formalmente impuestos.
• Una representación documentada de una condición o capacidad como en (1) o (2)

Basado en el dominio del problema y la metodología con la que trabaja un Analista de Negocios (BA), los siguientes son los diversos requisitos, de los cuales los más importantes son: requisitos de negocio y requisitos funcionales.

En este blog, exploraremos la diferencia entre los requisitos empresariales y los requisitos funcionales. Es imperativo comprender la diferencia para que ofrezcamos al negocio una solución ideal que realmente se encargue del problema.

Cuáles son los requisitos comerciales

¿Por qué un cliente necesita una aplicación?

Esta información puede parecer innecesaria para muchos porque el cliente está listo para pagarle por crear una aplicación. Entonces, ¿por qué debería importarte entender las razones?

Bueno, si te apasiona crear productos de calidad y ofrecer experiencias perfectas a tus clientes, entonces deberías preocuparte por los «porqués» tanto como por los » qué «y los «cómo».»

Y cuando empiezas a centrarte en la parte del «por qué» de un proyecto, significa que estás cuidando los requisitos del negocio.

Requisitos de negocio para el ciclo de vida de desarrollo de software se ocupa de los requisitos de alto nivel o los deseos de una organización, lo que permite que la empresa alcance sus objetivos finales, visión y metas.

Por lo general describen lo que debe hacer un sistema o una solución. Dan el alcance de una necesidad de negocio o un problema que debe ser abordado por un proyecto o tarea en particular.

Ejemplo de requisitos comerciales

ParcelKiosk es uno de nuestros clientes que se acercó a nosotros para obtener una aplicación web diseñada y desarrollada para ofrecer mejores servicios de entrega de paquetes a los clientes. A medida que se acercaban a nosotros, comenzamos la discusión con un parámetro importante: analizar las necesidades del negocio.

¿Cuál cree que podría ser el requisito comercial para este servicio de aplicación web de entrega de paquetes?

Es posible que se te ocurra un parámetro importante como la seguridad. Sin embargo, a pesar de que la seguridad es un factor vital, no es un requisito comercial. No creas un servicio como ParcelKiosk sin tener en cuenta la seguridad, pero crear un servicio solo por el bien de proporcionar seguridad no es el objetivo final.

¿Qué pasa con la conexión de una amplia gama de servicios de mensajería y clientes?

Esto tiene más sentido como requisito de negocio en comparación con la seguridad porque describe lo que hará el servicio. Sin embargo, ¿es esa la razón para crear el servicio web, o es realmente una función del servicio?

Estas son algunas de las posibles razones (requisitos comerciales) para construir ParcelKiosk:

• Ofrezca una solución más inteligente para medir, seleccionar y enviar paquetes
• Proporcione capacidades para rastrear y administrar sus servicios de entrega y recogida
• Entrega a tiempo y comentarios de los clientes

¿Ve la diferencia entre conectar una gama de servicios de mensajería y clientes o seguridad y los requisitos reales del negocio?

Los siguientes puntos se pueden observar aquí w. r. t requisitos comerciales:

• Los requisitos del negocio siempre se escriben desde el punto de vista del cliente.
• Son requisitos de sistema amplios de alto nivel pero orientados a los detalles.
• No son objetivos organizacionales, sino que ayudan a una organización a lograr sus objetivos. Al cumplir con estos requisitos de negocio, la organización alcanza sus objetivos generales.

Ahora está bastante claro que los requisitos de negocio explican la parte de «por qué» de un proyecto: «por qué» se necesita construir un proyecto en particular, p. ej. qué beneficios pretende lograr la organización a través del cumplimiento de un proyecto específico.

Documento de Requisitos Comerciales (BRD)

Un Documento de requisitos comerciales describe las necesidades comerciales de alto nivel. El público objetivo principal de un BRD es el cliente y los usuarios. Los requisitos de negocio están documentados en el BRD. Un documento de requisitos comerciales bien escrito ayuda a lograr el objetivo deseado de construir un producto exitoso dentro del límite de tiempo estipulado.

tiene los siguientes elementos:

• La visión del proyecto
• Objetivos del proyecto
• Contexto o los antecedentes del proyecto
• Alcance del proyecto
• identificación de las partes Interesadas
• detalle de Requisitos de Negocio
• Alcance de la solución
• las restricciones del Proyecto: Marco de tiempo, Costo del Proyecto y recursos disponibles

Documento de requisitos comerciales Ejemplo: Por qué se etiquetó a Chrysler PT Cruiser como ‘Héroe a cero’

Chrysler Group no se centró mucho en BRD y siguió adelante con la producción de su PT Cruiser, lo que resultó en muchos dolores de cabeza para la organización. Echemos un vistazo a cómo falló su documento de requisitos de negocio:

• Identificación de partes interesadas: El Grupo Chrysler identificó bastante bien a la mayoría de las partes interesadas. Estaban a bordo con los vendedores y el equipo de producción del crucero PT. Sin embargo, las dos partes interesadas importantes que se perdieron fueron el cliente final que compró el vehículo y los concesionarios que vendieron el Crucero.
• Restricciones del proyecto: Chrysler realizó un buen trabajo cuando se trataba de partes interesadas de alto nivel que suministraban y supervisaban la construcción. Sin embargo, lo que se perdieron fue cuestionar el calendario de producción, responder a las consultas de los clientes o de los distribuidores, como el precio, la disponibilidad del modelo y la demanda.

Supongamos que el BRD de Chrysler incluía los requisitos de todas las partes interesadas, que esos retrasos imprevistos en la entrega del producto (objetivo de entregar los automóviles al concesionario para 2001) podrían haberse influido mucho antes de la producción, y que las necesidades de los usuarios finales se habrían justificado.

Consejos para escribir una Plantilla de Documento de Requisitos Comerciales (BRD)

Ahora que tiene un conocimiento básico de lo que debe lograr un BRD, puede seguir los consejos mencionados a continuación para asegurarse de escribir un documento de requisitos comerciales sobresaliente.

• Practique la obtención de requisitos fuertes
• Use un lenguaje sencillo sin voz pasiva y jerga
• Investigue proyectos anteriores
• Valide la documentación
• Integre elementos visuales

Cuáles son los requisitos funcionales

Requisitos funcionales, como su nombre indica, describa las funcionalidades del software o un producto. Estas son las funciones que el sistema debe realizar para cumplir con los requisitos del negocio.

Incluyen detalles técnicos, cálculos, manipulación y procesamiento de datos y otras funcionalidades particulares que caracterizan lo que debe lograr un marco.

Si no tiene requisitos funcionales claros para comprender el aspecto técnico del proyecto, durante el proyecto no podrá responder si las decisiones tomadas por los equipos de desarrollo/diseño/prueba son correctas.

«no escribir una especificación es el mayor riesgo innecesario tomar en un proyecto de software.»~Joel Spolsky

Si un detalle funcional no está alineado con los objetivos de negocio, podría resultar en el fracaso del proyecto.

Requisitos funcionales Ejemplo

Uno de los grandes fabricantes de bienes de consumo se acercó a Net Solutions para un proyecto de desarrollo de aplicaciones móviles que podría mejorar la eficiencia en su cadena de suministro.

Este gigante de los bienes de consumo comenzó un proyecto en 2001, cuyo objetivo era empoderar a las mujeres rurales generando oportunidades para que vendieran productos y ganaran la vida.

El cliente quería que nuestro equipo de proyecto volviera a hacer su aplicación móvil existente de una manera que automatizara su cadena de suministro y el proceso de pedidos al reunir a las mujeres rurales y los distribuidores en una única plataforma digital.

Su objetivo era mejorar la tasa de adopción, habilitando digitalmente a los empresarios y resolviendo la fricción en el recorrido del cliente existente (todos estos son requisitos comerciales).

Cuando se trata de requisitos funcionales, comenzamos a discutir las características de la aplicación requeridas con el cliente, que eran:

• Integración con proveedores de terceros
• Actualizaciones de existencias en tiempo real
• Colocación de pedidos

El cliente asumió que estas características serían suficientes para resolver la fricción en el recorrido actual del cliente, mejorando así la tasa de adopción.

Sin embargo, al discutir los requisitos funcionales con nuestro cliente, nos dimos cuenta de que a menos que identifiquemos la fricción en el recorrido de un cliente existente y medamos los niveles de alfabetización digital para los nuevos usuarios de la aplicación, desarrollar una aplicación no tendría sentido.

La solución que Net Solutions Entregó

Aplicamos el enfoque de Design Thinking y llevamos a cabo una investigación etnográfica para evaluar la preparación digital de los empresarios y comprender las brechas en el recorrido de los usuarios de la aplicación existente.

Pasamos un día con todas las partes interesadas para identificar mejor sus problemas.

Utilizando el enfoque de pensamiento de diseño, pudimos averiguar qué características deberían ir en la nueva aplicación. Además, este enfoque hizo que nuestro cliente comprendiera que la mejor manera de seguir adelante con la gestión del proyecto es llevarla a cabo de manera gradual.

El resultado:

La investigación etnográfica y el mapeo de viajes dentro de nuestra metodología de pensamiento de diseño nos ayudaron a construir una nueva aplicación con características diseñadas y validadas por las partes interesadas que, en última instancia, la usarán, lo que la convierte en uno de los ejemplos notables de requisitos funcionales.

Los siguientes puntos se pueden observar aquí con los requisitos funcionales de r.t.:

• Los requisitos funcionales siempre se escriben desde el punto de vista del sistema y de las partes interesadas.
• La especificación de requisitos funcionales es mucho más detallada.
• Es a través del cumplimiento de los requisitos funcionales que se desarrolla una solución efectiva, satisfaciendo las necesidades y objetivos de negocio del cliente.

Por lo tanto, los requisitos funcionales explican la parte de «cómo» de un proyecto, es decir, los requisitos de software y cómo la solución podrá satisfacer las necesidades de la organización.

Documento de Requisitos funcionales

El Documento de Requisitos funcionales describe las funciones necesarias para satisfacer las necesidades empresariales. Estas funciones están documentadas en el Documento de Requisitos Funcionales (FRD) o en el documento de Especificaciones de Requisitos Funcionales (FRS).

Un FRD bien escrito representa cada flujo de proceso para cada actividad, entrelazando las dependencias.

FRD contiene los siguientes elementos:

• Propósito del proyecto
• El alcance del proyecto
• Requisitos funcionales detallados
• Suposiciones/restricciones
• Representación de los requisitos funcionales mediante Arquitectura de la información

Consejos para escribir una Plantilla de Documento de Requisitos funcionales (FRD)

Creación de un documento las funcionalidades técnicas que se requieren para la entrega exitosa de un software/producto es como escribir un mensaje a todos los miembros del equipo involucrados sobre las tareas técnicas que desea que realicen.

Los siguientes consejos le ayudarán a escribir un Documento de Requisitos Funcionales efectivo:

• Verifique dos veces sus hechos
• Use un lenguaje simple
• Agregue ilustraciones o diagramas
• Observe los marcos de tiempo

Requisitos comerciales vs Requisitos funcionales: Desafíos clave para escribir un documento

Escribir requisitos comerciales y funcionales «buenos» o «válidos» es un gran desafío. Los desafíos más comunes que se encuentran al crear estos documentos de requisitos incluyen:

• Una comprensión incompleta del requisito, sin pedir aclaraciones.
• Interpretación incorrecta del requisito; aplicar filtros personales a la información que altera la intención.
• Escribir sobre implementación (el cómo) en lugar de requisitos (el qué).
• Las decisiones de aplicación deben aplazarse hasta el momento más tardío posible en el Proceso de obtención de Requisitos.
• Usando una estructura de oración incorrecta.
• Importancia de evaluar la calidad de los requisitos en el desarrollo de productos de software.

¿Qué son los requisitos no funcionales?

Los requisitos no funcionales definen y especifican el funcionamiento del sistema. Sin embargo, no afecta a la funcionalidad del sistema como su nombre indica. Por lo tanto, el sistema puede continuar funcionando incluso si no se cumplen sus requisitos no funcionales. La razón por la que los requisitos no funcionales son esenciales es por su facilidad de uso y porque ayudan a determinar los factores que afectan la experiencia del usuario.

Lo que diferencia los requisitos funcionales y no funcionales es que, mientras que el primero decide las características del producto y los requisitos del usuario, el segundo se centra en las propiedades del producto y las expectativas del usuario.

Requisitos de negocio vs Requisitos funcionales-Conclusión

De la comparación anterior, está claro que los requisitos son la columna vertebral de cada negocio. Tanto los requisitos de negocio como los funcionales forman la base de un análisis de negocio eficaz. Los requisitos comerciales explican el » por qué «y el» qué «de un proyecto, y los requisitos funcionales explican el» cómo » del proyecto.

Una revisión periódica y una evaluación comparativa de los requisitos funcionales (desarrollados) con los requisitos comerciales garantizan el éxito general de un proyecto. Esta es una declaración final que le ayudará en gran medida a distinguir claramente los requisitos de negocio de los requisitos funcionales: el punto de partida de cualquier análisis de negocio es comprender los requisitos de negocio (qué y por qué) del cliente y transformarlos en requisitos funcionales (cómo).