Technical Requirements Document

What is a Technical Requirements Document?

A Technical Requirements Document is the blueprint developers refer to while working on a specialized project. A TRD should be a straightforward and efficient way to communicate scope and design/technical ideas between my team and other stakeholders. Creating a document that outlines the technical details that need to be met increases the chances of having a successful project and decreases the chances of something going wrong during implementation and even after the product has launched.

The most effective way for a TRD to be created is when the whole team collaboratively solving potential problems and creating new solutions. My team is made up of several T-shaped employees who excel in their core responsibilities, and can support one another, and our clients, with tasks outside of their expertise effectively. This project crossed the desk of developers, marketers, and designers during its production.

Technical Writing

Template & Table of Contents
Although our team has developed and consulted on many Drupal migrations, we did not have an official TRD template. The outline I created was built on the back of many hours of research, as well as consolidation of internal documents.
I wrote in full or in part all bolded sections in the below Table of Contents:

1.1 Problem/Opportunity Description 
1.2 Project Outcomes 
1.3 Project References 
1.4 Acronyms and Abbreviations 
1.5 Definitions 
1.6 Roles

2.1 Current System Identified Opportunities 
2.2 Heuristic Evaluation 
2.2.1 Heuristic Definitions
2.2.2 Methodology
2.2.3 Heuristic Artifact 
2.3 Registration Process

3.1 Summary of Functions 
3.1.1 Functional Requirements 
3.2 Summary of User Impacts 
3.2.1 User Stories 
3.3 Registration Point Merger (aka “Single Sign On”, “SSO”) 
3.3.1 Current Scenario 
3.3.2 Desired Scenario & Considerations 
3.3.3 Technical Details

4.1 Specific Performance Requirements 
4.1.1 Accuracy and Validity 
4.1.2 Capacity Limits 
4.1.3 Languages & Frameworks 
4.1.4 Databases 
4.1.5 Search Engine Optimization 
4.2 Design Standards 
4.2.1 Accessibility 
4.2.2 Mobile First Approach 
4.3 Site Map 
4.3.1 Diagram 
4.3.2 Content Types 
4.4 Search Functionality 
4.5 Multilingual Capabilities 
4.6 Customization and Flexibility

5.1 Flagged Features and Functionalities 
5.2 Recommended Solutions
5.3 Potential risks midst launch & post launch

6.1 Requirements 
6.1.1 Web hosting security 
6.1.2 Data encryption and transmission
6.1.3 Administrator controlled username and password access 
6.1.4 Automatic timeout/log-off 
6.1.5 Administrator controlled user level read, write, edit and delete capabilities 
6.1.6 Information Security Industry Standard encryption and SSL certifications 
6.1.7 User settings 
6.1.8 Content settings
6.1.9 Input Validation 
6.1.10 Code Maintenance 
6.1.11 Drupal Security Modules

7.1 System Description 
7.2 Systems Integration

Supporting Documentation

Additional documentation I created to help inform the completed TRD included:

  • Requirements Spreadsheet
  • Use Case Document
  • Risk Assessment
Product Development Tracking

As the Producer for this project I was responsible for allocating responsibilities to members of my team. Steps I took are as follows:

  1. Creation of Project Strategy document
  2. Tickets created & time estimates entered in PM software
  3. Referencing & updating Utilization Profile to assign employees to tasks
  4. Regular check-ins & conversations as document was built up
  5. Copy editing of writing & final presentation of document


Heuristic Analysis

The heuristic analysis conducted was modeled after the Nielsen/Norman standard.

Some evaluators will be better than others at conducting heuristic evaluations, but that doesn’t mean a strong evaluator will consistently find a high number of usability problems on every UI he/she evaluates. Because of this fact, I had three evaluators independently evaluate this website. The evaluators were asked to explore the site through the lens of a end-user with a specific outcome related to the client’s North Star indicator. 

The three evaluators (myself, a developer, and a marketer) conducted the analysis and I compiled the results into average severity scores.

Throughout the projects I have conducted an evaluation on, I have kept a list and developed a 230+ line evaluation catalog of features and functionalities that should be tested for most web projects. This has allowed me to expedite the analysis process.

User Stories

The User Story format I utilize:

As a <role> I want to <goal> so I can <value>.

I also assign a User Value and Effort Level to help triage features for development. You can read about ma simple formula in the blog I wrote: HERE.

The following aspects were examined via internal documentation, research and end user interviews:

  • Users (peers, facilitators, their roles, responsibilities, behaviour, etc.)
  • Location (online)
  • Technical infrastructure
  • Resources (material and human, access and support)
  • Activities
  • Intended outcomes (products, performance and process)
  • Actual outcomes 
  • Curriculum context


The final product was a 52 page TRD for the client and a template with instructions for future use by the agency.