A Snapshot of Today's Requirements Process

In the semiconductor industry today the requirements process for the majority of teams is structured into a serial sequence that looks similar to the diagram to the right. Project complexity may drive a different number of hierarchical requirements levels within the engineering domain, however the diagram concept is the same. In the interest of getting projects started there is usually a parallel component (denoted as the red urgency line) that cuts across all levels of requirements. This parallel short cut path allows the detailed engineering requirements to begin, often without a solid understanding of the top-level system or customer application needs.

Requirements details are typically captured in a word processing document for each level. This document has multiple reviews and iterations before being released to the next lower level of detail. Within the engineering domain the written specifications are often complemented with some degree of high level modeling of the IC component or an IC family of components.

The task of keeping the customer requirements aligned with the engineering implementation details is a manual, error prone process. The engineering level requirements details are usually held close to the vest and typically not shared outside of the company. This separation of what is shared vs. what is kept in "secret" further complicates the alignment of engineering and customer requirements.

The ownership of the requirements process changes as the requirements march towards finer engineering level detail. The high-level customer requirements are usually managed within marketing/applications engineering. The engineering level details are managed within the design team and may have different owners for each level of detail. Note - This requirements ownership and management handoff is a major source of confusion, leading to a lack of clarity and focus.

So, how's this process working for you?

Based on inputs from many of you, requirements at both the project level and individual level is a big problem. Couple this with non-ideal scope change control (Feature Creep) and this makes requirements a huge deal for projects. Organizations are not achieving the requirements results they desperately need, so it's fair that the current approach is just not working.

In reality the requirements process is the one item in the development process that has not evolved, while the design flow and tools have seen significant advances. The existing requirements process is an antiquated system that is impacting our projects to a significant degree and the industry continues to accept this, project after project. I believe most will agree that a change in the requirements gathering process is long overdue!