|
| |
Technical requirements are specifications for a technology such as a system or application. The following are illustrative examples.AvailabilityThe system will maintain availability of 99.99%.
ReliabilityThe system will maintain a mean time between failures of greater than 60 days.PerformanceThe system will have an average page load time of less than 2 seconds.ThroughputThe system will handle 1,000 concurrent users while meeting performance objectives.StandardsThe system will comply with our architectural and security requirements [provide links to relevant standards].
Authentication & AuthorizationThe system will conform to our policy for authentication and authorization [provide links to relevant standards].ServiceabilityChanges and upgrades to the system will not require total outages.MaintainabilityLogging 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.AccessibilityAll videos will have accurate closed captioning.PrivacyThe user interface will not allow employees to view customer birth dates stored in the customer database.Human ErrorThe 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 ErrorsSystem 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.Information SecurityUser credentials and all personally identifiable information will be encrypted in storage and transit.Audit TrailAccess to the database will result in logs including a high priority alert that is triggered for sensitive operations such as a database dump. Internal ControlsThe 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.DataCustomer data will be sourced from the customer database without permanently storing these fields in the billing system.Data MigrationHistorical customer invoices will be accurately migrated to the new system and will be viewable from the customer invoice screen.Data QualityThe data migration will confirm that the billing rate is accurate for every customer.UsabilityUsers will be able to permanently turn off each individual smart feature from the user preferences menu.ProductivitySales 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.StructureThe sales system will have a flat hierarchy of screens whereby no screens are at a depth of greater than 3. InteroperabilityThe website will work on all major operating systems, devices and browsers as specified in the current customer technology requirements [link to this document].Vendor Lock-inThe system will be based on custom code and open source without any dependency on proprietary technologies.Loose CouplingThe 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.Transitional RequirementsThe 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.SummaryThe following are common types of technical requirements:OverviewThe operational characteristics of a technology such as its performance, security, data quality and error handling.NotesIt 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 requirements above are non-functional requirements. Generally speaking, functional requirements are consider business requirements.Next: Non-functional Requirements
More about technical requirements:
If you enjoyed this page, please consider bookmarking Simplicable.
The common types and formats of requirements.
The common types of business need.
The common types of business needs analysis.
An overview of business requirements with examples.
A business requirements document template with an example.
A definition of business analysis with examples.
The common types of information requirements.
A complete overview of statement of work.
A list of common technological factors that influence strategy.
A few examples of non-functional requirements.
An overview of functional requirements with examples.
Common examples of process requirements.
An overview of service requirements with examples.
An overview of performance requirements with examples.
Common examples of stakeholder requirements.
TrendingThe most popular articles on Simplicable in the past day.
Recent posts or updates on Simplicable.
Site Map
© 2010-2023 Simplicable. All Rights Reserved. Reproduction of materials found on this site, in any form, without explicit permission is prohibited.
View credits & copyrights or citation information for this page.
|
