Guía en profundidad · Tecnología
Un pliego de requisitos para el software de family office
Actualizado: · Leutrim Miftaraj, FLIORE · Principios editoriales · Otros idiomas: Deutsch · English · Français
Respuesta breve
Un pliego de requisitos describe qué debe hacer el software de un family office antes de comparar proveedores: objetivos, personas implicadas, contexto del sistema, requisitos funcionales, requisitos de calidad como seguridad y ubicación de los datos, y restricciones como protección de datos y conservación. Cada requisito recibe una prioridad y un criterio de aceptación verificable. Así las ofertas son comparables y la recepción inequívoca.
Por qué un pliego antes de elegir
Sin requisitos escritos, un family office compara presentaciones en lugar de soluciones: cada proveedor muestra sus puntos fuertes y al final decide la impresión general de la presentación. Un pliego de requisitos invierte el orden. Recoge lo que la propia organización necesita, lo pondera y hace verificable si una solución lo cumple. El método sigue la ingeniería de requisitos tal como la describen, por ejemplo, el International Requirements Engineering Board (IREB) y la norma ISO/IEC/IEEE 29148.
Estructura del pliego
- Objetivos: ¿qué resultados debe permitir el software, como una visión mensual consolidada o un expediente KYC verificable?
- Partes interesadas: dirección, contabilidad, cumplimiento, familia, asesores, auditores, con sus expectativas.
- Contexto del sistema: bancos, contabilidad, correo, firma, portales de las autoridades y sus interfaces.
- Requisitos funcionales: qué debe hacer el sistema.
- Requisitos de calidad: con qué nivel debe hacerlo, como seguridad, disponibilidad, facilidad de uso, exportabilidad.
- Restricciones: derecho, ubicación de los datos, conservación, presupuesto, calendario.
- Priorización y criterios de aceptación para cada requisito.
Ejemplos de requisitos
| ID | Requisito | Prioridad | Criterio de aceptación |
|---|---|---|---|
| F-01 | Representar estructuras con porcentajes de participación y vigencia en cualquier número de niveles | Must | Se registra una estructura de cuatro niveles; el patrimonio por persona coincide con el cálculo manual |
| F-02 | Determinar los beneficiarios efectivos por ordenamiento jurídico | Must | Para un caso de prueba, el sistema devuelve las personas esperadas para CH y DE |
| F-03 | Importar extractos bancarios en formato CAMT.053 y detectar duplicados | Must | Un extracto importado dos veces no genera asientos duplicados |
| F-04 | Avisar con 60 días de antelación de los documentos de identidad y poderes que caducan | Should | Un documento de prueba que caduca en 59 días aparece en el calendario |
| Q-01 | Los datos se guardan en Suiza | Must | Ubicación de los datos asegurada por contrato y lista de subencargados |
| Q-02 | Inicio de sesión con dos factores que puede imponerse a toda la organización | Must | Se rechaza un inicio de sesión sin segundo factor |
| Q-03 | Exportación completa de los datos en un formato abierto | Must | La exportación de todas las estructuras, personas, valores y documentos es posible sin el proveedor |
Redactar buenos requisitos
Un buen requisito es inequívoco, verificable y neutral respecto a la solución. «El sistema debe ser fácil de usar» no es un requisito verificable; «Tras una introducción de una hora, una empleada de contabilidad registra sin ayuda una nueva sociedad con tres socios» sí lo es. Los criterios de aceptación pueden seguir el esquema «Dado – Cuando – Entonces»: dado un mandato con un documento de identidad caducado, cuando se abre el calendario, entonces el documento aparece como vencido. Para los requisitos de calidad, la ISO/IEC 25010 ofrece una estructura, por ejemplo por seguridad, fiabilidad, facilidad de uso y portabilidad.
Priorizar
No todos los requisitos tienen la misma importancia. El método MoSCoW distingue Must, Should, Could y Won’t-have-this-time. Los requisitos Must son criterios eliminatorios: una solución que no cumple uno de ellos queda fuera. Los requisitos Should y Could entran en la comparación con ponderaciones. Quien formula demasiados requisitos Must no encuentra ninguna solución; quien formula muy pocos acaba comparando peras con manzanas.
Ejemplo práctico (simplificado)
Un multi family office recoge en dos talleres 140 deseos del equipo y de la familia. Tras depurarlos quedan 62 requisitos, 18 de ellos Must. Tres proveedores reciben el pliego y deben responder a cada requisito como cumplido, parcialmente cumplido o no cumplido, y ofrecer pruebas. Un proveedor queda fuera porque no asegura la ubicación de los datos en Suiza. Con los otros dos se comprueban los criterios de aceptación en una prueba con estructuras reales anonimizadas: la decisión se basa en los resultados, no en la presentación.
Del pliego a la decisión
El pliego muestra su valor en la comparación. Ha dado buen resultado un procedimiento en dos etapas: primero, los proveedores responden por escrito a cada requisito como cumplido, parcialmente cumplido o no cumplido y nombran una prueba: una función, una documentación, una referencia. Los requisitos Must no cumplidos llevan a la exclusión. Después, los proveedores restantes comprueban criterios de aceptación seleccionados en una prueba con los propios datos anonimizados del family office.
La valoración utiliza una matriz ponderada de funciones, calidad, costes a varios años y proveedor: estabilidad, soporte, desarrollo. Es importante fijar la ponderación antes de abrir las ofertas; de lo contrario se adapta inconscientemente al favorito. El resultado se documenta con su motivación; es a la vez la base del contrato y de la recepción posterior.
En FLIORE
FLIORE puede probarse frente a un pliego así en un mandato de prueba: estructuras de varios niveles, beneficiarios efectivos por ordenamiento jurídico, importación de extractos bancarios, plazos, derechos, ubicación de los datos en Suiza y exportación completa. El manual de cada módulo ayuda a asignar los requisitos a las funciones.
De un vistazo
| Método | Ingeniería de requisitos (IREB, ISO/IEC/IEEE 29148) |
|---|---|
| Modelo de calidad | ISO/IEC 25010 |
| Priorización | MoSCoW: Must, Should, Could, Won’t-have-this-time |
Términos de esta página
- Beneficiario efectivo
- La persona física que en última instancia posee o controla una sociedad, una fundación o un trust, o por cuya cuenta se realiza una transacción.
- Multi family office
- Un proveedor de servicios que atiende el patrimonio y los asuntos de varias familias no vinculadas entre sí.
Preguntas frecuentes
¿Cuántos requisitos necesita un pliego?
Los necesarios para cubrir los objetivos. Para un family office, entre 40 y 80 requisitos bien formulados suelen ser más significativos que varios cientos de requisitos vagos.
¿Quién redacta el pliego?
Los responsables del negocio, con el apoyo de una persona con experiencia en ingeniería de requisitos. Lo importante es que los usuarios formulen y acepten ellos mismos sus requisitos.
¿Deberían ayudar los proveedores a redactar el pliego?
Mejor no antes de la licitación, porque el pliego quedaría hecho a medida de un proveedor. Las preguntas de los proveedores durante la licitación, en cambio, son útiles.
¿Qué es un criterio de aceptación?
Una condición verificable que decide si un requisito se cumple, idealmente con un caso de prueba concreto.
¿Cómo se usa el pliego durante la implantación?
Como base para la configuración, los casos de prueba y la recepción. Así se mantiene trazable si se entregaron los servicios acordados.
¿Qué forma parte de las restricciones?
Los requisitos legales como la protección de datos y la conservación, la ubicación de los datos, el presupuesto, el calendario y los sistemas existentes con los que debe funcionar el software.
¿Cómo se comparan los costes?
Por el coste total a varios años: licencias, implantación, migración de datos, tiempo interno, formación y operación. Una entrada barata puede salir más cara en cinco años que una licencia más alta con menos esfuerzo.
¿Cómo se tratan los requisitos Should no cumplidos?
Entran en la valoración con ponderaciones y pueden ser objeto de negociación, como una entrega en una versión posterior. Las ampliaciones aseguradas por contrato deberían registrarse con fecha.
Fuentes
- IREB – International Requirements Engineering Board (CPRE)
- ISO – ISO/IEC/IEEE 29148, ingeniería de requisitos
- ISO – ISO/IEC 25010, modelo de calidad del software
- HERMES – método de gestión de proyectos de la administración federal suiza
- Ley federal suiza de protección de datos (LPD, RS 235.1) – Fedlex
Esta página sirve de orientación y no sustituye el asesoramiento jurídico o fiscal. Las fuentes legales citadas prevalecen en su versión aplicable.
Más información
Más sobre Creación, gobernanza y selección
FLIORE en su family office
Vea estructuras, cumplimiento y patrimonio consolidado con sus propias preguntas, en una demostración personal.