INTRODUCTION

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.

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:

• A cover page
• Section headings
• Essential guidelines for the content in each section
• A brief explanation of the version (change) control system used to govern updates made to the document.

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:

• A clear and concise explanation detailing the design rationale and/ or design decisions
• Product/ system specifications
• Regulatory requirements
• In E/E systems (cyber)security needs to be taken into consideration
• Drawings, images and sketches
• Testing requirements
• Budget constraints/ Product costing targets
• Expected timeline with key milestones
• Where applicable for each working state– initial, defined and released
• Final due dates for key events such as sample submissions and SoP
• Safe and environmentally friendly after-life disposal plan

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:

•  Design brief
•  Standards governing the design, engineering and testing, production and quality management of the product or system
• Where applicable, company policies guiding E/E systems security, or as they become available standards such as the BIS’ PAS 1885
• Product specifications
• Engineering drawings
• Failure Mode Effects Analysis (FMEA) records or equivalent Failure Analysis documentation

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:

• Documents must be approved by a relevant team before initial issue to ensure the information is accurate
• Documents have to be reviewed, updated and re-approved in a controlled process
• Each document must note the revision number and status, as well as identification of what changes were made in the last revision
• Current versions of these documents must be available at their points of use, and users must be notified of updates
• Documents are required to remain legible and readily identifiable. This normally involves a reference code or numbering system and a standard document format
• Any documents of external origin must be identified, managed and controlled as such
• Obsolete documents have to be removed from circulation and easily identifiable as different from the current approved versions

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)

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:

• So an Electric Vehicle (EV) can be classified as electrified, but an electrified Hybrid Electric Vehicle should not be described as an EV, as laid 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.

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

• ISO
• SAE
• UN
• DIN
• VDA
• IECQ

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

• The Automotive Dictionary
• Edmunds’ Alphabetical Glossary of Automotive 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:

• Kick-Off Review HW/SW
• Planning Review
• Requirements Review
• Initial Design Review
• Final Design Review
• PPAP Review

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:

• Using clear, unambiguous language
• Never using colloquial or internal terminology
• Enforcing standard automotive terms
• Recording all relevant standards, norms and conventions
• Conducting thorough multi-party review meetings at critical points

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.

7. ALL REQUIREMENTS MUST BE MEASURABLE AND TESTABLE

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:

• Specifications
• Drawings
• Norms
• Regulatory requirements
• Functional safety requirements
• Budgets and costing
• Quality targets
• FMEA results
• Overall timing and key milestones

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:

• Part 3 describes the “Concept Phase,” detailing processes that would come early on in assuring the functional safety of road vehicles. It features item definition, hazard analysis and risk assessment, and the functional safety concept.
• Part 7 deals with the “Production, Operation, Service and Decommissioning” addressing the production, operation, service, and decommissioning stages of the automotive safety lifecycle, including related planning activities.

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:

• What are the edge cases (Rarely encountered driving scenarios) that need to be evaluated?
• What redundant systems are needed?
• What form of testing should be carried out?
  • Machine in the Loop
  • Driver in the Loop
  • Virtual simulation
  • Closed-circuit testing
  • Road testing
• What mileage should be covered?
• In what environment and traffic conditions?
• How would success be measured
  • Mileage covered
  • Number of disengagements

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:

• What are the attack surfaces?
• What tests should be used?
  • Bounty/ white hat hacking
  • Internal system security audits
  • FMEA
  • Predictive Failure Analysis
  •  Deep packet inspections
  • System entropy monitoring.
• What measurements could be made to determine the success or failure of the systems?

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:

• Security
• Performance
• Scalability
• Extensibility
• Maintainability
• Testability
• Reliability
• Interoperability
• Deployment
• Disaster recovery
• Usability
• Accessibility
• Compatibility

Other more general NFRs would include:

• Accessibility – when developing interior solutions.
• Aesthetics – obviously important for any components with a visual impact.
• Human Machine Interface – important in systems such as infotainment or Advanced Driver Assist Systems that make use of alerts to warn drivers.
• Driving range – of particular importance for EVs.
• Emissions conformity – this applies to ICE-powered and hybrid vehicles.
• User Experience – how easy is it for consumers to use the systems?

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:

• The same standards, regulations or norms may appear in several places in the requirements: For instance an E/E requirements document may 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 requirements 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 Validation) as the equivalent requirement – this can lead to contradiction and even duplication, and is best resolved by studying the requirements and selecting a single standard.
• Regulations may also vary by region, with emissions standards, for instance, in Europe differing from those in North America, Japan or China. The requirements need to define very clearly the most concise yet encompassing strategy to satisfy the demands.
• It is also possible that material specifications may vary from region to region. So, a grade of steel specified for a non-critical part by the manufacturer may only be available in that region, whereas a supplier based in a different area would require a slightly different specification to meet availability. It is more productive to spend time optimizing the requirements than it would be to have a bloated and contradictory requirement document.

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.

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

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

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.

Learn how QVscribe can transform your design process.

Download a PDF copy of this guide.

REFERENCES

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

IEC Quality Assessment System for Electronic Components (IECQ System). (2013). IECQ PUBLICATION, 03(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/how7223211-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/SupplierQuality-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.blog-spot.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/08991710e3ed691e787af6a8aad3776015d58

Weber, M., & Weisbrod, J. (2003). Requirements Engineering in Automotive Development: Experiences and Challenges. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/downloaddoi=10.1.1.98.9103&rep=rep1&type=pdf

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