My father served in WWII. He was part of the United States Army Air Force, specifically the 15th Expeditionary Mobility Task Force stationed in the Mediterranean Theater of Operations. In other words, he was in the US Air Force before it was the Air Force, stationed in Tunisia and later in Italy. He was part of the repair depot with the mission to get damaged aircraft back up in the air and flying. Using spare parts, cannibalized parts from other aircraft, bailing wire and string, they got aircraft back in the air.
He safely returned from the war, married Mom, had a handful of baby boomers, including me. However, the order to get stuff repaired or built with spare parts, bailing wire, and string, was seemingly never countermanded. Washers and dryers were repaired with spare parts. The family sedan was involved in an accident. Cannibalizing from the junk yard soon resulted in a newish car.
Dad was a stereotypical Scotsman, cheap, stingy, or frugal, choose your adjective—he had a limited set of tools. Buying new tools, or appropriate tools for a specific project, apparently was never in the budget. Dad did most of his damage with a couple of screwdrivers, a hammer, a hand saw, a drill, and a motley assortment of wrenches.
Which gets us to the point of all this—let’s countermand the order to create requirements in standalone, old-fashioned authoring tools such as Word or Excel. New order—all requirements should be authored, related, and traced in a specific Requirements Management (RM) application, built on a flexible, scalable, and upgradeable PLM Platform.
All too often we use the tools we are most comfortable with, the tool that seems to fit our hand best, like our screwdriver with the worn wooden handle. We’re talking about the old standbys of Word and Excel. And in some cases, a standalone RM system, outside of the PLM system. Again, you need to create your requirements in a system like Requirements Engineering, where requirements can be bi-directionally traced between individual requirements and various design artifacts across all design domains and their lifecycles (system, mechanical, electrical, software, and documentation).
You have created Marketing Requirements Documents (MRDs), Business Requirements Documents (BRDs), Functional Specifications, and System Requirements Specifications (SRSs). You have authored them in silos and jealously guard them as your “single source of truth,” while sending them via email to various stakeholders for further input and approval outside of any formal process, keeping track of who you have contacted, which have reviewed, and who has signed off—within that monolithic Excel file. Then something changes, and if you are an Agile house, things are changing often and quickly. Whose single source of truth needs to be changed and what else has been affected by the change? How are changes propagated throughout the various documents? Or, how are the changes propagated into and out of the standalone RM system outside of the PLM ecosystem?
Do you ever wonder where that requirement that you wrote for another project can be found now? It was written for a project a couple of years ago and would be perfect to use again—if only it could be found. Which project was it and where is the document now?
Aras Requirements Engineering allows you to express requirements content in various forms―text, reusable content structures (ex: paragraphs, graphics, tables, etc.), and shareable parameters. It also has distinct advantages over traditional non-PLM centric tools stemming from the configuration management functionality of the Aras PLM platform, which include:
- Versioning (engineering V curve)
- Verification (engineering V curve)
- Traceability between requirements
- Traceability from/to requirements and items such as parts, assemblies, external links, multimedia, etc.
- Impact Analysis (on the non-requirement items)
- Collaboration (configuration controlled)
- Change Management, Workflow, Lifecycle
Requirements Engineering enables traceability within the context of the PLM digital thread. The Data Model approach of RE not only enables defining, managing, and maintaining requirements across the product lifecycle, but also allows capturing and managing the relationships between the requirements. A data model approach supports traceability across an organization’s application eco-system, connecting requirements from multi-sources: text, structured data, parameters, and models; providing a competitive advantage in reducing product failures such as:
- excessive product cost
- lost time to market
- products shipped without meeting all requirements
- excessive time in tracing requirements
- challenges in meeting regulatory or product quality
Requirements Engineering from Aras can help you with a modern tool that enables:
- faster time to market with less rework
- reduction in legacy systems technical debt
- creation and leveraging of a digital thread though Concept Development, Technical Development, Requirements Development, Specifications, Analysis & Design, Fabrication, Testing, Verification, Validation, and Operations/Support
- timely and accurate compliance reporting
Let’s start today, and look outside of our old tool box, full of inefficient tools. Let’s stop creating static, one-off, siloed documents that are resistant to change, reuse, and are untraceable. Instead let’s use a modern tool, Aras’ Requirements Engineering, built on a flexible, scalable, and upgradeable PLM Platform.