QRA Corp

Automotive Requirements Guide & Checklist: The 10 Essentials for Writing a Clear Requirements Document

While requirements documents are not new to the automotive industry, the rapid rate of change brought about by the introduction of sophisticated automated and electrified systems means that drawing up a requirements document is now no longer a best-in-class practice, but rather, critical to ensuring the timeous delivery of a cost-effective product that meets customer’s expectations, and safety and emissions requirements.

Table of Contents


As the 4 ACES (Automated Driving, Connectivity, Electrification and Shared mobility) change the face of the automotive industry, the complexity of electronic and electrical systems (E/E) is increasing exponentially. Currently, about forty percent of component-spend in high-end models can be ascribed to electric and electronic systems, with that cost set to continue to grow.


At the same time, driven by customer demands for a heightened User Experience (UX) and inconsistent global legislation, manufacturers are forced to engineer an increasing number of novel variations of the base-specification. Consequently, the complexity of compiling requirements documents outlining the specifications, processes and procedures required to produce automotive components and systems continues to grow.


While requirements documents are not new to the automotive industry, the rapid rate of change brought about by the introduction of sophisticated automated and electrified systems means that drawing up a requirements document is now no longer a best-in-class practice, but rather, critical to ensuring the timeous delivery of a cost-effective product that meets customer’s expectations, and safety and emissions requirements.

Download the Free Guide & Checklist

Booklet & printable checklist now available for Automotive professionals!

1. Review the Contents of the Requirements Template

Developing an automotive requirements document requires a multi-faceted approach that includes not only the tangible word-based requirements but also sketches and technical drawings, and standards and engineering norms, to contextualize the information.


To achieve the desired quality of information, and save time, it is worthwhile to develop an updatable “living” manuscript from a trusted requirements document template.


A good requirements document template should have as a minimum:

It is also critical that the requirements document is “word processor friendly.” Team members are more likely to embrace the document as a tool if it is intuitive and easy to implement and maintain.


The template should also include standardized sections covering recurring topics such as terminology, formatting and traceability standards, and any internal guidelines the organization follows in documenting and managing the requirements documentation.


These standardized sections, or “boilerplates” as they are often referred to, are useful to promote consistency across projects. These are the sections that tend to remain little changed from project to project, and from team to team within a company, only evolving slowly to meet changes in methodology and lessons learned.


This provides a stable platform allowing for continuous development and refinement of the manuscript to best meet the evolution of the company’s business as well as accommodating emerging technologies.  


In compiling the requirements document the following elements have to be addressed:

It is equally important that the requirements document captures the intangible engineering and design requirements that specialists such as stylists and product planners specify. Consequently, it is important that the look, feel, and perspective of the original resources are retained, including:

While there is no standard that governs the requirements document’s layout, tracking, and change control per se, the process will obviously have to meet all relevant quality management standards, such as ISO 9001 and ISO/TS 16949, to meet the company’s obligations.

2. Develop a Concise Filing System

As the requirements document develops it is natural that changes and updates are made – It is therefore important that any of these changes can be recalled and its history reviewed. In order to do this, a well-controlled, long term filing system is crucial to ensuring long-term traceability and redundancy.


The ISO 9001 filing standards for documents offer a well-proven system that requires the following actions:

Adhering to these procedures will ensure that employees are always accessing the most current, approved version of the requirements document while being able to track and review historical information.


Limiting access to writing and editing these documents is important. The requirements document controller or administrator will hold this access with the authority to initiate reviews, make changes to the document or file and resubmit it for approval.


The approval process may include the input of a single individual or a team who needs to review from multiple angles. Reviewers should include team members who most frequently use the document, as they will have the best input on what has changed since the last revision.


When choosing a document control numbering system it is advisable to stick to ISO guidelines for conformity and also to standardize systems across the company. Thus the requirements document could be identified by a prefix such as SOP for a standard operating procedure, followed by REQ to describe the document.


Numbering can be done either sequentially, as created, or by using a numbering system in which each digit represents something. For example, SOP/REQ-1007 could mean the seventh requirements document within the standard operating procedure created by the department designated as 1000.


Document labels should also include an easily understood title, as well as an indication of the most recent review and approval date. Normally the creator(s), editor(s) and approval team are also included as a reference for any users that have questions or need to submit changes.

3. Maintain a Paper Trail of Changes

As the project advances through development it is likely that new requirements will be added and existing requirements will be improved upon. A change control system should be in place to capture these changes.


An audit trail should be maintained for all changes to requirements to ensure that the methods and reason for the changes are available for review and even regulatory inspection.


Documenting clear reasons for the requirement change can also be helpful later in the engineering process and can potentially reduce iterations in the development of a product or system.


By adhering to the following five steps in ISO/TS 16949, 4.2.3 (Control of documents,) the document change-control process is both simplified and standardized:

  1. Approve the adequacy of documents prior to issue (Including drawings and sketches)
  2. Review, update as necessary, and re-approve documents (Including drawings and sketches) – Provide suitable identification of any obsolete, revised or superseded documents retained for any purpose
  3. Identify changes to documents as well as identify their current revision status (Including drawings and sketches) – Use a single system, date, letter, number, but not multiple methods
  4. Make relevant versions of applicable documents (Including drawings and sketches) available at points of use
  5. Identify documents of external origin and control their distribution (Including drawings and sketches)
  6. Prevent the unintended use of obsolete documents, and apply suitable identification to these documents if they are kept for any purpose (Including drawings and sketches)

Download the Free Guide & Checklist

Booklet & printable checklist now available for Automotive professionals!

4. Use Industry-Specific Terms

As the requirements document is meant to be a working document that spans multiple divisions within an organization as well as being circulated to external suppliers, it is critical that there can be no confusion over what is intended in the manuscript.


When dealing with regulatory requirements it’s important to use industry-specific words and terms. This will be crucial for success when being audited as well as ensuring contextual uniformity of all documents contained in files relating to the requirements documents.


In the often highly technical and complex automotive environment it is not uncommon for terms to, incorrectly, be used interchangeably:

Recognizing the importance of unambiguous terminology several standards, such as ISO’s 26262 standard on E/E functional safety, already include a section on terminology or vocabulary – in this instance, part one specifies a vocabulary (a Project Glossary) of terms, definitions, and abbreviations for application in all parts of the standard.


The following standards organizations all have vocabulary specific to their requirements:

If the team is unsure of the correct terminology there are several online references that can be consulted for the applicable industry-specific terms:

5. Accommodate Evolving Manufacturer/Supplier Requirements

In the past there has mostly been a very clear distinction between manufacturers’ and suppliers’ functions and responsibilities in developing and producing parts; however, the increasing complexity of modern systems has led to these roles being less clearly defined.


Thus, the respective roles of manufacturer and supplier in drawing up the user requirement specification, traditionally compiled by the manufacturer, and the system requirement specification developed by the supplier is no longer that clear-cut.


In situations where manufacturers are exploring undefined nascent technologies, they will be required to outline much of the specification document features in as much detail as possible by specifying system specification solutions instead of only affirming requirements.


This is particularly true for systems that rely on both software and hardware. In this situation manufacturers have to specify a single component as two interactive elements: A hardware module and a piece of software code, possibly sourced from two suppliers, that have to function as a system.


One mechanism that facilitates this shift in roles is the multi-party review meeting, which when conducted at appropriate stages of the project allows for a flexible approach to the traditional manufacturer/ supplier roles.


There are typically six Joint Reviews in a normal hardware/ software (HW/ SW) development project:

While this is common in complex E/E systems it is equally relevant and actionable for less intricate, traditional mechanical components.

6. Write the Requirements for a Universal Audience

As suppliers, particularly technology companies that are less familiar with the stringent automotive standards and requirements, play an increasingly pivotal role in vehicle engineering manufacturers need to be particularly vigilant to make sure all documentation is understandable and actionable by all parties – internally and within supplier organizations.


This can be facilitated through:

Furthermore, document change control and the underlying filing system, as outlined in sections 2 and 3 above, must be strictly adhered to, and even audited from time to time.

Download the Free Guide & Checklist

Booklet & printable checklist now available for Automotive professionals!

6. Write the Requirements for a Universal Audience

As with any management or planning system, requirements must be measurable and testable against set values, milestones and performance targets.


These include tangible requirements, which are possibly a little easier to measure and test, such as:

However, in an environment of increasing technological innovation, there are now also intangible requirements that need to be measured and tested. While being more difficult to define, these test and measurement parameters are possibly even more important than the tangible items, as they are often mission-critical in nature.


For instance, certain elements of ISO’s functional safety standard, 26262:2018, are not as easy to measure or test:

In these examples, the concept referred to in Part 3 may be a nascent technology without any historical norms or specifications; while in part 7 “decommissioning” of a component such as a Li-ion battery may have different solutions, some of which may once again have no real test or measurement history. In this case, the batteries may follow the route of a second-life power supply, or alternatively be recycled for the raw material and components. Both of which would probably require novel tests and measurements.


Even more difficult to test and measure would be certain aspects of automated (self-driving) vehicle technologies:

With very few standards, regulations, or norms in place, it is incumbent on the authors of the requirements documents to define actionable tests and measures that will verify the performance and conformance of these systems.


Similarly, when it comes to testing and measuring the (cyber) security performance of E/E systems, there is very little generic historical data to draw on when compiling the requirements.


Thus test and measurement decisions have to be documented around several elements:

When compiling a comprehensive requirements document under these conditions the multi-party review meetings, described in section 6, will play a crucial part in determining the appropriate tests and measurements.

8. Define the Non-Functional Requirements

In order for manufacturers to deliver vehicles that meet customers’ expectations of performance while being user-friendly and reliable, it is important that when writing requirements the document or package should be able to capture not only the functionality but also the look and feel of the product.


It’s common for Non-functional requirements (NFRs) to take a back seat in requirement review sessions. Topics like scalability and security are rarely met with the same excitement or urgency as customer-facing features, yet they are critical to a development project’s success.


If a system fails to meet the specified NFRs in isolation it will rarely result in catastrophic failure. However, in E/E systems, for instance, continued development of a system running atop an architecture that is not maintainable or secure and doesn’t meet customer expectations will create compounding and far-reaching problems.


Consequently, it is important that, when compiling a requirements document, a list of NFRs is recorded as early as possible.


NFRs cover a broad range of qualitative concerns, therefore inclusions should be specific to the project at hand. The following list would be typical for a software development project:

Other more general NFRs would include:

Objective consideration of each item in the NFR list will significantly increase the chances of long term success.

9. Discard Duplicate or Contradictory Requirements

The automotive industry, being very technical by nature, is governed by a myriad of regulations, standards, norms and legislation that is unfortunately not always homogeneous across the Globe.


In recent times this has been further complicated with the entry of tech companies that have no automotive industry experience to draw on – often bringing with them somewhat more lenient consumer-device requirements and standards.


This poses a significant challenge to anyone compiling a requirements document: The manuscript needs to be comprehensive in order to cover all requirements, but without contradiction or duplication.


Thus it is important to decide on a strategy for addressing this issue early on when developing requirements.


While the strategy may differ by project, system or component it is important that the company adopt a standardized strategy taking into account the following:

As a control and advisory mechanism, one of the functions of the review meeting is to streamline the document to ensure the requirements are concise, unambiguous and not contradictory. As such, the review is expected to identify and correct any terminology or wording that may lead to subjective interpretation.

Download the Free Guide & Checklist

Booklet & printable checklist now available for Automotive professionals!

10. Avoid Ambiguity and Using Passive Voice

Requirements are living documents for a product that needs to actively meet the general safety and performance requirements on an on-going basis. Consequently, the requirement statements should be written in an unambiguous and consistent voice that reflects the active nature of the requirement.


By way of a hypothetical example:


The requirements for an electric fuel pump could call for the device to be tested at a consistent flow rate of 5L/min for 500 hours.


Worded like this, it could be interpreted to mean that this flow rate is an upper limit test, not continuous delivery.


Alternatively, the requirement could demand that the pump must be able to deliver a consistent flow rate of 5L/min for 500 hours.


This is better but could still sound like an upper limit that the pump won’t necessarily achieve.


A better wording for the requirement would be: The fuel pump must deliver a consistent flow rate of 5L/min for a minimum of 500 hours.


This is clear and concise, actively conveying the requirement with no latitude for interpretation or confusion.

11. Simplify the requirements process

Due to the growing complexity of components and systems, the requirements are similarly becoming more complicated to document, requiring more time-consuming effort while increasing the possibility of errors.


Introducing database-based requirements management tools can reduce time and improve accuracy and traceability. However, such tools must retain the basic functionality of a standard text-processing user interface while adding management and tracing functionality.


Designed to simplify the user interface, QVscribe harnesses Natural Language Processing to proactively check for compliance of the best requirements analysis tactics identified by associations such as INCOSE and leading industry experts.


Automated requirements analysis throughout the authoring process empowers engineering teams to build faster by identifying errors where they matter most and cost the least to fix – in the requirements.


QVscribe significantly simplifies the 10 Step process discussed above through:

Requirements Similarity Analysis

Assessment of requirements similarity to assist in eliminating redundant or contradictory requirements

Quality Indicators & Warnings

Detection, enumeration, and classification of all measurement units and noun phrases to help verify their correct use and location in the requirements.

Configurable Analysis Reports

Configurable PDF report generation, ready for sharing and printing. Reports can include full quality analysis, document summary, unit consistency results, analysis configurations, and recommendations.

Enterprise & Team Customizations

Centrally managed group-specific analysis configurations and trigger words for consistent requirements reviews across teams.

Requirements Exporting

Export requirements from Word documents into CSV formats compatible with management software.

Download the Free Guide & Checklist

Booklet & printable checklist now available for Automotive professionals!


Advanced search. (2017, August 29). Retrieved from https://www.iso.org/advanced-search/x/title/status/P,U/docNumber/26262/docPartNo/docType/0/langCode/ics/currentStage/true/searchAbstract/true/stage/stageDateStart/stageDateEnd/committee/sdg


Automotive – Certification & Assessment. (n.d.). Retrieved from https://www.sabs.co.za/Sectors-and-Services/Sectors/Auto/auto_ac.asp


Automotive CyberSecurity. (2019). Retrieved from http://sites.ieee.org/ocs-cssig/?page_id=736


Automotive Dictionary – automotive glossary of terms. (n.d.). Retrieved from http://www.automotivedictionary.org/


Edmunds. (2019). Retrieved from https://www.edmunds.com/glossary/#E


Gould, L. S. (2017, February 1). Making the Analysis of Requirements Documents Easier. Retrieved from https://www.adandp.media/articles/making-the-analysis-of-requirements-documents-easier


How to Write an Exceptionally Clear Requirements Document. (2019, June 17). Retrieved from https://qracorp.com/write-clear-requirements-document/


IEC Quality Assessment System for Electronic Components (IECQ System). (2013). IECQ PUBLICATION03(3). Retrieved from https://www.iec.ch/webstore/freepubs/iecq/iecq03-3-2{ed1.0}en.pdf


ISO/TS 16949:2009. (2016, December 1). Retrieved from https://www.iso.org/standard/52844.html


ISO/TS 16949:2009 Technical Specification In-Depth. (2010). Retrieved from http://static1.squarespace.com/static/5667015fa2bab8c35c555338/5669b0a0c03355b914a05833/5669b095c03355b914a056d9/1449767061636/ISO.TS-16949_2009-Technical-Spec-In-Depth-4.16.10.pdf?format=original


Kelechava, B. (2019, August 15). ISO 26262:2018 – Road Vehicles Functional Safety Standards – ANSI Blog. Retrieved from https://blog.ansi.org/2019/02/iso-26262-2018-road-vehicle-functional-safety/#gref


Naden, C. (2018, December 19). Keeping safe on the roads: series of standards for vehicle electronics functional safety just updated. Retrieved from https://www.iso.org/news/ref2358.html


Nason, T. (2018, August). Driving quality through Non-Functional Requirements. Retrieved from https://www.wiliam.com.au/wiliam-blog/driving-quality-through-non-functional-requirements


PAS 1885:2018. (n.d.). Retrieved from https://shop.bsigroup.com/ProductDetail/?pid=000000000030365446&_ga=2.267667464.704902458.1545217114-2008390051.1545217114


Quality Glossary – S: ASQ. (n.d.). Retrieved from https://asq.org/quality-resources/quality-glossary/s


Quality Management Systems. (2015). Retrieved from https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:en


QVscribe by QRA Corp – Analyze Requirements Documents in Seconds. (n.d.). Retrieved from https://qracorp.com/qvscribe/

Road Vehicles – Vehicle to Grid Communication Interface. (2019). Retrieved from https://www.iso.org/obp/ui/fr/#iso:std:iso:15118:-1:ed-2:v1:en


Smyth, D. (2019, August 8). ISO 9000 Document Codes: How to Label Your Documents. Retrieved from https://bizfluent.com/how-7223211-iso-document-codes–label-documents.html


Supplier Quality Assurance Manual. (2019). Retrieved from https://www.volvogroup.com/content/dam/volvo/volvo-group/markets/global/en-en/suppliers/our-supplier-requirements/Supplier-Quality-Assurance-Manual-2019-Volvo-Group.pdf


Supplier Requirements Manual. (2018, May). Retrieved from https://www.faurecia.com/sites/groupe/files/paradocfournisseurs/faurecia_supplier_requirements_manual_1.pdf


Transport, D. for. (2018, December 19). New cyber security standard for self-driving vehicles. Retrieved from https://www.gov.uk/government/news/new-cyber-security-standard-for-self-driving-vehicles


TS 16949 Clause 4.2.3 – How many Procedures are Required? (2011, February). Retrieved from https://elsmar.com/elsmarqualityforum/threads/ts-16949-clause-4-2-3-how-many-procedures-are-required.46245/


UN, United Nations, UN Treaties, Treaties. (n.d.). Retrieved from https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&mtdsg_no=XI-B-16-78&chapter=11&clang=_en


Van Der Weel, H. (2014, September). Non Functional Requirements: A car analogy. Retrieved from http://bpmea.blogspot.com/2014/09/non-functional-requirements-car-analogy.html


Weber, M., & Weisbrod, J. (1970, January 1). Requirements engineering in automotive development-experiences and challenges – Semantic Scholar. Retrieved from https://www.semanticscholar.org/paper/Requirements-engineering-in-automotive-and-Weber-Weisbrod/08991710e3ed691e787af6a8aad3776015d58cdb


Weber, M., & Weisbrod, J. (2003). Requirements Engineering in Automotive Development: Experiences and Challenges. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=


What is ISO 9001:2015 – Quality management systems? (n.d.). Retrieved from https://asq.org/quality-resources/iso-9001

wikiHow. (2019, June 28). How to Write a Requirements Document. Retrieved from https://m.wikihow.com/Write-a-Requirements-Document