Embedded Systems
Products & Services

Home Services Products Resources About Contact

Javascript is used
on this Web site to
do things like open
pop-up windows
and to prevent
harvesters from
extracting PayPal
account info.

All material on
this Web site is
protected under
United States
and International
copyright law.
[more...]

Liability for your
use of information
on this Web site is
strictly limited.
[more...]

Trademarks used
on this Web site
are the property of
their respective
owners.

Atmel and AVR
are registered
trademarks of
Atmel Corporation.

Engineering Process Consulting

ECROS Technology can help you organize your embedded systems development.  Many projects fail because they were not at the outset put on the rails that lead to success.  We can help you establish a clear idea of what has to be done, make sure your timescales are reasonable and your people properly equipped and trained to accomplish the job.

Steps of a Complete Engineering Process

An engineering project is most likely to succeed if it is broken down into a number of steps, each with a specific goal, designed to produce a physical end result from an initial abstract idea.  The steps should be designed so that their output or results can be validated against some known-good reference, for example the output of a previous step or the ideas in the customer's head.  By regularly pausing to ask "Is what we've done so far leading us in the right direction" everyone can be sure that time and money are not being wasted and the project is making progress.  This procedure also points a searchlight on uncertainties in the objectives of the project, which should be resolved as early as possible (or the project scope narrowed to exclude them).

There are many descriptions of engineering processes available in books, papers and on the Internet.  This page presents ECROS Technology's particular approach, but this is not meant to suggest that other sources should not also be consulted.  The focus here is on what each step is intended to achieve and what its output contributes to the project.  The exact means of executing the step and reaching the result is much less important.  Pragmatically, the organization of the project (for example, the views of some people involved) may make it impractical to perform some steps in a formal way - with meetings, documents, reviews and sign-off.  The idea presented here is that, nevertheless, some effort should be made to produce the results of those steps, even if it is one person thinking things through and discussing his or her conclusions with as many others as will listen.  In some organizations, doing engineering right can be a battle and flexibility is a valuable weapon to those who understand the benefits of following a process.

Use Case Analysis

The first step should always be to consider how the end product will be used.  It may be tempting to think that this is obvious.  This suggests pre-conceived ideas that may later prove to be wrong or at least incomplete.  Imagine yourself in the position of the user.  Try to think of unusual situations, especially those that could result from some kind of failure (for example, loss of power or network connectivity).  Involving someone new to the project can help with this.  The goal is to identify every reasonable way in which the user will try to use the product and what reasonable expectations the user will have of how it will operate.  The completion of Use Case Analysis is validated by asking the question "Have we identified and studied every situation in which we want the product to be used?" and receiving the answer "Yes!".

It can be difficult to get buy-in for this step of the process, especially if the product sponsors view the requirements as "obvious" and want to see immediate progress towards an implementation.  Meeting over lunch, or just talking while waiting for late arrivals to a meeting, can prod people to consider use cases and result in a product that meets the end user's expectations in more circumstances.  If a formal document cannot be produced, the discoveries and open questions should at least be circulated by email.  As a last resort, just taking opportunities to ask questions about how the product will be used can gain some of the benefits of this step without actually using the words "use case".  It is important to have the people who will work on requirements and function present for these discussions, especially if they are informal in nature.  The degree to which questions remain unanswered at this stage can be a good predictor of how much trouble can be expected later.

Requirements Elicitation

A Statement of Requirements is a way of one group of people telling another group of people what they want.  The first group could be a customer or the sales and marketing organization in your own company.  The second group is your engineering organization.  The language of this document should talk about what the product must do and avoid all assumptions about how it will be done.  The requirements for an automobile, for example, are "a system for moving a small number of people from place to place with tolerable safety, delay and cost", not "a box on wheels that travels at such-and-such a speed".  If possible, the requirements should flow from the results of the previous step, Use Case Analysis.  The idea is to distil the use cases into a single set of properties such that if the product possesses them all then it will operate correctly under every usage scenario.  The completion of Requirements Elicitation is validated by asking the question "If the product meets these requirements, will it perform as we expect in all of the studied use cases?" and receiving the answer "Yes!".

Completeness is the biggest problem with requirements.  An incorrect requirement can usually be spotted, but a missing one is much harder to detect.  Note that in the example above for an automobile we covered secondary issues of safety, delay and cost as well as the primary function of transportation.  But this is still not complete.  What about size?  We also need to be clearer about what we mean by "tolerable" and all the other terms.  This is where use cases can help.  By imagining potential users interacting with the product in different ways we can begin to be more specific.  We think of the users acquiring the product, keeping it at their homes, maintaining it, supplying power to it, dealing with failures and disposing of it at the end of its useful life as well as popping out to the store.  These issues can play a large part in the success of a product but are often ignored during design.  Note that anything missing from the Statement of Requirements could be resolved in an arbitrary way and our only hope is that "good engineering judgment" exercised later on will make things come out right.

Functional Description

A Functional Description is a way of one group of people telling another group of people what they are going to produce.  The first group is now the engineering organization and the second group the customer or sales and marketing.  In effect, the Functional Description is an "answer" to the Statement of Requirements.  It differs in the level of detail and point of view.  For example, if the solution to the automobile requirement turns out to be a box on wheels after all, the "tolerable delay" requirement will be addressed by stating the intended acceleration and speed of travel.  The general approach to design starts to become apparent, but it is still important to avoid details that might unnecessarily limit options later on.  Elements of function that need not be described to show that requirements are met should not be mentioned.  For example, it may be necessary to state the source of power for the automobile engine to show that this source is readily available.  But other details of the engine should be held back until the design stage.  The Functional Description is validated by asking the question "If the product functions as described, will it meets the stated requirements?" and receiving the answer "Yes!".

Most organizations that at least pay lip service to engineering process produce a "Functional Spec." at some point in the project.  The effectiveness of this document, however, can vary widely.  In fact, it can be almost none, as in some cases it is little more than a summary of implementation decisions that have already been taken and cannot be checked back to what the product is required to do.  In any reasonably well organized project, the people commissioning the product (that is, the people who want the product to be created, control payment for its creation and in the end expect to benefit from it) must have some way, early in the project, to verify that the people building the product are going to make the right thing.  The Functional Description is pivotal in this regard.  Even if the commissioners (the customer, for example) have done no use case analysis and written no requirements, they should be able to see from this document whether or not the end product described is what they want.  Therefore, it must be written so as to express the complete function of the product in a clear and understandable way.  Block diagrams, part numbers and algorithms are not going to do this (they belong in design documents); what is really needed is clear narrative.

Architecture and Design

Any non-trivial intellectual task can only be achieved by normal people by being broken into smaller tasks.  This is due to fundamental limitations of human Working Memory and cannot be avoided.  In engineering, this process is given the names "Functional Decomposition", "Top-Down Design" or called the "Divide-and-Conquer" approach.  If this is not performed in a formal, controlled way, it will take place in a happenstance, uncontrolled way, and the consequence will be inferior results.  This is why design must be performed before implementation.  Without this step, during the implementation phase, people will have too many details to think about to make the best decisions about the work in hand.  A formal design puts limits to the complexity of each task by answering questions about how that task relates to the overall project.  In the Architecture and Design step, the product functions identified in the previous step must be divided up and allocated to smaller sub-systems until the complexity of the sub-systems is tractable to the people who will implement them.  The Design is validated by asking the question "Can the elements of this design be implemented and integrated so that the complete system has the function described in the Functional Description?" and receiving the answer "Yes!".

The distinction between "Architecture" and "Design" is rarely well defined.  Sometimes the architecture of a system is defined by the more highly paid workers, who have the word Architect on their business cards, but just produce the upper levels of the design decomposition.  A useful definition for architecture can be drawn from the field of building styles.  Here, to produce a building that conforms to a certain style, the architect adheres to a certain set of rules that limit his or her choices at the detailed level.  For example, to produce a building in the Federal style, the roof must be low-pitched, windows must be placed symmetrically on the façade, etc.  The fact that these rules may be arbitrary does not matter.  A skilled architect uses a set of rules that will result in a pleasing structure, or in the case of an engineering project, in an elegant product design.  The point is to limit the solution space that must be explored by other contributors to the design, without compromising function, thus speeding up decisions and giving the system a "unity" that makes it easy to understand and work on.  An architect that can do this deserves his or her higher pay!

Acceptance Test Plan

To complete a project on time and within budget, it is essential to be able to answer the question "Are we done?". 

Implementation and Unit Test

Integration and Engineering Test

Test Procedure and Acceptance Test

Documentation