Guide · Ultineo SaaS
From an idea to a specification
This guide is for a founder or a manager who needs custom software and has never written a specification. You will be able to describe your need as situations that someone can check, each with its user, its action, its information, its result and its exception. No technical knowledge is needed: the words are those of your trade.
Checked against the product in November 2026
The five parts of a requirement you can check
- The user
Name the person by role: the manager, the technician, the customer. A requirement with no one in it cannot be checked by anyone.
- The action
One verb for the one thing this person does: asks, assigns, confirms. When you need the word "and", write two requirements.
- The information
What the person reads or enters in order to act, and where it comes from. Say which items are required.
- The result
What the person sees when it has worked, and what has changed for the next person. This is the sentence you will check.
- The exception
The case that changes the rule: information missing, a person not allowed, a slot already taken. Say what the user sees then.
- What a specification is not
A specification is not a list of screens, and it is not a technical document. It is a list of situations someone can check, written in your own words.
1. Describe one situation from start to finish
Do not start with the software. Start with one piece of work that takes time today and tell it as a story: who begins, what they hand over, who decides, what the first person receives at the end.
Then add the documents that show how it is done now: a form, a spreadsheet, an email. For each, say what stays and what changes.
Example. A workshop repairs coffee machines for cafés: today a café phones, and the manager notes the repair in a spreadsheet and calls a technician. Her story: a café asks for a repair, the manager assigns a technician and a slot, the café receives a confirmed date. She attaches the spreadsheet and marks the columns to keep.
In Ultineo. A project is opened in Ultineo SaaS after our team has reviewed your application, and your software is then designed and built with you. In the project workspace, preparation starts from the "Getting started" steps of the Dashboard: describe the problem and the result users need in "What will your project do?", complete "Who are your users / customers?" and "Key modules", add useful links in "References / inspiration" and click Save. Our team then reviews this presentation ("Analysis of your project").
2. Scope a first version you can check
List everything you would like, then keep one journey that is useful on its own: one team, a process they know, a result you can check. Group what belongs together by responsibility, not by screen.
Write the other ideas down under "later". An idea that stays visible is not a condition for starting.
Example. The workshop would like repair requests, a stock of spare parts, invoices and reminders. The first version keeps one journey: a repair asked for, assigned and confirmed. Stock and invoices go on the "later" list, with one line each on why they matter.
In Ultineo. In the project workspace, a business area groups related work and can contain several functions and pages; the interface calls the areas Modules. During preparation, open Modules, review each "Module name" and Description, fill in "Add a module" and click Add if a proposal is missing, then click "Validate the modules" when the list is correct. Any addition, edit or deletion resets the validation.
3. Write each requirement in four parts
Take each moment of the journey and write one sentence with four parts: the user, the action, the information, the result. Use the words your team already uses.
Test the sentence: could a colleague who was not in the room say whether a screen does this or not? If the answer depends on what you meant, the sentence is not finished.
Example. Vague: "The manager manages the schedule." Checkable: "The manager assigns a technician and a two-hour slot to a repair, chosen among the slots that are free that week. The café then sees the date and the name of the technician."
In Ultineo. To read what is planned for an area, open Modules and click Configure on the area concerned: you read its purpose, its user journey and its included scope, then the "Application features" and the "Administration features". On a page, Information lets you compare "What's included" and "What's not included". This analysis becomes a reference for checking that the build solves the right business problem.
4. Add the exception that changes the rule
A rule with only its ordinary case is half a rule. For each requirement, ask what happens when information is missing, when the person is not allowed, when two people want the same thing.
Write the ordinary case and one exception side by side, each with what the user sees. Those two situations make the rule checkable.
Example. Ordinary case: the café gives the model and the serial number of the machine, and the repair can be assigned. Exception: the serial number is missing. The request is kept, the café sees which field to complete, and the manager cannot assign it yet.
In Ultineo. When the rule of a function must change, open the specification of the function and click "Request a change". In "Your request", describe the rule, give one example of an ordinary case and one exception, then click "Send the request". Once the specification shows the change, read it again with your example in hand.
5. Answer each question where it is asked
Whoever builds your software will come back with questions. A question is not a reproach: it marks a decision that your text left open. Answer with the rule, an ordinary case and an exception, not with "yes".
Keep the answer with the requirement it completes. A decision given by phone or in a separate email is lost by the time someone checks the result.
Example. The question: can a café cancel a confirmed repair? The answer of the manager: until the day before, the café cancels and the slot becomes free again. On the day itself, the café sees the phone number of the workshop and cannot cancel online.
In Ultineo. In the project workspace, a question is asked on the item it concerns: a business area, a function or a page. Click the tasks icon in the top bar, read "To do" and open the item, then open "Answer the clarifications": fill in "Your answers", with one normal case and one exception when the rule allows several outcomes, and click "Submit my answers".
6. Turn your cases into a test list
Copy every ordinary case and every exception into one list. Beside each, write what you must see. This list is how you will accept the work, whoever builds it.
A screen can look finished and still handle an exception wrongly. Check behavior first, appearance second.
Example. The list of the workshop has six lines: three ordinary cases and three exceptions. Line four reads: "Repair without a serial number: kept, field shown to the café, cannot be assigned." A page is accepted when all six lines pass.
In Ultineo. In the project workspace, a specification describes intended behavior, and the development application shows what has actually been constructed. To compare them, read the planned task and its rules, open the built page in development, then complete the same ordinary case and the same exception as in the requirement. The test checks behavior as well as appearance.
Checklist
Before you hand over your specification
- 1. Describe one situation
One journey from the first request to the result received, with the people who take part in it.
- 2. Attach today's documents
The form, the spreadsheet or the email, with what must stay and what must change.
- 3. Name the first version
One useful journey that you can check, and every other idea on a list marked "later".
- 4. Write the four parts
User, action, information and result, in one sentence for each moment of the journey.
- 5. Add one exception
For each rule, the case that changes it and what the user then sees.
- 6. List your test cases
Each ordinary case and each exception on one line, with what you must see.
Go further
Prepare your software project with Ultineo SaaS
Send your application: our team reviews each one before a project is opened.
Questions
No. You can start with the business need, examples and constraints, and you do not need to decide every screen before beginning. Technical detail is useful when it describes a system you already use; it does not replace a clear explanation of what users should achieve.
It identifies the user, the action, the information needed and the expected result. Add the important exceptions and the limits of the scope, so that an ordinary case that works is not mistaken for a complete process.
No. In Ultineo SaaS, a business area groups related work, such as customer management or scheduling, and can contain several functions and pages. The interface calls the areas Modules.
Yes. Preparation is the starting point: functions and pages can be clarified, and later needs can be described through the project tools. Check the effect of an extension on your offer rather than treating every new idea as already included.
Because a rule or an expected result is still unclear: the question names the information needed to continue. Answer on the item that asks it, so that the answer stays connected to its function or its page. Answering supplies information; it does not by itself publish a change.
You send an application. Each application is reviewed by our team before the project is opened, and our team replies by email; there is no self-service sign-up. In the project workspace, our team also reviews the presentation of the project, and preparation stops at that step if the team does not validate it.