The Requirements Guide

Our process improvement initiative on requirements resulted in some updates to our checklists and quality process tools, but some of the things we learned didn’t have an obvious place to go. Some of the things we learned seemed worthy of standing on their own as something new. We created a requirements guide to capture the rest.

The major parts include:

• Steve McConnell’s “Project Team’s Bill of Rights”
• The Requirements Mindset – What to think about requirements
• The Requirements Process – What to do about requirements
• Requirements Management in Phased Projects
• Requirements Analysis
• Types of Requirements

Steve’s Bill of Rights essentially states the obvious, but not always guaranteed, things which any engineering team deserves: the purpose of the project, the requirements, access to necessary resources, agency for executing the technical work in a responsible way, and re-estimating when things change.

Then we summarized some basic points about the right mindset regarding requirements – what to think about requirements.

Requirements Are A Must

Requirements are needs; a description of what must be exhibited. They define what, not how. They are not architecture or design. They come before that, as the first step towards a solution – a critical prerequisite. Requirements are also a primary means for communication between a client and the engineer. At the start of a project, the client has stuff in their mind and we know none of it. We need to have the posture, “What does the client want? What do we have to provide?” Requirements create a basis for mutual understanding of the scope of a project. They promote accurate estimation of effort and definition of exit criteria. They also enable the project team to detect and manage changes in requirements and scope. Good requirements promote happy engineers, efficient development teams, good systems, and satisfied clients.

Good requirements management establishes a foundation for the success of the project, and a common risk in development is poor requirements management. Development projects are consistently challenged to manage this risk. Requirements management is not unnecessary overhead – it is risk management. The scope and level of effort of requirements management must be tailored to the project. This requires careful thought, judgment, communication, and agreement across the entire team. The requirements effort can be driven by the nature of the problem, the expertise of the engineers, the client, or the project. Determining and documenting requirements can be hard, tedious, time-consuming, abstract, and doesn’t feel like progress – it’s tempting to get on to the “real work” of building something. Uncertain or to-be-determined requirements lead to inaccurate cost and schedule estimates. Without a good foundation, the best we can do is damage control.

This is why it is important that everyone on the team understands the importance of determining and managing requirements. This includes the positive impact of doing so and the negative impact of skipping it. The requirements guide helps our project teams to think about these things proactively, which ultimately results in better outcomes for our clients.

About Indesign, LLC

Indesign, LLC is a multi-discipline engineering design firm that provides full turnkey electronic product development to allow clients to get their new product ideas into the market quickly. Indesign offers complete product development capabilities, starting with a product concept and finishing with a ready-to-manufacture design. Indesign has an ISO-certified product development process and a proven track record for on-time, on-budget, high-quality product realization. To learn more about us and our services, contact us at (317) 377-5450 today!