Freezing requirements in embedded product development

Only very slightly.

I think this is a common problem in many areas - not just embedded. However, it tends to hit us hard because of the attitude "it's only software". Many of our customers are either not engineers at all, or are used to the more physical engineering disciplines such as mechanical or electronic, where they can see what causes the lead times.

All too common a story. Unfortunately, the usual reality is that we have to just deal with it.

But after a certain point in time, the delivery will be delayed, or will miss altogether.

First, make sure you start with a baseline of actual stated requirements and your assumptions about what the missing requirements are. Share this with the customer and give them time to respond.

Then, every time a new request comes through, record this request. Where I work, we log requests in our issue tracking system, just like any other issue (bug, etc). Do an estimate of how much it's going to cost (time and money) to do the change. Keep track of how much it actually does cost (for future reference so your quoting accuracy improves over time).

There is a Jack Ganssle article on

about this very thing. Basically, it comes down to "Customer, we love you, but here's how much the change is going to cost in time and money."

You have to manage the customer. We have several customers who won't shift deadlines (automotive - we have to meet up with the sheet metal at some stage), but keep giving us change requests, even after launch. Basically, we now tell the customer about the cost of each change. Present them with a quote, and they'll soon get the idea. If your management is strong enough, the deadlines will move as well. This, of course, is the main problem - is your management strong enough?

At some stage, the cost of delivering changes will wipe out any hope of profit from the work. Make sure this gets communicated to your management. To do this, of course, you have to be aware of your own (and the other team members') value to the company.

I wouldn't say "good". Just "experience".

I think this is as good a group as any. Most professionals on this group will have gone through similar frustrations (and it *is* frustrating).

Geoff

--
Geoff Field
Professional Geek,
Amateur Stage-Levelling Gauge

Never say 'no' to the boss over requirements (unless it's a requirement for sexual favors). Just send an email that says "sure, here's how long it'll take, and how much it'll set back these other projects". That way you're not a nay-sayer.

A detailed estimate of the additional cost (to him). If your boss doesn't have what it takes to say no to the customer, either live with it, shop around for one who does, or become the boss who can say no.

Have fun. This is what makes hopeful young engineering interns into crusty old cynics. By the time they're 30.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Hello ,

Please note that customer does not change their requirements, they are very clear in what they want. It is you who have not captured the complete requirement! You may want to take a look at PMBOK! from PMI. This is a very common problem, which has been addressed!! I will give you an example, if you (as a customer) have a need to buy a pen, your need is fixed/constant. You want to use the pen at very low temperature! You goto a shop and ask for a pen, the shop keeper (vendor) will give you a pen! If he is intelligent, he will ask you questions like - sir in which price range, brand, etc... Simillarly you should also ask such questions to your customer to understand the hidden attributes! If you dont do this, its your mistake and you have to live with that!!

Best Regards, Vivekanandan M

There is no such thing as a dumb question, only dumb answers. I have already seen that Geoff, Tim and Vivekanandan have provided some quite reasoned answers pointing out it really is a question of how you manage your boss. As well as following up on the Jack Ganssle links at and you should also read a few other books on project management. One book that is well worth a read, "Software failure: management failure - amazing stories and cautionary tales" by Stephen Flowers [John Wiley & Sons ISBN0-471-95113-7], because it reports on a number of projects that failed miserably and explores the reasons for those failures.

Vivekanandan's suggestion about ensuring you properly capture the customer requirements is a really good point. As I deal with the more industrial user I tend to have to learn a lot about my clients processes (I have worked mostly in Energy [Nuclear and Oil] and Transport [mostly Rail]. I have also worked for companies that supply to the food industry [a most fickle clientel]).

To capture the requirements fully I have even generated presentations to give to the customers which describes the approach we are planning to take in providing their solution and ensuring that they fully understand that approach (using lots of diagrams and simple demonstrations) then asking them to sign up to the technical specification. At this point the specification is frozen and the customer is made aware that any changes from then on will cost. Naturally, the earlier they request any changes the less expensive it will be but you should go through the presentation stage again and get new signatures on the updated specifications. It makes the Technical Specification contractual. Beware that the cost of change works both ways in this situation. Any change you make is your own cost and may involve penalties to be paid to your client.

The other aspect that you will need to your project management is to have a very clear and resilient change management process. You should know what the status of every single component of the system is at any given time during its development, whether or not it meets its specifications, how it performed during unit testing, has it met with client approval (if client inspection of testing was a requirement) which issue is being incorporated into the final product. The change management system should be monitoring changes not only to the software but the hardware, specification documents, data-sheets, certificates of conformity from suppliers, and the contractual documentation and correspondence between you and the client.

None of the above should prevent you from being fairly agile in your development process. In fact, if you use a more component oriented approach in your development you may find it easier to be very agile in development and thus minimise the cost of making changes.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Un bel giorno ssubbarayan digitò:

This is very familiar. :)

The first law of customer is: no matter how hard you try, they will always want more. The second law is that they would want your blood, if you are willing to give it to them. Therefore you need to do (at least) two things:

1) Write very detailed specifications before starting to work to the project. Each hour spent on the specifications is at least some tens of hours saved during the project.

2) Make clear from the beginning that you will have fixed release dates for the updates/bugfixes; for example say that you will release a new version one time per month, implementing all of the requests arrived in the previous month. This greatly helps to organize your work. Never ever let someone expect that when they have a request you will fullfill it as soon as you can. Of course there are occasions when you have to do it, but they are far less frequent than you think.

This is always _the_ issue, I think that even people with thirty years of experience still have to deal with it. :)

--
emboliaschizoide.splinder.com

While this is sometimes true, it's far from universally true. Remember that engineering gets its feature requirements from Marketing. If Marketing does not know all the end-user requirements and desires (and they never can) then the actual requirements will continue to evolve every time someone in Marketing talks to a potential customer. This happens all the time in my company.

There is an ongoing effort to commit the entire team to a hard spec before beginning development, but it's slow going to get this system operable. Also, the principal side-effect of telling Marketing "once you sign this, there can be no changes" is that they will never sign - meaning that development will never start.

I've never met a customer like that.

That clarity is just an illusion. ;)

And requirements will almost certainly change after the first beta test unit gets installed because

• Engineering didn't understand the requirement that was stated by Marketing, and that fact wasn't obvious until somebody actually installed and tried to use the product at a customer site.

• Marketing didn't understand the customer's stated requirements.

• The customer didn't know what they really wanted.

• The rest of the system doesn't work the way it was supposed to or the way it was understood to. In my experience all of these are fairly common.

Either that or they'll demand absolutely everything they can think of that anybody, anywhere might ask for at any point in the future. If they know they've got a shot at adding/changing a feature during development and beta-testing, they tend to be a lot more reasonable in their initial requirements.

--
Grant Edwards                   grante             Yow!  Th' MIND is the Pizza
                                  at               Palace of th' SOUL
                               visi.com

I am adding this to the great list of things already posted. If the spec was incomplete then that was a problem from the get go and we allow a certain leeway in places where the spec was fuzzy. However, if additions to the spec/feature list is requested we require that a change order be filled out and the price for the job and deadlines are adjusted appropriately and then the customer has to sign off on the adjustments. The customer tends to freeze the requirements themselves at that point and those that don't know they are gonna' have to pay. I have one customer that has been dragging out a project for WAYYYYYY too long because of their continued "Creeping Featurism" but the checks don't bounce.

Jim

this appeared on digg/reddit today

It may help.

martin

Marketing has no idea what it takes to do this and that, and a very little idea about the customer needs. Marketoids will always try to change something just to make themselves look useful. There is no easy way to freeze the requirements without hurting yourself or anybody else.

The smart way to deal with that is taking the initiative in your hands. I.e. you should foresee their "bright" ideas in advance and have something already available to distract their attention.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

That's why MRD (Marketing Requirement Document) and Firmware Specifications are essential.

Before you write any code, get these two documents written and approved. Quote a development time frame for these requirements.

If they want to change the requirements, generate new versions of the document and new time estimates and get them approved. Keep this up and you have a paper trail.

This is essential if the customer was originally quoted a fixed fee, and has the expectation of only paying that fee. They need to realize that changes cost money. They may assume a verbal change request was part of the original deal.

Its pretty common for this to occur, just make sure you have the documentation trail to insure blaim for cost overruns lie with them and not with you.

I have a customer like that too. Every time they sell out a production run, they revise the product (and run sizes are small). Sometimes it's just a PCB layout change because they altered the shape of the housing, usually it's a firmware change, sometimes they want an extra connector or something else. It is going to be a nightmare for some service technician eventually.

Working with these people, I've realized how it was that no two Commodore computers of the same model had identical contents.

"Should", you ask? At the earliest possible time, obviously. In the best of all possible worlds, that'd be a time before the first hour of work is spent on actually designing the thing. This world is called "theory".

In the real world, also referred to as "practice", it happens as late as your boss lets the customer get away with it.

Never. The strongest you can ever say is: "a change at this point in the project will be _really_ expensive, and certainly make us miss _this_ deadline". This is engineering, so nothing (within the laws of physics) can ever be impossible --- but changes are expensive, some of them prohibitively so.

Maybe your projects are different, but I've never seen that work very well. Most of the time, you don't know what's really feasible until you've written some code and gotten a prototype up and running. Most of the time, nobody knows what they really want until they've got a prototype in-hand to play with. Pretending they do just wastes a lot of time.

Maybe if you're not at all pushing the limits of technology or innovation or anything else, you can use the old standard waterfall model. For real product development where time is money and you're trying to squeeze everything you can out of your platform it just doesn't work.

Sounds like a defense industry project.

--
Grant Edwards                   grante             Yow!  My mind is making
                                  at               ashtrays in Dayton...
                               visi.com

Oh, I have one hell of a file on the thing(s). Tech support has a big matrix of PCB and firmware revisions and what the difference between all of them is. I don't think he has even ordered a run of boards that would even go beyond, what I would call, a prototype run, but, like I said, he has no problem paying for what he wants. At the end of the day, or billing cycle, that is what we are all after. A little fun and a paycheck for our troubles. What is a pain is when it is miserable work on a boring project and the customer wants to argue over every single billable item.

Jim

I had a conversation a while back in one of these groups about how to manage requirements, etc. Most of the feedback I got was along the line of real and hard requirements being fictitious. In general the work I do does have hard, fixed requirements and we spend a lot of time ironing them out before we start development. But my current project is being done by more than one company and it involves reusing hardware (and the resident firmware) in multiple products. As it turns out the result is quickly becoming crap for the product I am working on. In order to get all the "stuff" into product A (another company's project), it is increasing the size and power consumption of the shared modules. This means the portable product B (our project) is suffering from oversize, overweight and battery life issues.

So our "requirements" are going out the window. I'm just glad I get paid either way!

Grant Edwards wrote:

And it is perfectly OK, except for one little problem: it could be very well that you will be made responsible for all of the failures.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

IMO, if you don't have the discipline to initially make a detailed spec, the end product will suffer, not to mention dealing with changing requirements.

Nope. Never worked defense industry. Telecom and consumer products here.

I am sure I will, but what does that mean? I don't think it will mean any impact on my paycheck or my bonus. I may hate the work, but it does pay well. :^)