Start with a task, not a feature list
A useful brief describes what people need to achieve. “We need an ERP” leaves many questions open. “Our administrators enter the same attendance information in three spreadsheets and need one approved record” identifies a workflow. Explain who performs the task, where it begins, what information is used and how success will be recognized. A short, specific description helps a development team separate the underlying need from a proposed solution.
Define users and permissions
List the people who use the system and what each group can view or change. A college portal might include students, trainers and administrators. A student may view their own records; a trainer may update an assigned class; an administrator may manage access. Do not assume every user needs the same dashboard. Record who approves changes and how access should be removed when someone leaves.
Map one complete workflow
Choose a frequent task and write its steps from beginning to end. For a training registration, the flow might be: a learner reads prerequisites, submits an inquiry, receives batch information, confirms enrollment and later accesses the course. Include exceptions such as an incorrect email address, a full batch or a request to change details. Those cases often reveal requirements that a collection of attractive screens would miss.
Separate the first release from later ideas
Create three lists: essential for launch, useful after launch, and undecided. A first release should complete the main workflow safely. An optional analytics dashboard should not hide an unresolved permission model. For each essential item, write a simple acceptance example: “A trainer assigned to Class A can update Class A attendance and cannot edit Class B.” This is more reviewable than “attendance management included.”
Describe content, data and ownership
Identify who supplies the logo, photographs, course descriptions and existing records. Say whether data needs importing and provide a small anonymized sample rather than real personal records during early discussions. Agree who will own the domain, hosting account, source code and administrator access. Also identify who maintains the content after launch and what support is expected.
A brief you can adapt
- Goal
- What problem should the project solve?
- Users
- Who uses it, and what can each role do?
- Main workflow
- What happens from the first action to a successful result?
- First release
- Which capabilities are essential, and how will you check them?
- Inputs
- What content, records and integrations are available?
- Constraints
- What timeline, budget range, access needs or device requirements apply?
- After launch
- Who updates content, handles support and manages backups?
Before requesting a quote
Read your brief as someone who has never worked in your organization. Replace unexplained abbreviations and attach examples of the existing process. Ask providers to state assumptions, exclusions and recurring costs. A shared understanding of the work makes proposals easier to compare and reduces surprises during delivery.
Discuss your software project or read our student project portfolio guide.