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.