Technical requirements are specifications for a technology such as a system or application. It is common to define technical requirements with commanding verbs such as will, shall and must. Technical requirements are an opportunity to communicate business expectations for the end-to-end operational quality of a technology. As such, it can be a bad idea to fully delegate them to implementors, although they should certainly contribute. Technical requirements are typically designed to be smart. In many cases, technical requirements are specified at several levels of detail. For example, an initial requirement for a “flat structure” for a user interface may be later expanded with detailed specifications of screen flows and navigation.
The system will maintain availability of 99.99%.
The system will maintain a mean time between failures of greater than 60 days.
The system will have an average page load time of less than 2 seconds.
The system will handle 1,000 concurrent users while meeting performance objectives.
The system will comply with our architectural and security requirements with links to relevant standards.
Authentication & Authorization
The system will conform to our policy for authentication and authorization with links to relevant standards.
Changes and upgrades to the system will not require total outages.
Logging will be sufficient to quickly identify and resolve system problems with a mean time to repair of less than one hour for high severity incidents.
All videos will have accurate closed captioning.
The user interface will not allow employees to view customer birth dates stored in the customer database.
The system will detect when a price entered by a user is more than 10% from the realtime market price. This will result in a confirmation screen that warns the user of the discrepancy.
System errors will result in an error code that will be communicated to the user. This code will be well documented in the help desk system to expedite support and incident resolution.
User credentials and all personally identifiable information will be encrypted in storage and transit.
Access to the database will result in logs including a high priority alert that is triggered for sensitive operations such as a database dump.
The only persons that will have access to the decryption keys for customer data will be officially designated as data stewards. Data stewards will be prohibited from accessing databases and will not be given the authorizations required to do so.
Customer data will be sourced from the customer database without permanently storing these fields in the billing system.
Historical customer invoices will be accurately migrated to the new system and will be viewable from the customer invoice screen.
The data migration will confirm that the billing rate is accurate for every customer.
Users will be able to permanently turn off each individual smart feature from the user preferences menu.
Sales people will be able to generate a quotation using a single screen. It will be possible to regenerate the quotation without entering all fields again.
The sales system will have a flat hierarchy of screens whereby no screens are at a depth of greater than 3.
The website will work on all major operating systems, devices and browsers as specified in the current customer technology requirements [link to this document].
The system will be based on custom code and open source without any dependency on proprietary technologies.
The system will continue to fully function when the billing API is down with the exception of any functions that depend on uncached data from this API.
The old billing system will remain fully operational for a period of 3 months after the launch as a reference that can be used to confirm the correctness of calculations, user interfaces and migrated data.