How to Gather Requirements Before Writing a TOR So the System Meets Real Operational Needs
A strong requirement baseline starts with users, workflows, outcomes, and constraints before being translated into technical specifications.
A strong TOR should not begin with an old specification or a vendor brochure. It should begin with a clear understanding of the problem the organization is trying to solve, the needs of actual users, and the outcomes the project must deliver.
If requirements are unclear, even a technically detailed TOR can result in a system that is successfully installed but fails to meet real operational needs.
1. Start with the Business Need, Not the Product
Before asking what system to buy, establish:
- What problem exists today?
- Who is affected?
- Which process needs improvement?
- What outcome is expected?
- What happens if the project is not implemented?
2. Gather Requirements from Actual Users
Different stakeholders often see the project differently. Requirements should therefore consider input from end users, operations, maintenance, engineering / IT / OT, procurement, management, and teams responsible for post-project support.
3. Understand the Existing Workflow
Review how work is currently performed from input through process to output. Identify who initiates the process, what information is required, who approves decisions, which systems must interface, where delays occur, and which activities remain manual.
4. Separate Requirements from Specifications
A requirement defines what the system must achieve. A specification defines the technical parameters used to describe how or to what level the requirement must be achieved.
Requirement: Users must be able to retrieve historical information continuously.
Specification: The system must support at least X days of retained data under defined operating conditions.
5. Make Requirements Verifiable
Terms such as “high performance,” “easy to use,” or “future-proof” are difficult to evaluate unless they can be measured.
Well-defined requirements form the basis for later FAT, SAT, UAT, and acceptance criteria.
6. Consider Real Project Constraints
- Budget
- Site conditions
- Existing infrastructure
- Timeline
- Integration
- Cybersecurity
- Maintenance capability
- Available resources
- Environmental conditions
Before Writing the TOR
The project team should be able to explain: What problem are we solving → who will use the system → what must it achieve → what constraints exist → how will compliance be verified? A clear requirement baseline makes the TOR easier to justify, reduces ambiguity and overspecification, and gives vendors a more consistent basis for comparable proposals.