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.
INTRODUCTION 1. REVIEW THE CONTENTS OF THE REQUIREMENTS TEMPLATE

As the 4 ACES (Automated Driving, Connectivity, Electrification and Shared mobility) change the face of the Developing an automotive requirements document These standardized sections, or “boilerplates” as
automotive industry, the complexity of electronic and electrical systems (E/E) is increasing exponentially. requires a multi-faceted approach that includes not they are often referred to, are useful to promote con-
Currently, about forty percent of component-spend in high-end models can be ascribed to electric and only the tangible word-based requirements but also sistency across projects. These are the sections that
electronic systems, with that cost set to continue to grow. sketches and technical drawings, and standards and tend to remain little changed from project to proj-
engineering norms, to contextualize the information. ect, and from team to team within a company, only
At the same time, driven by customer demands for a heightened User Experience (UX) and inconsistent global evolving slowly to meet changes in methodology and
legislation, manufacturers are forced to engineer an increasing number of novel variations of the base-spec- To achieve the desired quality of information, and lessons learned.
ification. Consequently, the complexity of compiling requirements documents outlining the specifications, save time, it is worthwhile to develop an updatable
processes and procedures required to produce automotive components and systems continues to grow. “living” manuscript from a trusted requirements This provides a stable platform allowing for continu-
document template. ous development and refinement of the manuscript
While requirements documents are not new to the automotive industry, the rapid rate of change brought about to best meet the evolution of the company’s business
by the introduction of sophisticated automated and electrified systems means that drawing up a requirements A good requirements document template should as well as accommodating emerging technologies.
document is now no longer a best-in-class practice, but rather, critical to ensuring the timeous delivery have as a minimum:
of a cost-effective product that meets customer’s expectations, and safety and emissions requirements. In compiling the requirements document the follow-
• A cover page ing elements have to be addressed:
• Section headings
• Essential guidelines for the content in each • A clear and concise explanation detailing the
section design rationale and/ or design decisions
• A brief explanation of the version (change) • Product/ system specifications
control system used to govern updates made • Regulatory requirements
to the document. • In E/E systems (cyber)security needs to be
taken into consideration
It is also critical that the requirements document is • Drawings, images and sketches
“word processor friendly.” Team members are more • Testing requirements
likely to embrace the document as a tool if it is intuitive • Budget constraints/ Product costing targets
and easy to implement and maintain. • Expected timeline with key milestones
• Where applicable for each working state
The template should also include standardized sec- – initial, defined and released
tions covering recurring topics such as terminology, • Final due dates for key events such as
formatting and traceability standards, and any inter- sample submissions and SoP
nal guidelines the organization follows in document- • Safe and environmentally friendly after-life
ing and managing the requirements documentation. disposal plan

qracorp.com 3 qracorp.com 4
 2. DEVELOP A CONCISE FILING SYSTEM

It is equally important that the requirements As the requirements document develops it is natu- Limiting access to writing and editing these
document captures the intangible engineering and ral that changes and updates are made – It is there- documents is important. The requirements document
design requirements that specialists such as stylists fore important that any of these changes can be controller or administrator will hold this access with
and product planners specify. Consequently, it is recalled and its history reviewed. In order to do this, the authority to initiate reviews, make changes to the
important that the look, feel, and perspective of the a well-controlled, long term filing system is crucial to document or file and resubmit it for approval.
original resources are retained, including: ensuring long-term traceability and redundancy.
The approval process may include the input of a single
• Design brief The ISO 9001 filing standards for documents offer individual or a team who needs to review from
• Standards governing the design, engineering and a well-proven system that requires the following multiple angles. Reviewers should include team mem-
testing, production and quality management of actions: bers who most frequently use the document, as they
the product or system will have the best input on what has changed since
• ISO/TS 16949 • Documents must be approved by a relevant team the last revision.
• DIN before initial issue to ensure the information
• SAE is accurate When choosing a document control numbering
• ISO 26262 • Documents have to be reviewed, updated and system it is advisable to stick to ISO guidelines for
• IECQ re-approved in a controlled process conformity and also to standardize systems across
• Where applicable, company policies guiding E/E • Each document must note the revision number the company. Thus the requirements document could
systems security, or as they become available and status, as well as identification of what be identified by a prefix such as SOP for a standard
standards such as the BIS’ PAS 1885 changes were made in the last revision operating procedure, followed by REQ to describe
• Product specifications • Current versions of these documents must be the document.
• Engineering drawings available at their points of use, and users must
• Failure Mode Effects Analysis (FMEA) records or be notified of updates Numbering can be done either sequentially,
equivalent Failure Analysis documentation • Documents are required to remain legible and as created, or by using a numbering system in which
readily identifiable. This normally involves a ref- each digit represents something. For example, SOP/
While there is no standard that governs the require- erence code or numbering system and a standard REQ-1007 could mean the seventh requirements
ments document’s layout, tracking, and change con- document format document within the standard operating procedure
trol per se, the process will obviously have to meet • Any documents of external origin must be created by the department designated as 1000.
all relevant quality management standards, such as identified, managed and controlled as such
ISO 9001 and ISO/TS 16949, to meet the company’s • Obsolete documents have to be removed from Document labels should also include an easily
obligations. circulation and easily identifiable as different understood title, as well as an indication of the
from the current approved versions most recent review and approval date. Normally the
creator(s), editor(s) and approval team are also
Adhering to these procedures will ensure that included as a reference for any users that have
employees are always accessing the most current, questions or need to submit changes.
approved version of the requirements document while
being able to track and review historical information.

qracorp.com 5 qracorp.com 6
3. MAINTAIN A PAPER TRAIL OF CHANGES 4. USE INDUSTRY-SPECIFIC TERMS

As the project advances through development it is 1. Approve the adequacy of documents prior to As the requirements document is meant to be The following standards organizations all have
likely that new requirements will be added and existing issue (Including drawings and sketches) a working document that spans multiple divisions vocabulary specific to their requirements:
requirements will be improved upon. A change 2. Review, update as necessary, and re-approve within an organization as well as being circulated
control system should be in place to capture these documents (Including drawings and sketches) to external suppliers, it is critical that there can be • ISO
changes. – Provide suitable identification of any obsolete, no confusion over what is intended in the manuscript. • SAE
revised or superseded documents retained for • UN
An audit trail should be maintained for all changes to any purpose When dealing with regulatory requirements it’s • DIN
requirements to ensure that the methods and reason 3. Identify changes to documents as well as important to use industry-specific words and terms. • VDA
for the changes are available for review and even reg- identify their current revision status (Including This will be crucial for success when being audited as • IECQ
ulatory inspection. drawings and sketches) – Use a single system, well as ensuring contextual uniformity of all documents
date, letter, number, but not multiple methods contained in files relating to the requirements If the team is unsure of the correct terminology there
Documenting clear reasons for the requirement 4. Make relevant versions of applicable documents documents. are several online references that can be consulted
change can also be helpful later in the engineering (Including drawings and sketches) available at for the applicable industry-specific terms:
process and can potentially reduce iterations in the points of use In the often highly technical and complex automotive
development of a product or system. 5. Identify documents of external origin and environment it is not uncommon for terms to, • The Automotive Dictionary
control their distribution (Including drawings and incorrectly, be used interchangeably: (http://www.automotivedictionary.org/)
By adhering to the following five steps in ISO/TS sketches) • Edmunds’ Alphabetical Glossary of Automotive
16949, 4.2.3 (Control of documents,) the document 6. Prevent the unintended use of obsolete • So an Electric Vehicle (EV) can be classified Terms (https://www.edmunds.com/glossary/)
change-control process is both simplified and documents, and apply suitable identification as electrified, but an electrified Hybrid Electric
standardized: to these documents if they are kept for any Vehicle should not be described as an EV, as laid
purpose (Including drawings and sketches) out in the SAE’s Hybrid Electric Vehicle (HEV) &
Electric Vehicle (EV) Terminology J1715_200802
• Similarly, the terms of reference for the levels of
driving automation is unequivocally the SAE’s
J3016’s that defines six levels of automation
for on-road motor vehicles

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.

qracorp.com 7 qracorp.com 8
5. ACCOMMODATE EVOLVING MANUFACTURER/SUPPLIER REQUIREMENTS 6. WRITE THE REQUIREMENTS FOR A UNIVERSAL AUDIENCE

In the past there has mostly been a very clear distinction There are typically six Joint Reviews in a normal hard- As suppliers, particularly technology companies that Furthermore, document change control and the
between manufacturers’ and suppliers’ functions and ware/ software (HW/ SW) development project: are less familiar with the stringent automotive stan- underlying filing system, as outlined in sections 2
responsibilities in developing and producing parts; how- dards and requirements, play an increasingly pivotal and 3 above, must be strictly adhered to, and even
ever, the increasing complexity of modern systems has • Kick-Off Review HW/SW role in vehicle engineering manufacturers need to be audited from time to time.
led to these roles being less clearly defined. • Planning Review particularly vigilant to make sure all documentation
• Requirements Review is understandable and actionable by all parties
Thus, the respective roles of manufacturer and supplier • Initial Design Review – internally and within supplier organizations.
in drawing up the user requirement specification, tradi- • Final Design Review
tionally compiled by the manufacturer, and the system • PPAP Review This can be facilitated through:
requirement specification developed by the supplier is
no longer that clear-cut. While this is common in complex E/E systems • Using clear, unambiguous language
it is equally relevant and actionable for less intricate, • Never using colloquial or internal terminology
In situations where manufacturers are exploring unde- traditional mechanical components. • Enforcing standard automotive terms
fined nascent technologies, they will be required to out- • Recording all relevant standards, norms
line much of the specification document features in as and conventions
much detail as possible by specifying system specifica- • Conducting thorough multi-party review
tion solutions instead of only affirming requirements. meetings at critical points

This is particularly true for systems that rely on both

software and hardware. In this situation manufacturers
7. ALL REQUIREMENTS MUST BE MEASURABLE AND TESTABLE
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. As with any management or planning system, require- However, in an environment of increasing technolog-
ments must be measurable and testable against ical innovation, there are now also intangible require-
One mechanism that facilitates this shift in roles is the set values, milestones and performance targets. ments that need to be measured and tested. While
multi-party review meeting, which when conducted at being more difficult to define, these test and mea-
appropriate stages of the project allows for a flexible These include tangible requirements, which are surement parameters are possibly even more import-
approach to the traditional manufacturer/ supplier roles. possibly a little easier to measure and test, such as: ant than the tangible items, as they are often mis-
sion-critical in nature.
• Specifications
• Drawings For instance, certain elements of ISO’s functional
• Norms safety standard, 26262:2018, are not as easy
• Regulatory requirements to measure or test:
• Functional safety requirements
• Budgets and costing • Part 3 describes the “Concept Phase,” detailing
• Quality targets processes that would come early on in assuring the
• FMEA results functional safety of road vehicles. It features item
• Overall timing and key milestones definition, hazard analysis and risk assessment,
and the functional safety concept.

qracorp.com 9 qracorp.com 10
 8. DEFINE THE NON-FUNCTIONAL REQUIREMENTS

• Part 7 deals with the “Production, Operation, Similarly, when it comes to testing and measuring the
Service and Decommissioning” addressing the (cyber) security performance of E/E systems, there
In order for manufacturers to deliver vehicles that NFRs cover a broad range of qualitative concerns,
production, operation, service, and decommis- is very little generic historical data to draw on when
meet customers’ expectations of performance while therefore inclusions should be specific to the project at
sioning stages of the automotive safety lifecycle, compiling the requirements.
being user-friendly and reliable, it is important that hand. The following list would be typical for a software
including related planning activities.
when writing requirements the document or package development project:
Thus test and measurement decisions have to be
should be able to capture not only the functionality
In these examples, the concept referred to in Part 3 documented around several elements:
but also the look and feel of the product. • Security
may be a nascent technology without any historical
• Performance
norms or specifications; while in part 7 “decommis- • What are the attack surfaces?
It’s common for Non-functional requirements (NFRs) • Scalability
sioning” of a component such as a Li-ion battery • What tests should be used
to take a back seat in requirement review sessions. • Extensibility
may have different solutions, some of which may • Bounty/ white hat hacking
Topics like scalability and security are rarely met with • Maintainability
once again have no real test or measurement • Internal system security audits
the same excitement or urgency as customer-facing • Testability
history. In this case, the batteries may follow the • FMEA
features, yet they are critical to a development • Reliability
route of a second-life power supply, or alternatively • Predictive Failure Analysis
project’s success. • Interoperability
be recycled for the raw material and components. • Deep packet inspections
• Deployment
Both of which would probably require novel tests and • System entropy monitoring.
If a system fails to meet the specified NFRs in isolation • Disaster recovery
measurements. • What measurements could be made to determine
it will rarely result in catastrophic failure. However, in • Usability
the success or failure of the systems
E/E systems, for instance, continued development • Accessibility
Even more difficult to test and measure would be
of a system running atop an architecture that • Compatibility
certain aspects of automated (self-driving) vehicle When compiling a comprehensive requirements
is not maintainable or secure and doesn’t meet
technologies: document under these conditions the multi-party
customer expectations will create compounding and Other more general NFRs would include:
review meetings, described in section 6, will play
far-reaching problems.
• What are the edge cases (Rarely encountered a crucial part in determining the appropriate tests
• Accessibility – when developing interior solutions
driving scenarios) that need to be evaluated? and measurements.
Consequently, it is important that, when compiling a • Aesthetics – obviously important for any
• What redundant systems are needed?
requirements document, a list of NFRs is recorded as components with a visual impact
• What form of testing should be carried out?
early as possible. • Human Machine Interface – important in systems
• Machine in the Loop
such as infotainment or Advanced Driver Assist
• Driver in the Loop
Systems that make use of alerts to warn drivers
• Virtual simulation
• Driving range – of particular importance for EVs
• Closed-circuit testing
• Emissions conformity – this applies to
• Road testing
ICE-powered and hybrid vehicles
• What mileage should be covered?
• User Experience – how easy is it for consumers
• In what environment and traffic conditions?
to use the systems?
• How would success be measured
• Mileage covered
Objective consideration of each item in the NFR list
• Number of disengagements
will significantly increase the chances of long term
success.
With very few standards, regulations, or norms in
place, it is incumbent on the authors of the require-
ments documents to define actionable tests and
measures that will verify the performance and
conformance of these systems.

qracorp.com 11 qracorp.com 10
9. DISCARD DUPLICATE OR CONTRADICTORY REQUIREMENTS 10. AVOID AMBIGUITY AND USING PASSIVE VOICE

The automotive industry, being very technical by nature, Validation) as the equivalent requirement – this can Requirements are living documents for a product Alternatively, the requirement could demand that the
is governed by a myriad of regulations, standards, norms lead to contradiction and even duplication, and is that needs to actively meet the general safety and pump must be able to deliver a consistent flow rate
and legislation that is unfortunately not always homoge- best resolved by studying the requirements and performance requirements on an on-going basis. of 5L/min for 500 hours.
neous across the Globe. selecting a single standard. Consequently, the requirement statements should be
• Regulations may also vary by region, with emis- written in an unambiguous and consistent voice that This is better but could still sound like an upper limit
In recent times this has been further complicated with sions standards, for instance, in Europe differing reflects the active nature of the requirement. that the pump won’t necessarily achieve.
the entry of tech companies that have no automotive from those in North America, Japan or China. The
industry experience to draw on – often bringing with requirements need to define very clearly the most By way of a hypothetical example: A better wording for the requirement would be: The
them somewhat more lenient consumer-device require- concise yet encompassing strategy to satisfy the fuel pump must deliver a consistent flow rate of 5L/
ments and standards. demands. The requirements for an electric fuel pump could call min for a minimum of 500 hours.
• It is also possible that material specifications may for the device to be tested at a consistent flow rate of
This poses a significant challenge to anyone compiling vary from region to region. So, a grade of steel 5L/min for 500 hours. This is clear and concise, actively conveying the
a requirements document: The manuscript needs to be specified for a non-critical part by the manufac- requirement with no latitude for interpretation
comprehensive in order to cover all requirements, but turer may only be available in that region, whereas Worded like this, it could be interpreted to mean that or confusion.
without contradiction or duplication. a supplier based in a different area would require a this flow rate is an upper limit test, not continuous
slightly different specification to meet availability. delivery.
Thus it is important to decide on a strategy for address- It is more productive to spend time optimizing the
ing this issue early on when developing requirements. requirements than it would be to have a bloated
and contradictory requirements document.
While the strategy may differ by project, system or com-
ponent it is important that the company adopt a stan- As a control and advisory mechanism, one of the func-
dardized strategy taking into account the following: tions of the review meeting is to streamline the document
to ensure the requirements are concise, unambiguous
• The same standards, regulations or norms may and not contradictory. As such, the review is expected
appear in several places in the requirements: For to identify and correct any terminology or wording that
instance an E/E requirements document may may lead to subjective interpretation.
require a HW developer to apply ISO 26262, while
at the same time demanding the same from a SW
supplier in another section of the manuscript –
wherever possible it is better to list all regulations,
standards, norms and specifications in respective
“boilerplate” sections, as described in Section 1.
• Similar standards set by different organizations, for
instance, ISO or SAE, may be quoted as require-
ments by different team members. So, it could be
that the manufacturer in its requirements, calls for
ISO26262 whereas a supplier may cite SAE’s J2516
(Embedded Software Development Lifecycle)
and J2734 (Embedded Software Verification and

qracorp.com 11 qracorp.com 10
11. SIMPLIFY THE REQUIREMENTS PROCESS

Due to the growing complexity of components and Detection, enumeration, and classification of all
systems, the requirements are similarly becoming measurement units and noun phrases to help verify
more complicated to document, requiring more their correct use and location in the requirements.
time-consuming effort while increasing the possibility
of errors. Configurable Analysis Reports
Configurable PDF report generation, ready for sharing
Introducing database-based requirements manage- and printing. Reports can include full quality analysis,
ment tools can reduce time and improve accuracy document summary, unit consistency results, analysis
and traceability. However, such tools must retain configurations, and recommendations.
the basic functionality of a standard text-processing
user interface while adding management and tracing Enterprise & Team Customizations
functionality. Centrally managed group-specific analysis configura-
tions and trigger words for consistent requirements
Designed to simplify the user interface, QVscribe reviews across teams.
harnesses Natural Language Processing to proac-
tively check for compliance of the best require- Requirements Exporting
ments analysis tactics identified by associations such Export requirements from Word documents into CSV
as INCOSE and leading industry experts. formats compatible with management software.

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

• Imperatives
• Negative Imperatives
• Optional Words
• Vague Language
• Continuances
• Directives
• Universal Quantifiers
• Terminology & Unit Consistency Analysis

qracorp.com 11
 REFERENCES

Advanced search. (2017, August 29). Retrieved from https://www. QVscribe by QRA Corp – Analyze Requirements Documents in
iso.org/advanced-search/x/title/status/P,U/docNumber/26262/ Seconds. (n.d.). Retrieved from https://qracorp.com/qvscribe/
docPartNo/docType/0/langCode/ics/currentStage/true/search-
Abstract/true/stage/stageDateStart/stageDateEnd/committee/ Road Vehicles – Vehicle to Grid Communication Interface.
sdg (2019). Retrieved from https://www.iso.org/obp/ui/
fr/#iso:std:iso:15118:-1:ed-2:v1:en
Automotive – Certification & Assessment. (n.d.). Retrieved from
https://www.sabs.co.za/Sectors-and-Services/Sectors/Auto/ Smyth, D. (2019, August 8). ISO 9000 Document Codes: How to
auto_ac.asp Label Your Documents. Retrieved from https://bizfluent.com/how-
7223211-iso-document-codes–label-documents.html
Automotive CyberSecurity. (2019). Retrieved from http://sites.ieee.
org/ocs-cssig/?page_id=736 Supplier Quality Assurance Manual. (2019). Retrieved from https://
www.volvogroup.com/content/dam/volvo/volvo-group/markets/
Automotive Dictionary – automotive glossary of terms. (n.d.). global/en-en/suppliers/our-supplier-requirements/Supplier-
Retrieved from http://www.automotivedictionary.org/ Quality-Assurance-Manual-2019-Volvo-Group.pdf

Edmunds. (2019). Retrieved from https://www.edmunds.com/ Supplier Requirements Manual. (2018, May). Retrieved from
glossary/#E https://www.faurecia.com/sites/groupe/files/paradocfournisseurs/
faurecia_supplier_requirements_manual_1.pdf
Gould, L. S. (2017, February 1). Making the Analysis
of Requirements Documents Easier. Retrieved Transport, D. for. (2018, December 19). New cyber secu-
from https://www.adandp.media/articles/ rity standard for self-driving vehicles. Retrieved
making-the-analysis-of-requirements-documents-easier from https://www.gov.uk/government/news/
new-cyber-security-standard-for-self-driving-vehicles
How to Write an Exceptionally Clear Requirements Document.
(2019, June 17). Retrieved from https://qracorp.com/ TS 16949 Clause 4.2.3 – How many Procedures
write-clear-requirements-document/ are Required? (2011, February). Retrieved from
https://elsmar.com/elsmarqualityforum/threads/
IEC Quality Assessment System for Electronic Components (IECQ ts-16949-clause-4-2-3-how-many-procedures-are-required.46245/
System). (2013). IECQ PUBLICATION, 03(3). Retrieved from
https://www.iec.ch/webstore/freepubs/iecq/iecq03-3-2{ed1.0} UN, United Nations, UN Treaties, Treaties. (n.d.).
en.pdf Retrieved from https://treaties.un.org/Pages/ViewDetails.
aspx?src=TREATY&mtdsg_no=XI-B-16-78&chapter=11&clang=_en
ISO/TS 16949:2009. (2016, December 1). Retrieved from https://
www.iso.org/standard/52844.html Van Der Weel, H. (2014, September). Non Functional
Requirements: A car analogy. Retrieved from http://bpmea.blog-
ISO/TS 16949:2009 Technical Specification spot.com/2014/09/non-functional-requirements-car-analogy.html
In-Depth. (2010). Retrieved from http://static1.
squarespace.com/static/5667015fa2bab8c- Weber, M., & Weisbrod, J. (1970, January 1). Requirements engi-
35c555338/5669b0a0c03355b914a05833/5669b095c- neering in automotive development-experiences and challenges
03355b914a056d9/1449767061636/ISO.TS-16949_2009- – Semantic Scholar. Retrieved from https://www.semanticscholar.
Technical-Spec-In-Depth-4.16.10.pdf?format=original org/paper/Requirements-engineering-in-automotive-and-
Weber-Weisbrod/08991710e3ed691e787af6a8aad3776015d58
Kelechava, B. (2019, August 15). ISO 26262:2018 – cdb
Road Vehicles Functional Safety Standards – ANSI
Blog. Retrieved from https://blog.ansi.org/2019/02/ Weber, M., & Weisbrod, J. (2003). Requirements Engineering
iso-26262-2018-road-vehicle-functional-safety/#gref in Automotive Development: Experiences and Challenges.
Retrieved from http://citeseerx.ist.psu.edu/viewdoc/
Naden, C. (2018, December 19). Keeping safe on the roads: series download?doi=10.1.1.98.9103&rep=rep1&type=pdf
of standards for vehicle electronics functional safety just updated.
Retrieved from https://www.iso.org/news/ref2358.html What is ISO 9001:2015 – Quality management systems? (n.d.).
Retrieved from https://asq.org/quality-resources/iso-9001
Nason, T. (2018, August). Driving quality through Non-Functional
Requirements. Retrieved from https://www.wiliam.com.au/ wikiHow. (2019, June 28). How to Write a Requirements
wiliam-blog/driving-quality-through-non-functional-requirements Document. Retrieved from https://m.wikihow.com/
Write-a-Requirements-Document
PAS 1885:2018. (n.d.). Retrieved from https://shop.bsig-
roup.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

qracorp.com

version 1
 Automotive
Requirements Checklist

1) Review the Contents of the Requirements Template

2) Develop a Concise Filing System

3) Maintain a Paper Trail of Changes

4) Use Industry-Specific Terms

5) Accommodate Evolving Manufacturer/Supplier Requirements

6) Write the Requirements for a Universal Audience

7) All requirements Must be Measurable and Testable

8) Define the Non-Functional Requirements

9) Discard Duplicate or Contradictory Requirements

10) Avoid Ambiguity and Using Passive Voice

11) Simplify the requirements process

qracorp.com