Requirements always change, so you have to manage the changes. However, there are ways to minimise the impact. The first is to employ a development process where change management is an integral part of the process. Some changes, will of course, have a bigger impact on the schedule and costs than others.
There has been some interesting discussion about "Requirements Churn" and how to measure its impact on the LinkedIn Systems Engineering group. So, in a few brief phrases I'll try to summarize.
- Test the initial requirements for consistency and coherence to make sure it is as complete and as practicable as possible. This will give you a fighting chance of producing a correctly working system.
- Do a "Function Point Analysis" from those requirements which can be used to generate the estimate of time and cost. This will be the initial base- line from which you are working. Set the start of the development project into your VCS with these cost and time values recorded.
- Review what you have so far.
- When a "Requirements Change" is received, test the requirement change for coherence and consistency with the original. Then perform "Function Point Analysis" again to evaluate the change of effort required (remember that it costs to take things out or put new stuff in).
- Review the changed requirements before implementing. Update the VCS and record the changes.
You might like to have the Requirements frozen before you start but embedded systems development life is rarely that easy. Skill at managing the changes in a smooth, resilient fashion will pay dividends. Time spent up-front of a project ensuring you are starting out with as firm a basis as possible will often results in less "catch-up" time being expended later on.