How to use this template
This template helps you describe a software project clearly before you ask developers for proposals. You do not need technical knowledge to complete it. Delete this page before you share the brief.
- Replace everything in [square brackets] with your own details. Examples are there to show the kind of answer expected; delete them once you have written your own.
- Answer what you can and write "not sure" where you do not know. Gaps are useful: they show the developer what to explore with you.
- Describe problems and outcomes, not technical solutions. "Staff re-type every order into the accounting system" is more useful than "we need an API".
- Involve the people who do the work today. They know where the current process breaks down.
- Attach examples: screenshots, spreadsheets, paper forms, reports and documents from your current process. Replace any real personal data in them with made-up examples before sharing.
- Agree the brief with your decision-makers (section 13) and sign it off (Appendix C) before sending it out, so every developer receives the same version.
- If the brief contains confidential information, ask developers to sign a non-disclosure agreement before you share it.
This template was prepared by Syxel Technologies Limited. For help completing it, or to turn it into a scoped project plan, contact [email protected].
[Organization] Software Project Brief: [Project Name]
| Prepared by | [Name, role] |
| Project sponsor | [Name, role] |
| Version | [1.0] |
| Date | [Date] |
| Status | [Draft, for discussion or approved] |
| Shared with | [Developers or vendors who received this version, and date] |
1. Background and problem
| Question | Your answer |
|---|---|
| Organization name, sector and what you do | |
| Project name | [A short working name] |
| In one or two sentences, what do you want built or changed? | |
| What problem does this solve? Who has the problem, and how often? | |
| What does the problem cost you today? (time, errors, lost sales, customer complaints, risk) | |
| Why now? (growth, a new service, a regulation, an old system reaching end of life) | |
| What have you already tried, and what happened? | |
| Is this a new system, a replacement for an existing one, or an upgrade? |
2. Goals and success measures
List what the project must achieve and how you will know it worked. Measurable goals help developers suggest the right scope and help you judge the result.
| Goal | How we will measure it | Today | Target | By when |
|---|---|---|---|---|
| [e.g. Process orders faster] | [e.g. Average time from order to dispatch] | [Current figure] | [Target figure] | [Date] |
| [e.g. Fewer data entry errors] | [e.g. Orders corrected per month] | |||
Out of scope
List anything this project will not cover, so nobody assumes it is included.
- [e.g. Replacing the accounting system]
- [e.g. Online payments, planned for a later phase]
3. Users and roles
List every type of person who will use the system, including customers, staff, managers, administrators and outside partners.
| User role | Who they are | Approximate number | What they need to do | What they must not see or do | Device and location |
|---|---|---|---|---|---|
| [e.g. Customer] | [e.g. Members of the public] | [e.g. 2,000 a month] | [e.g. Place and track orders] | [e.g. Other customers' orders] | [e.g. Phone, anywhere] |
| [e.g. Staff] | [e.g. Desktop, office] | ||||
| [e.g. Manager] | |||||
| [e.g. Administrator] | |||||
| Question | Your answer |
|---|---|
| Will users have unreliable or slow internet, for example in rural areas or on mobile data? Do they need to work offline? | |
| Do any users need accessibility support, such as large text or screen reader compatibility? | |
| How do users sign in today? (email and password, Microsoft or Google accounts, none) | |
| How much training will users get, and who provides it? |
4. Current process (as-is)
Describe how the work is done today, step by step, including the workarounds. If you have more than one process, copy this table for each one.
Process name: [e.g. Taking and fulfilling a customer order]
| Step | Who does it | What they do | Tools or documents used | Problems or delays |
|---|---|---|---|---|
| 1 | [e.g. Sales clerk] | [e.g. Takes order by phone or email] | [e.g. Paper order form] | [e.g. Details missed, illegible] |
| 2 | [e.g. Excel spreadsheet] | [e.g. Re-typed, errors] | ||
Attach examples of what is used today:
- Paper forms or templates
- Spreadsheets
- Screenshots of current systems
- Example reports
- Emails or messages that are part of the process
- Process diagrams or written procedures
5. Desired process
Describe how the work should happen once the new system is in place. Focus on what people and the system should do, not on how screens should look.
| Step | Who or what does it | What happens | What changes from today |
|---|---|---|---|
| 1 | [e.g. Customer] | [e.g. Places order on the website and receives a confirmation email] | [e.g. No re-typing by staff] |
| 2 | [e.g. System] | [e.g. Sends order to the warehouse queue and accounting system] | |
| Question | Your answer |
|---|---|
| What must stay the same? (steps, documents or approvals required by policy, regulators or customers) | |
| Which approvals or sign-offs must the system enforce? | |
| What notifications should be sent, to whom, and how? (email, SMS, in-app) | |
| What reports or dashboards do managers need, and how often? |
6. Features: must-have, should-have and could-have
List the features you need and give each a priority. This helps developers propose a first version that fits your budget and plan later phases.
- Must-have: the system is not usable or does not solve the problem without it.
- Should-have: important and expected, but the first version could launch without it if needed.
- Could-have: useful extras to add if time and budget allow.
- Won't have this time: agreed as out of scope for now, recorded so it is not forgotten.
| ID | Feature | Description and who uses it | Priority | Notes |
|---|---|---|---|---|
| F-01 | [e.g. Online order form] | [e.g. Customers choose products, delivery address and delivery date] | [Must] | |
| F-02 | [e.g. Order status tracking] | [e.g. Customers and staff see where each order is] | [Should] | |
| F-03 | [e.g. Monthly sales dashboard] | [e.g. Managers see sales by product and parish] | [Could] | |
| F-04 | ||||
| F-05 | ||||
| F-06 | ||||
| F-07 | ||||
| F-08 | ||||
| F-09 | ||||
| F-10 |
Won't have this time: [list features agreed to be left out of this phase].
For more detail on how each user will use a feature, complete the user story table in Appendix A.
7. Data and integrations
Existing systems
List the systems the new software must work with or replace. Record the details of each connection in the integration inventory in Appendix B.
| System | What it is used for | Vendor and where it runs | Keep, replace or connect? |
|---|---|---|---|
| [e.g. Accounting software] | [e.g. Invoicing and payments] | [e.g. Vendor name, cloud] | [e.g. Connect: send each order as an invoice] |
| [e.g. Email] | |||
Data to bring across
| Data | Where it is now | Format | Approximate volume | Condition (clean, duplicated, incomplete) |
|---|---|---|---|---|
| [e.g. Customer list] | [e.g. Spreadsheet and accounting system] | [e.g. Excel] | [e.g. 5,000 records] | |
| [e.g. Product catalog] | ||||
| Question | Your answer |
|---|---|
| Do any of your current systems offer an API or a data export? Who can confirm this? | |
| Will the system take payments? If so, which payment provider or bank do you use or prefer? | |
| Does the system need to send SMS, email or push notifications? | |
| Who will clean and check imported data before go-live? | |
| How much data do you expect the system to hold after three years? |
8. Platforms
Tick each platform the system must support, and say who will use it there.
- Web application, used in a browser on desktop and laptop computers
- Mobile-friendly website, used in a browser on phones and tablets
- iOS app (iPhone and iPad), downloaded from the Apple App Store
- Android app, downloaded from Google Play
- Internal app only, not published publicly
- Works offline and syncs when a connection returns
- Administrator portal for managing users, content and settings
| Question | Your answer |
|---|---|
| Roughly what share of your users are on iPhone, Android and computers? (a guess is fine) | |
| Does the app need phone features such as the camera, location, barcode scanning or notifications? | |
| If apps will be published, will they be published under your organization's own Apple and Google developer accounts? | |
| Are there company devices or browsers the system must work on? |
9. Security and privacy
If the system will collect or use information about identifiable people, such as customers, staff, members or patients, the Jamaica Data Protection Act, 2020 (JDPA) applies. The Act took full effect on 1 December 2023 and is overseen by the Office of the Information Commissioner. Its eight data protection standards are: fairness and lawfulness, purpose limitation, data minimization, accuracy, storage limitation, rights of data subjects, technical and organizational measures, and cross-border transfers.
Personal data in the system
| Type of personal data | Whose data | Why it is needed | How long it must be kept | Sensitive? (yes or no) |
|---|---|---|---|---|
| [e.g. Name, email, phone, delivery address] | [e.g. Customers] | [e.g. To deliver orders] | [e.g. a set period after the last order] | [No] |
| [e.g. TRN] | ||||
Sensitive personal data includes health information, genetic or biometric data, and information about criminal offences, among other categories defined in the Act. Collecting it needs extra care and should be discussed with your Data Protection Officer or legal adviser.
Requirements to discuss with developers
- Collect only the personal data the system needs, and say why on the screen or in a privacy notice.
- Each user role sees only the data it needs (section 3).
- Multi-factor authentication for staff and administrator accounts.
- An audit log of who viewed, changed, exported or deleted records.
- Data encrypted in transit and at rest.
- A way to find, export, correct and delete a person's data when they exercise their rights under the Act.
- Automatic deletion or anonymization of records when the retention period ends.
- Regular backups, and a tested way to restore them.
- Security testing before launch, and a process for applying security updates afterwards.
- A plan for detecting and responding to a data breach. Under the Act, a breach affecting personal data must be reported to the Information Commissioner within 72 hours of becoming aware of it, and affected people must be notified as required by the regulations.
- If card payments are taken, the payment provider handles card details so the system does not store them, and PCI DSS requirements are considered.
| Question | Your answer |
|---|---|
| Who is your Data Protection Officer, or who advises you on data protection? | |
| Will personal data be stored or processed outside Jamaica? (Many cloud services are.) The Act restricts cross-border transfers. | |
| Should a data protection impact assessment be done before development starts? | |
| Are there other rules you must follow? (sector regulators, PCI DSS, client contracts) | |
| Will the developer have access to live personal data? If so, a written agreement setting out their obligations as a processor is needed. |
Check the Office of the Information Commissioner's website for current registration requirements for data controllers.
10. Hosting and ownership
| Question | Your answer |
|---|---|
| Where should the system be hosted? (cloud, your own servers, no preference) | |
| Do you have existing cloud accounts (for example Microsoft Azure, AWS or Google Cloud) that should be used? | |
| Who will pay hosting, domain, app store and third-party service costs after launch? | |
| Who will manage hosting, updates and backups after launch? (you, the developer, another provider) | |
| Do you need separate test (staging) and live environments? |
Ownership checklist
Agree these points in the contract before work starts:
- Your organization owns the source code and other work produced for the project, or the license terms are clearly stated.
- The code is kept in a repository your organization owns or can access at any time.
- Domain names, cloud hosting, app store developer accounts and third-party service accounts are registered in your organization's name.
- Administrator credentials for every account are handed over and stored securely by your organization.
- Documentation is provided: how the system is built, deployed, backed up and restored.
- Any third-party or open-source components and their license terms are listed.
- There is a clear handover process if you change developers.
11. Budget range and timeline
A budget range helps developers propose a realistic scope. Without one, proposals are hard to compare. Phased delivery, where a first version launches with the must-have features, is one way to fit a project to a budget.
| Item | Your answer |
|---|---|
| Budget range for development | From [ ] to [ ] |
| Budget for running costs per year (hosting, licenses, support) | From [ ] to [ ] |
| Is the budget approved? If not, when will it be? | |
| Funding source or conditions (for example a grant with reporting rules) | |
| Would you consider a phased delivery? | [Yes, no or not sure] |
| Milestone | Target date | Fixed or flexible? | Reason |
|---|---|---|---|
| Proposals received | |||
| Developer selected | |||
| Work starts | |||
| First version ready for testing | |||
| Launch | [e.g. Must be live before a product launch or contract start] | ||
| Question | Your answer |
|---|---|
| How much time can your staff give to the project each week for meetings, questions and testing? | |
| Are there busy periods when staff will not be available? |
12. Decision-makers
List everyone involved in decisions about the project, and what their role is. Name one day-to-day contact for the developer.
| Name | Role and department | Part in the project | Availability |
|---|---|---|---|
| [Name] | [e.g. Managing Director] | [e.g. Approves budget and final sign-off] | |
| [Name] | [e.g. Operations Manager] | [e.g. Day-to-day contact, approves requirements] | |
| [Name] | [e.g. Finance Manager] | [e.g. Consulted on integration with accounting] | |
| [Name] | [e.g. Data Protection Officer] | [e.g. Consulted on personal data] | |
| Question | Your answer |
|---|---|
| Who makes the final decision on which developer to use? | |
| Who approves changes to scope, budget or timeline during the project? | |
| Who tests and accepts the finished system? | |
| Does a board, committee or parent company need to approve the project? |
13. Support after launch
Software needs care after launch: fixes, security updates, operating system and browser changes, app store requirements and new features. Agree how this will work before the project starts.
| Question | Your answer |
|---|---|
| How long after launch should defects be fixed at no extra cost? (warranty period) | [ ] |
| Who will users contact with problems, and during what hours? | |
| How quickly do problems need a response? (for example, system down versus minor issue) | |
| Who will apply security updates and keep the system current? | |
| Who will update the mobile apps when Apple or Google change their requirements? | |
| Do you expect ongoing improvements? Roughly how often? | |
| Who in your organization will administer the system day to day (users, settings, content)? | |
| What training and user guides do you need, and for whom? |
Questions to ask each developer
- Have you built similar systems, and can we see examples or speak to past clients?
- Who will work on our project, and who is our main contact?
- How do you handle changes to scope once work has started?
- How often will we see working software during the project?
- How do you test the system before launch, including for security?
- What happens to our code, data and accounts if we stop working together?
- What support options do you offer after launch?
Appendix A: User Stories
A user story describes one thing a user needs to do and why, in the user's own terms. Write one row per need. Acceptance criteria say how you will check that the story works.
| ID | As a (role) | I want to (action) | So that (benefit) | Priority | Acceptance criteria |
|---|---|---|---|---|---|
| US-01 | [e.g. Customer] | [e.g. see the status of my order] | [e.g. I do not have to call to ask] | [Must] | [e.g. Status shows received, packed, dispatched or delivered, and updates when staff change it] |
| US-02 | [e.g. Manager] | [e.g. approve refunds over a set amount] | [e.g. large refunds are checked] | [Should] | |
| US-03 | |||||
| US-04 | |||||
| US-05 | |||||
| US-06 | |||||
| US-07 | |||||
| US-08 | |||||
| US-09 | |||||
| US-10 | |||||
| US-11 | |||||
| US-12 |
Appendix B: Integration Inventory
List every system the new software must exchange data with. If you do not know an answer, write "not sure" and name who could find out.
| System | Owner or vendor and contact | Data exchanged | Direction (in, out, both) | Method (API, file export, manual) | How often | Documentation available? |
|---|---|---|---|---|---|---|
| [e.g. Accounting software] | [Vendor, contact] | [e.g. Invoices, customer accounts] | [Out] | [e.g. API] | [e.g. Each new order] | [Yes, no or not sure] |
Appendix C: Sign-off
We have reviewed this software project brief, version [1.0], and agree that it describes our needs well enough to share with developers. We understand that requirements will be refined with the chosen developer, and that changes to scope, budget or timeline will be agreed in writing.
| Name | Role | Signature | Date |
|---|---|---|---|
| [Project sponsor] | |||
| [Day-to-day contact] | |||
| [Finance approver] | |||
Change log
| Version | Date | Changed by | Summary of changes |
|---|---|---|---|
| [1.0] | [First version] | ||