How to prepare a brief for developers?
Creating software is like designing your own lego set with the pieces and instructions on how it all goes together.
You need to provide an understanding of what the end result should look like. Then the developers help by breaking the end result into the small pieces that will need to be created.
This article shows the various high level pieces and describes what you and the developers need to consider. The steps are called RAGDAR (Roles, Areas, Goals, Data, Abilities, Results) and represent the various aspects of the solution that you as the expert will need to contribute to.
Notes on tackling this
It should be tackled as an iterative process, not just top to bottom.
You don’t need a 100% complete answer to every part, that will come through conversation with the developers. The more you can get your thoughts sorted out the easier it is for the developers to understand and contribute.
This isn’t the only way of expressing your know-how, if you like diagrams and flowcharts, detailed explanations, whatever works for you to get the ideas out, the developers job is to translate.
ROLES
List out the ROLES of the various people who will be utilising this solution.
Next, add some detail about their usage – this should include things like whether they will be an Admin or standard User, the frequency of their usage of the program, where they will be accessing it from and if this will be their primary software program.
We’ve included this cheat sheet to help you:
Areas
What areas of the solution are required?
This is a very developer centric question and it isn’t critical you answer completely, if you can see obvious “sections” within the system add them in otherwise your developer will fill in this component.
Possible areas include administration area, user settings, customer account/payment, common patterns include
Typically each key Role will have their own area where they see status, data, reports and access to processes that are relevant to them.
Areas may be shared between several roles and may break down along “stages” of a process or the type of data (Accounts VS Invoicing)
GOALS
For each role you need to identify the key GOALS the user will have when using the system - put yourself in the user’s shoes and ask “why would I put the effort in?”
These can be expressed either as “known goals” or as a hypothesis to be tested.
For each Role:
Why do they want to use the system?
What are their key reasons to use it? Eg. To assist in making a sale, or provide costings for quotes
Now, for each Role in each Area of the system go through the next 4 steps
Data
Collect a list of DATA or entities the system will need to remember. Typically, these are names of categories of things that describe the company and that the company uses.
Examples of entities include: Invoices, Company details, Pricing Structures, Organisational Chart, etc. Then for each entity you will need to list the bits of data the system will need to work with..
For example, the data required for the invoice would include:
Net Price, Tax and Total price
Delivery address
Payment status, etc
Abilities
This is the point you provide your workflows, diagrams, explanations or existing prototypes to provide examples of how you currently .
Consider for each role and each goal - What ABILITIES does the system need to provide the user?
For example:
As a user, when I start, I need the ability to login
As an administrator, when prices change, I need the ability to find and modify stock prices
Ability to take credit card payment
Ability to quote rates based upon different specification, etc
RESULTS
For each combination of Role, Goal and Ability, what RESULTS would the user expect.
For example:
List all Reports that must be produced
List all the Dashboards required and the frequency they should be updated
List all automated emails
System messages sent to specific roles/users. (Eg. When a sale is made or an order is placed - notify the relevant staff)
Credit cards debited
Text messaging
Best retailer and best retail sales person reports