Technology Advisory & Systems Engineering
Requirements Engineering & Architecture
Clear, testable requirements and architectures that vendors can build to.
What this covers
Poor requirements are the most common cause of failed technology projects. HQT elicits and documents requirements that are specific, testable, and traceable, and designs architectures that show how systems fit together.
Typical activities
- Stakeholder workshops and process observation
- Functional, non-functional, data, integration, and security requirements
- Traceability from business needs to requirements to test cases
- Solution and enterprise architecture, including integration and data flows
- Standards selection, such as accessibility, security, and interoperability standards
- Requirements baselines and change control
What you receive
A requirements specification, traceability matrix, architecture documents, and a change control process.
Why it matters
Requirements are the contract between the agency and its vendor. When they are clear, disputes are rare and acceptance is objective.
Signals that the specification is the binding constraint
These are signs that the next procurement milestone is waiting on the specification rather than on the schedule or the vendor:
- Change orders on an active project turn on what a clause meant rather than on genuinely new scope.
- The clearest available description of the future system is a vendor demo script or a feature list from a brochure.
- No one can name the statute, regulation, ordinance, or policy behind a disputed business rule.
- Integration points surface during user acceptance testing instead of during design.
- Program staff and IT staff describe the same process differently, and both are partly right.
- An earlier solicitation drew a wide price spread or a long list of bidder questions asking what the scope meant.
- Fields are overloaded, code sets differ by office, and two systems each claim to be the system of record.
How to read a draft specification
A requirement can be judged before anything is built. A sound one states a single need in operational language, carries a source, a priority, and a verification method, and can be shown satisfied or not without argument; standards for requirements practice, such as ISO/IEC/IEEE 29148, describe those characteristics. Non-functional requirements are stated in terms the agency can measure, including concurrent users at peak periods, retention taken from the approved records schedule, recovery time and recovery point objectives, and a stated accessibility conformance level.
Warning signs in a draft:
- A product or brand name used where a capability was meant, which narrows competition and invites protest.
- Terms such as "user friendly," "intuitive," and "as needed" inside shall statements.
- No priorities, so every line is mandatory and the price reflects it.
- Diagrams with boxes and arrows but no interface contracts, message formats, exchange frequency, or error handling.
- Retention, public records response, audit logging, and accessibility written as project tasks rather than as obligations the vendor must meet.
Constraints set outside the agency
Much of the architecture is fixed before the first workshop, so this work includes establishing what is genuinely open:
- What the incumbent contract says about data ownership, export formats, and the cost of an export, which governs whether a migration is possible at all.
- Reporting submissions whose layouts and cutoffs are set by a state or federal program office rather than by the agency.
- Exchange standards named in the specification instead of left to bidders, such as NIEM for information exchange across justice and public safety, HL7 FHIR where health data moves, and the NENA i3 architecture where next generation 911 is involved.
- Security, privacy, and accessibility regimes that place obligations on the design: the FBI CJIS Security Policy for criminal justice information, administered in each state by its CJIS Systems Agency; IRS Publication 1075 where federal tax information is handled; HIPAA where the agency is a covered entity or business associate; and, for state and local web content and mobile applications, the Department of Justice rule under Title II of the ADA, which adopts WCAG 2.1 Level AA.
- A written line between constraints the agency treats as fixed and those open to change, so bidders price the work instead of the uncertainty.
Judging the result later
Requirements quality shows up in the procurement and the build, and agency staff can measure it without help: the share of change orders traced to ambiguity rather than to new scope, the volume of bidder questions asking what the specification meant, defects found at acceptance that trace to a requirement defect rather than a coding defect, and how much the baseline moves after it is set. The harder test is whether every acceptance test maps to a numbered requirement, and whether that mapping is still current at go-live. A baseline that is not maintained through implementation stops settling arguments, and the agency is back to debating what was meant.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
Can the firm that writes our requirements also bid on the implementation?
That depends on your jurisdiction's procurement code and its conflict of interest rules, and many jurisdictions restrict a firm that prepares specifications from competing for the resulting contract. Settle the question with your procurement office and counsel before the specification is drafted, because the answer changes how the statement of work is written and who may attend elicitation workshops. If you want the requirements author held separate from the implementer, put that exclusion in the solicitation and in the contract rather than relying on an understanding.
How long does requirements and architecture work take before we can issue an RFP?
The duration is driven by the number of distinct business processes, the number of interfaces that must keep working, and how quickly agency subject matter experts can be scheduled, not by the size of the software being bought. A single-program system with a handful of interfaces is a much shorter effort than an enterprise replacement touching finance, permitting, and public-facing services. Stakeholder availability is usually the binding constraint, so ask any firm to quote a schedule that names the workshops required and who has to attend each one.
Do we still need written requirements if we are buying commercial or software as a service products?
Yes, though the emphasis shifts. With a configurable product you spend less effort specifying screens and more on fit and gap analysis, configuration decisions, data conversion rules, interface specifications, security and accessibility obligations, and the service levels the contract will carry. Without those written down there is no objective basis for acceptance and no way to compare two products that both claim to do everything.
What is the difference between requirements engineering and writing the RFP?
Requirements engineering produces the technical content: what the system must do, what data it holds, what it must connect to, and how each item will be verified. RFP development wraps that content in a solicitation with evaluation criteria, scoring, terms, and submission instructions. The two are usually sequential, and a solicitation is only as good as the requirements it carries. RFP development and vendor evaluation is a separate service that normally follows this one.
Who from our agency has to participate, and in what role?
At a minimum you need a decision maker who can settle disputes between programs, subject matter experts for each business process in scope, a data steward who knows the current systems of record and how the data is actually coded, and someone accountable for security, privacy, and records retention. Their time is heaviest during elicitation workshops and again during review of the draft baseline. Name those people in the project charter, because a requirement cannot be settled by staff who are not in the room.