Requirements Management

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.

Requirements Management - Value Transformation

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/

Reviews and Walkthroughs.

Reviews of all kinds If you have been in product development for any time, you may have been involved in design reviews, walk-throughs, specification reviews, product reviews, audits and other forms. Recently I was a part of a customer presentation.  The presentation was developed to introduce the customer to a new product design that the […]

Why are we doing this?

By Shawn P Quigley and Jon M Quigley Change Dynamics Change is a function of tension created by the difference between the current condition and the desired state. It can only occur when this tension contains sufficient energy to overcome external forces. These external forces could be something as simple as the current condition being […]

Requirements, Elicitation and Attributes

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 […]

Mere Scrap of Information

Mere Scrap of Information – The Route to the Product I am a guy, and grew up in the 70’s.  My dad was a Vietnam Vet serving in the 7th Special Forces Group.  I grew up watching action movies.  My favorite actor of that era was Clint Eastwood, and one of my favorite movies Fist Full […]

Prototype- Old School Style

The Olden Days by Jon M Quigley I recently had a phone call with a person I met on LinkedIn. Actually, I have been having calls with them over the weeks, to talk about product development, especially the way it was in the olden days.  Over the course of few discussions we began chatting about […]

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 […]

CMMI Tracking

Pugh Matrix

Contact Value Transformation about Requirements Management