Are you Ready for Changes in the Requirements Process?

If you are ready for some changes to the requirements gathering process I would like to share a number of possibilities that can be explored. It's best to start out defining a set of objectives to describe what needs to be different. Items such as time, synergy, quality (i.e. less rework) and clarity would probably be the areas where objectives should be established. Also, keep in mind that this is a business level change, not only marketing or engineering.

Focus, focus and focus
The simplest place to start and make a difference is emphasizing management of the entire process. Have one individual responsible for managing the requirements details that spans across the customer, marketing and engineering domains. The domains typically manage their own requirements activities, but there is often nothing in place to drive the technical process through all domains. This leaves the project open to the cross-domain blame game where one domain is locked waiting for inputs from another. A single person that focuses on total requirements actions and manages the cross-domain synergy should make a significant difference. The person tasked with this must be skilled in requirements gathering.

Workshops
This would build upon the focused management aspect to fast track the entire process for a project through a series of concentrated workshops with all the key players. This emphasizes the necessary focus while providing an environment to accentuate closure of specific actions and sub-deliverables. There is an art to facilitating such a process, however, when one does this well the results can be rather impressive. The facilitator of such a workshop must be an individual skilled at focusing a team and enabling synergy while maintaining an unbiased view towards any specific requirements.

Modeling
In my opinion modeling at all levels would be the most advanced form of requirements gathering. This removes the mindless and error prone task of reviewing written documents. Modeling is very common within design but must be advanced into the marketing domain via an industry common language such as UML or more precisely SysML. Other possibilities in modeling platforms exist and the decision on which is best will be left to your organization. The key model platform decision factor should be accessibility outside of design while maintaining the ability to directly interpret the model within the designers world. An emphasis on early modeling over written documentation also yields access to Agile methods, a very successful iterative approach in software product development. The key question to ask yourself is this "Can modeling in the customer domain bring relief to the requirements closure process?". I believe this is easily a yes.

The most important step to a better requirements process is to take an honest look at how the process is working in your organization. If your organization falls in with the majority, you believe the process is broken. Are you going to justify why it is the way it is, or is it time do something about it? Continuing only to talk about the requirements problem is justification; organizing, defining objectives and taking action is doing something about it.

Delivering to the Plan

What does the statement " Delivering to the Plan" mean to you? To me it means that the right product was developed at the right cost and in the right time frame. Essentially, the project was successful in meeting the revenue and margin goals, as per the business case that launched the project. As you are working on projects what objectives are on your radar screen? If you are like most development organizations the milestone focus is probably on tapeout, first samples, evaluation, characterization and production release. Yes, of course you know you need revenue, but that’s not your responsibility, right?

Who is responsible for revenue generation? Sales and marketing, right? WRONG! Everyone on the New Product Development team is responsible for revenue. One important question to ask is, “Are projects failing to meet revenue objectives while at the same time showing success for milestones such as tapeout, samples, characterizations or production release?” If this is the case, it is time to institute new criteria for measuring the success of a project, one that keeps everyone focused on making money.

Success against revenue/margin goals indicates the team’s project decisions and actions were aligned to produce the right product at the right cost and in the right time frame. Setting the objective on revenue and visibly measuring the project’s ultimate success or failure against that objective will create the proper incentive for everyone on the team to challenge product assumptions. When this occurs, the project objectives and goals will reflect a heightened level of clarity, realism and buy-in; enabling projects that deliver to the plan, and that means meeting revenue and margin objectives.

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!