At Citadel Matrix, every project follows the same five steps: you send a request, we meet to gather requirements, you receive a quote, payment is collected when you accept it, and the software is built and delivered. The meeting is step two — and it shapes everything after it.
Bring the problem, real examples, and the people who know the work. Leave with agreed requirements that become the basis for your quote.
What the meeting is for
The goal is a shared, specific understanding of what the software must do. Not a technical design, and not a final answer to every question — but enough agreement about the people, the process, the information, and the systems involved that a quote can be accurate and the build can start without surprises.
What to bring
- The problem, in plain words. What is slow, frustrating, error-prone, or impossible today? Who does it affect?
- Real examples. The spreadsheets, forms, emails, documents, or screenshots you use now. Examples answer questions that descriptions can’t.
- A list of the tools involved. The software, platforms, and files the work touches, and anything the new software should connect to.
- The people who will use it. Which roles, roughly how many people in each, and whether they’re staff, customers, or partners.
- Constraints that matter. Timing, budget expectations, policies, or requirements that come from your industry or customers.
- One-sentence description of the problem
- Two or three real examples of the current process
- List of tools and systems involved
- Who will use the software, by role
- Any deadline or constraint that can’t move
Who should attend
Three perspectives make a requirements meeting work. They can be the same person in a small organization, or several people in a larger one:
- Someone who can make decisions about priorities and scope.
- Someone who does the work every day and knows where it gets stuck — including the exceptions.
- Someone who knows the systems and data, if the software needs to connect to existing tools.
Questions we work through
- What must the software do, and what would make it a success?
- Who will use it, and what does each role need to see and do?
- Where does work slow down today, and why?
- What information does it store, and where does that information come from?
- What systems does it need to connect to?
- How will you know it works?
Common pitfalls to avoid
- Describing a solution instead of the problem. “We need a dashboard” is a guess; “managers can’t see which jobs are late” is a requirement.
- Skipping the exceptions. The unusual cases — missing information, rejected requests, urgent jobs — are where software gets complicated. Mention them.
- Making everything top priority. Decide what the first version must do. The rest can come later.
- Forgetting who looks after it. Think about who will manage users, update content, or answer questions once the software is running.
What you leave with
The outcome is a set of requirements you agree with — the basis for your quote. The quote states what will be built and what it costs. Nothing is built until you accept it; once you do, payment is collected and work begins.
- Bring the problem and real examples, not just a feature list.
- Include a decision-maker and someone who does the work.
- Name the exceptions early.
- The meeting produces agreed requirements — the basis for your quote.
Ready for step one?
Send a request with the basics. We’ll reply to set up the requirements meeting.