More than one way

There is not silver bullet or one way to do most things.  The best approach will depend upon the amount of time, talent, tools available, and potential risks associated with the work and level of risk aversion of those undertaking the effort.  The example below, is typical for developing embedded automotive product development.  There are agile and lean approaches to gathering, prioritizing and tracking requirements that have some differences than below. However, from a philosophical approach, that is we need to know what we are doing – gather requirements, then we need to prioritize what of those requirements should we start, build an iteration of the product from which we can learn, and update the requirements with that learning.  Below is an example of how requirements are typically handled for embedded product development.

The Market

For ongoing concerns, the goal is to continue going on into the future.  The organizations goal, ideally, is to cost effectively meet the customer’s needs, and make it possible for the organization to continue to provide jobs for the citizenry while meeting these customer objectives.  The company will employ a number of approaches to gather information on the customer and the product or process needs.  Ultimately, we will have a set of stories (use cases) that describe how the customer will work with the product and how the product will respond to given inputs and interactions.

The Requirements

Requirements are the description of those attributes a product or service must have in order to be of value to the customer or otherwise provide a benefit.  The benefit may not be clear, or may require iterative articulations to improve or refine over time and interactions with models and prototype parts.  The requirements amount to the scope of the product or service, and is the compelling reason for undertaking the project.

There are many requirement types that come from a variety of areas throughout the product development and manufacturing pipeline as well as those from the customer.  For example, the customer will articulate the nature of the area of improvement or problem to be solved.  However, the customer may not understand the dynamics of the system or other requirements.  Is the customer able to articulate the product environmental performance? Does the customer understand the entire rage of stimulus to which the product may be subjected?

1. Performance requirements
2. Design to requirements
3. Manufacturing requirements
4. Functional requirements
5. Derived requirements

Attributes for Good Requirements

Poor requirements will not result in the product we desire.  Building or basing the product upon poor requirements is not the way to success.  It is the way to developing an errant product.  A list of positive attributes for the requirements are listed below.  Requirements should have these attributes.

• Cohesive
• Complete
• Consistent
• Correct
• Observable
• Feasible
• Unambiguous
• Required
• Verified
• Traceable

Cohesive

The requirements describe what we know the product should be and how it should have worked.  The requirements describe the product and not attributes of another product or system component.

Complete

The requirements describe what we want the product to do at that point in time. Requirements morph as we create prototype iterations of the product and learn. We update the requirements with what has been learned.

Consistent

There are no contradictions or requirement in the document that lead to disparate conclusions on the product.

Correct

We do not want to record requirements that are incorrect that will require rework should these be integrated into the product. The language will need to be as precise or specific as it can made, to reduce multiple interpretations.

Observable

At some point we will need to prove the requirement has been met.  This will require some observable effect from the requirement. Additionally, requirements that are not observable are not testable, and testing to requirements are a part of contract and project closure if the design work is being done for a specific client.

Feasible

A requirement that cannot be met, perhaps beyond the bounds of technology, is not a practical requirement, and will be a source of trouble for the product development effort should it not be removed.  The difficulty will be in spending time trying to make something that is not possible.

Unambiguous

Unclear requirements unnecessarily confound the product development effort.  Ambiguous requirements require time to sort, and if not sorted out in a way that actually captures the product or service intent, will likely result in an errant product.

Required

The root of requirements, is required. That is, this element is necessary for the product to meet the customer and market needs.

Verifiable

There will come a time when the results of the requirements must be testable or verifiable. If the requirement is not written in a way that could be verified, then it is a poorly written requirement. There must be a way to demonstrate or otherwise provide feedback to the team that the requirement has been met.  Without this feedback via the verifiability, it is only speculation by the team members that the requirement has been met.

Traceable

The requirements must be traceable to the customer needs or product scope, but also traceable as the requirements morph from learning via customer interactions with prototype parts and perhaps models if we are using models for development.  The traceability to customer requirements, allows us to make informed decisions about the product iteration, particularly when we discover defects in the product. Traceability makes prediction of the consequence when we discover the product does not meet the requirements.

Reviews

We have written an earlier article on the role of design reviews, a type of inspection, that includes the walk through which is a presentation to the customer of the proposed product and interactions, which is generally the response to the requirements.  Cross functional collaboration is required when generating requirements.  These reviews are especially important for ensuring common understanding.  Whether we know it or not, and there are competing elements in the requirements document.  Different parts of the organization have differing (competing) interests or needs from the product.  Reviews can help bring these interests to the surface, and uncover unspoken assumptions allowing for updates to the requirements with clarifying and prioritizing language.

Iterations

Through the development effort, iterations of the product will emerge.  These iterations will be used to test, or perhaps sent to the customer for their feedback on the product features or partial features that are available in that iteration.  This interaction will inform the direction of the product development, and often results in updates to the requirements.  It is folly to believe the requirements will be written in one swoop and not be updated or changed as prototype parts with available features are delivered.  There are those that describe waterfall, a method of development, that requires all of the requirements be delivered in the beginning and these requirements are not allowed to change without great fanfare.  Change happens, especially when requirements, at least in part, have some measure of intuition and guesses.

Changing Requirements

The Requirements

Requirements grow over time and prototype iterations.  To believe that the requirements are not subject to revision or addition over the product development cycle are either naïve or inappropriately optimistic.  The truth is what we believe or think are requirements, can change as a product prototype iteration is delivered for exploration (testing) but the developers and in best situations, the customer.  It is difficult to project all of the attributes of the requirements at the beginning of the development cycle. There are those that will say that the waterfall approach to developing the product requires all of the requirements up front. I have never worked a stage gate product development project, that behaved according to this extreme misrepresentation of waterfall.  However, recognizing changes happen and we should recognize this, and adapt to what is learned in the prototype iterations, does not mean just adding requirements willy-nilly.  At a high level, the change management system should look a bit like the graphic below.

Requirements and Change

The changes to requirements are systematically considered, and either adapted or integrated into the requirements documents, or rejected and excluded. From experience, some of these changes will originate from the testing of the product, when we find that the developers have delivered to an interpretation of the specification (perhaps not specification reviews or inadequate reviews).  As the product is tested, we can find interpretation issues or other needed changes in the specification.  The specification, after being updated, will have a revision or document number change per the configuration management system of the organization that differentiates this iteration from an earlier iteration.

Conclusion

Requirements come from many places.  Discovering what are actual requirements and what is not really a requirement is not a trivial task.  We can use interviews with the customer and develop plans for product iterations through the development process, knowing that we will learn through doing the work, and requirements will be added and altered throughout the work. We should recognize this early on, so what we can to capture and articulate those requirements and know these are subject to change and revision, and that should be done with care.