Manage Requirements

The requirements are the reason for the project and development work. Requirements set the expectation for the final product. Either these are achieved or there are reasons communicated to the stakeholder to alter or eliminate specific subset of the requirements. Requirements management requires an understanding of the connection between the requirements, the project objective, and ultimately the work of the project. Requirements management includes commitment to meeting the requirements, the bi-directional traceability of the requirements from customer input to instantiation of the product as well as addressing requirements changes systematically.

Commit to Requirements

To reach the objective the organization must stand behind the requirements. If the organization is not able to commit to meeting the requirements there is no sense in undertaking the project. To be able to commit to the requirements means understanding the requirements without understanding the commitment is hollow.

Evoke Requirements

There are a number of approaches available to evoke and documenting the requirements. To be able to gather the requirements necessitates knowing who will provide this information. Requirements are written in a very specific way to reduce the possibility of multiple interpretations. There will be metrics by which the requirements will be compared to determine if these are written meeting the objective and where the interpretation is singular.

Work Performed and Requirements Discrepancies

The requirements are documented and the team moves to incarnate the specifics that will constitute the product or system over time. A comparison of the work being performed and the work products are conducted periodically to uncover any deviation from the objective. Once uncovered the project and product development work will be altered to ensure that the work being performed is to deliver the expectations defined in the requirements.

Manage Requirements

Managing the requirements is where inconsistency in the requirements from the project objectives as well as maintaining the interconnectivity and dependencies between requirements are maintained. Any inconsistency in the requirements will require corrective actions. As the projects progresses, changes will likely happen, managing the changes and adaptation to the requirements will also be part of managing requirements.

Requirements Traceability

At any time in the product development lifecycle there is a traceable connection between the requirements and the project objectives and plans. This makes identification of the contents of the product at any given point; that is a connection between an instantiation of the product and the requirements through to the project objectives. This connection ensures the requirements; product development and project effort are aligned to produce the desired project results.

Requirements management – consists of the approaches we use to evoke, prioritize and document the expectations of the product. This includes the quality attributes of the articulation of those requirements along with managing the changes and traceability of the requirements to the customer’s needs or demands.

    1. https://www.ifpug.org/

Missing Requirements

Missing Requirements Sometimes the best way to convey the challenges in product development, is to show some of the reasons things can go wrong.  To that end I am going to regale you with a tale of requirements gone astray. Wearing Many Hats I worked at a small company a long time ago. I am […]

Learning

Learning and Product Development By now, we should all understand the need for speed when it comes to product development, but not just any speed, it is the need for speed of learning.  This is one of the benefits of an agile approach, but this benefit is not restricted to a development methodology, unless of […]

Requirements and Project Success

We have written much on requirements in other blog posts.  We have been maintaining this blog for years, admittedly sometimes more fervently than others.  We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the […]

test requirementsmanagement

test requirementsmanagement

Requirements, Benchmarking and Teardowns

Requirements and Benchmarking One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem.  Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have […]

Requirements and Decomposition

The customer can seldom articulate the technical details of the product.  The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible.  We will need some type of document to begin describing in technical terms the product that […]

Good Requirements Attributes

In keeping with our requirements work, we will start by identifying the attributes of a good requirement.  We start our project off with the requirements, so it stands to reason if we start off poorly or in the wrong direction, we will not make the objective.  This situation will get worse the longer we spend […]

Continuous Delivery

Continuous Deliver and Embedded Automotive I have worked on projects that employed continuous delivery for embedded products. The embedded product was an automotive component.  The core of the software (the operating system) was specified using conventional approach. This operating system consisted of the maximum model requirements for this globally used component. The component looked and […]

But our ISO Documentation Says…..

Documentation and Rework Once, a long time ago, I worked at a company that was having some difficulty coordinating their development work.  The product that was produced was a complex arrangement of mechanical and electrical / electronic systems.  The company was ISO certified and had documentation describing how they would work, including configuration and change management.  […]

Quality – when 500 parts per million is not

In the purchasing contract with a tier one supplier, the expected the “0-kilometer” quality or failure rate is not to exceed 500 parts per million (ppm).  These are failures seen before the product leaves the OEM manufacturing floor requiring product rework on the assembly line or as the vehicle rolled off the end of the […]

CMMI Tracking

Pugh Matrix

Contact Value Transformation about Requirements Management