In-depth guide · Technology
A requirements catalogue for family office software
Updated: · Leutrim Miftaraj, FLIORE · Editorial standards · Other languages: Deutsch · Français · Español
Short answer
A requirements catalogue describes what family office software must do before providers are compared: goals, the people involved, the system context, functional requirements, quality requirements such as security and data location, and constraints such as data protection and retention. Every requirement receives a priority and a testable acceptance criterion. This makes offers comparable and the later acceptance unambiguous.
Why a catalogue before the selection
Without written requirements, a family office compares presentations rather than solutions: each provider shows its strengths, and in the end the overall impression of the presentation decides. A requirements catalogue reverses this. It records what the organisation itself needs, weights it and makes it testable whether a solution meets it. The method follows requirements engineering as described, for example, by the International Requirements Engineering Board (IREB) and the standard ISO/IEC/IEEE 29148.
Structure of the catalogue
- Goals: which results should the software enable, such as a consolidated monthly overview or an audit-proof KYC file?
- Stakeholders: management, accounting, compliance, family, advisers, auditors – with their expectations.
- System context: banks, accounting, email, signature, authority portals and their interfaces.
- Functional requirements: what the system must do.
- Quality requirements: how well it must do it, such as security, availability, usability, exportability.
- Constraints: law, data location, retention, budget, schedule.
- Prioritisation and acceptance criteria for every requirement.
Example requirements
| ID | Requirement | Priority | Acceptance criterion |
|---|---|---|---|
| F-01 | Map structures with ownership percentages and validity across any number of levels | Must | A four-level structure is captured; the wealth per person matches the manual calculation |
| F-02 | Determine beneficial owners per legal system | Must | For a test case, the system returns the expected persons for CH and DE |
| F-03 | Import bank statements in CAMT.053 format and detect duplicates | Must | A statement imported twice does not create duplicate entries |
| F-04 | Report expiring identity documents and powers of attorney 60 days in advance | Should | A test document expiring in 59 days appears in the calendar |
| Q-01 | Data is stored in Switzerland | Must | Contractually assured data location and list of sub-processors |
| Q-02 | Two-factor sign-in enforceable across the organisation | Must | Sign-in without a second factor is rejected |
| Q-03 | Complete data export in an open format | Must | Export of all structures, persons, values and documents is possible without the provider |
Writing good requirements
A good requirement is unambiguous, testable and solution-neutral. "The system should be user-friendly" is not a testable requirement; "After a one-hour introduction, an accounting employee captures a new company with three shareholders without help" is. Acceptance criteria can be phrased in the pattern "Given – When – Then": given a mandate with an expired identity document, when the calendar is opened, then the document appears as overdue. For quality requirements, ISO/IEC 25010 provides a structure, for example by security, reliability, usability and portability.
Prioritising
Not every requirement is equally important. The MoSCoW method distinguishes Must, Should, Could and Won't-have-this-time. Must requirements are knock-out criteria: a solution that fails one of them is eliminated. Should and Could requirements feed into the comparison with weights. Those who formulate too many Must requirements find no solution; those who formulate too few end up comparing apples with oranges.
Worked example (simplified)
A multi family office collects 140 wishes from the team and the family in two workshops. After clean-up, 62 requirements remain, 18 of them Must. Three providers receive the catalogue and are asked to answer every requirement as met, partly met or not met and to offer evidence. One provider is eliminated because it does not assure a data location in Switzerland. With the other two, the acceptance criteria are checked in a test run with real, anonymised structures – the decision is based on the results, not on the presentation.
From catalogue to decision
The catalogue shows its value only in the comparison. A two-stage approach has proved its worth: first, the providers answer every requirement in writing as met, partly met or not met and name evidence – a function, documentation, a reference. Unmet Must requirements lead to exclusion. Then the remaining providers check selected acceptance criteria in a test run with the family office's own anonymised data.
The assessment uses a weighted matrix of functions, quality, costs over several years and the provider – stability, support, further development. It is important to set the weighting before the offers are opened, otherwise it is unconsciously adapted to the favourite. The result is documented with reasons; it is at the same time the basis for the contract and the later acceptance.
In FLIORE
FLIORE can be tested against such a catalogue in a test mandate: structures across several levels, beneficial owners per legal system, import of bank statements, deadlines, rights, data location in Switzerland and complete export. The manual for each module helps to map requirements to functions.
At a glance
| Method | Requirements engineering (IREB, ISO/IEC/IEEE 29148) |
|---|---|
| Quality model | ISO/IEC 25010 |
| Prioritisation | MoSCoW: Must, Should, Could, Won't-have-this-time |
Terms on this page
- Beneficial owner
- The natural person who ultimately owns or controls a company, foundation or trust, or on whose behalf a transaction is carried out.
- Multi family office
- A service provider that looks after the wealth and affairs of several unrelated families.
Frequently asked questions
How many requirements does a catalogue need?
As many as necessary to cover the goals. For a family office, 40 to 80 clearly formulated requirements are usually more meaningful than several hundred vague ones.
Who writes the catalogue?
The business owners, supported by someone experienced in requirements engineering. What matters is that the users formulate and accept their requirements themselves.
Should providers help with the catalogue?
Better not before the tender, because the catalogue would otherwise be tailored to one provider. Questions from providers during the tender, on the other hand, are useful.
What is an acceptance criterion?
A testable condition that decides whether a requirement is met – ideally with a concrete test case.
How is the catalogue used during implementation?
As the basis for configuration, test cases and acceptance. This keeps it traceable whether the agreed services were delivered.
What belongs to the constraints?
Legal requirements such as data protection and retention, data location, budget, schedule and the existing systems the software must work with.
How are costs compared?
Through the total cost over several years: licences, implementation, data migration, internal time, training and operation. A cheap entry can be more expensive over five years than a higher licence with less effort.
How are unmet Should requirements handled?
They feed into the assessment with weights and can be a subject of negotiation, such as delivery in a later version. Contractually assured extensions should be recorded with a date.
Sources
- IREB – International Requirements Engineering Board (CPRE)
- ISO – ISO/IEC/IEEE 29148 requirements engineering
- ISO – ISO/IEC 25010 software quality model
- HERMES – project management method of the Swiss federal administration
- Swiss Federal Act on Data Protection (FADP, SR 235.1) – Fedlex
This page provides orientation and does not replace legal or tax advice. The cited legal sources in their applicable version are authoritative.
Read more
More on Setup, governance & selection
FLIORE in your family office
See structures, compliance and consolidated wealth with your own questions – in a personal demo.