The originator may have a good concept of what that electronic, supersonic,

space-age; whatsamagigit is supposed to do, but the hows and heretofores of

what needs to happen in order to make it do that is entirely dependent upon
proper development of the requirements

9 Essential Rules of Requirements Development for Electronic Products

When it comes to electronic product development, many books have been

written about the importance of project requirements development before product
development. Why? Because the requirements phase of development is what
provides a strong foundation for an effective development structure and
ultimately a successful product rollout. Requirements development has a
significant effect on an organization's development costs and product quality as
well as whether a product ever actually makes it to market. Well developed
requirements identify performance needs applicable standards and fills in gaps,
all with the benefit of improving, budgets, schedules, product success and
quality. The key is to adhere to these 9 basic rules of product Requirements
development at the beginning.

Electronic product development is the source of its future to companies and great
satisfaction for inventors as well as revenue for both, yet it can also be loaded
with frustrations and unintended consequences ambushes. The path to quality
electrical engineering begins with excellent requirements. Taken seriously and
executed industriously defining requirements will increase the chances of
delivering on-schedule, on-budget nearly every time. Incomplete or changing
requirements and specifications are among the top contributing causes of
challenged and at risk projects. As in building a house … the architect has to
make the blueprints before the foundation can be laid and before the walls and
roof go up.

There are typically several types of necessary and essential requirements

involved in electronic product development. Each individual might interpret the
word “Requirements” in a different way. This is perfectly legitimate; however a
plan must exist to bring all of these different concepts together. Industry and
product function is the first requirements to consider.

A. Consumer expectations (What is wanted)?

B. Business Requirements comprising objectives for the product. (Why is it
needed, how much should it be sold for)?
C. User Requirements that delineate what functions can be performed by
users of the electronic device. (What does it need to do)?
D. Design specifications, which encompass both the non-functional and the
functional requirements. These include: objectives, performance,
regulatory compliance, design and implementation constraints, and user
or other external interface requirements.
Extensive research shows that timely and reliable knowledge about the
requirements is the single-most crucial area of information essential for electronic
product development. Expending a little extra energy on this step will pay off in
lower development costs and a better finished product.

Rule #1: Use Clear and Concise Language for Requirements

Being specific is essential. Vague or indistinct words should be avoided when

writing requirements. Words like “and/or” and “etc.” should never be used. It’s
asking for trouble to incorporate words like “user-friendly, intuitive, minimize,
maximize, optimize, rapid, state-of-the-art, improved, efficient or simple.” Save
them for your advertising campaign. Sometimes unknown information must be
left out or the original requirements for products that are being developed
iteratively. It is acceptable to insert “TBD (To Be Determined) until the details are
worked out.

Rule #2: Assign Priorities

Clarify which features are priorities so the development team is not left with a
question of which features to trade against. Not all tasks end up being worthwhile
in the end. You may want to consider sacrificing them for more important ones if
necessary. An example is power budget; perhaps you will want to give up a
couple of bells or whistles to get more battery life for your product. Leave some
room for adjustments because they will happen. New requirements, bright ideas
or changes will have to be worked in.

Rule #3: Encourage Stakeholder Participation

Adequate stakeholder involvement is crucial when designing electronic products.

Developers should obtain information and perspective from the appropriate
stakeholders before making any requirements decisions. Surprises are rarely
good ones at the end of a project. Identify your key decision-makers early in the
project so you know who can decide on matters to allow the project to continue
moving forward. Also important is identifying who can drive a change or
investigation as this will affect schedule and cost.

Rule #4: Know Which Regulatory Requirements Must Be Met For Your
Industry

Regulatory requirements are a major driver in the development of any product.

There are a number of federal agencies that require safety compliance for
various products and industries. These many regulations must be identified up
front during requirements development so that the product can be designed to
comply with those regulations that are applicable. Products are tested and must
pass specific safety regulations before they are allowed into the market. A
medical device has very specific and different set of tests than a consumer
device does and these affect almost every level of development of a product.

Rule # 5: Keep Moving - Use Iteration & a Wish List

Skimping on requirements is never recommended but neither is becoming

paralyzed on some portion of the process. If the development is delayed until all
possible requirement modifications or ideas that you could ever possibly think of
have been implemented ... It could stall the project. Proceed in such a way as to
permit development to continue at satisfactory risk level by using iteration and
tracking exactly what a revision is about on the front page with a “wish list” for
future features in the back. Marathon-analysis runs the risk of stalling a project,
entangling it in the requirements. Once the basics have been captured, get on
with it; don’t get ensnared in a never-ending re-write of the perfect requirements
document. Having a place and a process to capture and fold in the information
will aid with this tendency.

Rule # 6: Watch for Scope Creep

“Scope creep” is the addition of ideas and tasks and may indicate a loss of
focus. This pushes costs and schedules and may not really support the “Big
Picture”. Allow some room for growth in your requirements, yes, but weigh the
benefits. Functionality is usually being added or changed during the development
process. If the product scope was well-defined at the beginning it will ease the
pain of accommodating ongoing modifications while still meeting the deadline or
staying on budget.

Rule #7: Examine Effects of Changes

Systematically review the implications of all changes. Identify functions and tasks
linked with each change and determine what the schedule and monetary impacts
will be before continuing. Adopt a defined process for dealing with requirements
changes.

Rule # 8: Get it in Writing

Documentation of where a requirement came from is always a good idea. Is it a

higher-level system requirement, industry standard, business rules, government
regulations or other functional requirements? There may be a point where it must
be traced back to the original requirements so that comparisons and trades can
be made.

Rule # 9: Define the Acceptance Test

The product requirements must be documented, measurable, actionable and

above all testable. In the requirements document itself, define the tests that will
be used to demonstrate and prove the product works to the stated requirements.
Defining the acceptance tests at the start always clarifies what the end product
needs to be.

Developing thorough requirements at the start of the design process gives a

distinct advantage to those who understand the benefits of doing so. The ability
to identify beneficial changes and add to or subtract from the requirements will
ensure that you are working within the parameters of a good foundation for
electronic product development. Establish exemplary communication between
the team members, because design requirements sometimes need to change
quickly to capture efficiencies. Flexibility and the ability to make changes are
necessary throughout the product development process and can be
accomplished more easily when the requirements are well established.
Requirements management and the use of established electronic product
development methodology will go far toward avoiding ambiguities, vague
wording, loopholes, or unnoticed design needs or shortcomings. Following these
rules as the requirements are developed will start the product on the journey to
success.