App and system brief
Problem, users, platforms, features, data, integrations and the first version's scope.
- Technicians get their orders by phone, and we type the visit reports into a spreadsheet by hand at the end of the week.
- Every order has a status the office can see within an hour of the visit.
- •Office: creates orders and assigns a technician
- •Technician: sees their own orders and adds a report with photos
- •Web browser
- •A PWA instead of a store app
- •A technician opens an order on their phone and closes it with a report and a photo
- •The office sees the list of orders with a status filter
- •Customer signature on the phone
- •Export to the accounting software (which format it accepts is still to be checked)
- Customer addresses and photos from the visits. A technician sees only their own orders.
- •Deadline: first version for the heating season
- and 2 more points
Fill in and download
The document updates as you fill in the 12 fields. Everything happens in your browser; nothing is sent.
When to use the app brief
Describe features as situations: who does what, and how you'll know it works.
If the app has to connect to other systems,
then describe the integrations by system name and API documentation. That's where surprises usually hide.
If you don't know exactly what you need yet,
then describe the problem, the users and the process, and in place of the features write that the list is open. A brief like this is the starting point for a paid analysis phase.
If you already have a detailed description of features, screens and acceptance criteria,
then you have a specification, not a brief. A specification grows out of a brief, not in place of it. Specification generator
If the project is co-financed from EU funds, or you are ordering as a public body,
then check the procedure for choosing a vendor before you send the brief to the first company. Choosing outside the required procedure can mean the expense is not recognised as eligible.
If every feature seems essential,
then set priorities. If everything is essential, each company decides for itself what to leave out, and each one leaves out something different.
What next: the same brief to several companies
A brief is most valuable when every vendor gets exactly the same thing. For example, one week for questions and another week for offers, so the answers reach everyone in time.
- SendingOne version of the brief, with a date or version number
- A week for questionsAnswers for everyone, without saying who asked
- ConversationsHalf an hour with each company
- A week for questionsQuestions about the brief
- A week for offersOffers in the same structure: scope, exclusions, assumptions, billing model, schedule
The brief
You Vendors. If you change something, you send the new version to everyone.
Questions
Vendors You. A company that read the brief carefully usually comes back with a few specific questions.
Offers
Vendors You. Half an hour going through the questions shows more than the offer alone.
Questions
First about what happens to what you type, then about the document itself.
Got the document ready?
Send it to us with your question. We reply within an hour with a quote.