Automotive Requirements Guide & Checklist: The 10 Essentials for Writing a Clear Requirements Document
EXECUTIVE SUMMARY
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.
Learn how QVscribe can transform your design process.
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.