Design Article
Comment
void(0)
"never static" is an understatement. Better title for the article is "How ...
JonPearson
I would expand on your last sentence: the only thing that matters is the ...
I don't need no stinkin' requirements!
Jon D. Pearson
7/31/2010 6:32 PM EDT
Ask a new or a seasoned embedded systems developer (a.k.a. "the coder") in a casual environment to briefly describe how he or she intends to execute the next project, and the answer will be something like this: "We'll get the requirements, design the system, write the code, and then verify it." The very same day, this coder can be in a conference room at the formative stages of said next project and as soon as he gets a whiff of what the project is about, the code is being written (at least in his head) and the architecture has been locked-in.
The same coder, a day or a week later can be in a very similar meeting (perhaps the same room) lamenting that there are not enough requirements to do his design and until the requirements stop changing he cannot proceed. What accounts for this seeming contradiction?
Every project has risk, and the greatest risk is that the requirements will either not be well-defined at the start or will change many times before the code is completed. At the same time, engineers are tasked with "getting the job done" within the constraints of the situation (and doing so safely, again within the constraints of the situation). Because most commercial projects have a limited market window, time is often the key constraint, whether the push is to meet a holiday sales cycle, a key conference or exhibition, beat a competitor to market, or simply meet an expected schedule. Since time is always limited, requirements will suffer and therefore change or develop throughout the project. I am reminded of a cartoon I saw as a new graduate engineer at my first job over 20 years ago. A manager talking to his coding team says, "You lot start coding. I'll go and see what they want." I was developing avionics software at the time, and many days it seemed to accurately reflect our work environment.
As a member of the marketing staff, I admit we start projects before the requirements are set, compounded by our understanding of what is possible, evolving customer desires (which are imperfectly divined at best), and a constantly changing competitive landscape (especially true for hot, new technology areas). But at the same time, engineers really thrive on their work and so often plunge headfirst into a new project.
So, for the engineer as coder, the real challenge is how to successfully begin and complete a project fast enough that the product generates maximum revenues, knowing that until it actually gets on the market virtually any requirement is subject to change. Engineers will also want to take into account that if it is successful, there will be follow-ons and derivatives required at even a faster pace.
The only sane strategy is to expect and handle change. This begins by expecting everything to change and then subdividing and separating aspects of the design behind strong interfaces. In this way, maintaining the interfaces and the changes underneath will not have an impact on the rest of the design. Incidentally, this type of programming is very deliberate and doesn't happen by chance or in an environment where code is simply cranked out as a reaction to requirements. Certainly requirements are important to designing these interfaces, but you can separate the critical structural ones from the features and, with the following design approach, move forward quickly and adapt quickly. The recipe is:
-
Start with the structure,
-
Establish communications,
-
Build-in the timing, and
-
Enable swappable features.
Next: Step by step
|
|
|
|
|
antiquus
8/2/2010 11:44 AM EDT
There is no contradiction if you consider the psychology of the coder. He is typically in conflict between responding honestly in the meeting (honesty, in the strict sense), and the underlying responsibility to work within physical laws. Specifically, he hears your words and sees your body language in a literal way. You say "Can we go to the moon?", and, since this has been demonstrated, the obvious short answer is "yes". You, on the other hand, thought you were asking "Can this project achieve the goal of delivering two people at the moon safely?", which is more detailed and requires finer analysis.
Also, an engineer by nature begins with all requirements equally weighted, and an unbounded solution space. How about wheels on the moon buggy (who asked about a moon buggy? -- well, it is implied by what you want to do on the moon, so its within the realm of possible solutions). After a week, there are fewer realistic solutions, but they each have their own parameter list. This is also driven by the desire to give you what you want, and an implicit belief that you may not know what you want, or at least you don't know the implications of the directions you have given (otherwise you would have analyzed/handled the problem yourself, and would not need the engineer's contribution).
There is a learning curve on both parties to achieve effective communications with an engineer.
Sign in to Reply
JonPearson
8/19/2010 11:57 AM EDT
As you point out communication is key, and it is just this struggle that makes designing in flexibility essential.
One contrasting experience I had with a customer was a new product development with two teams: one to complete the design all they way up to low volume (thousands of units for a consumer product), the other to re-design for mamnufacturing. In this case, the requirements for the second team are going to be infinitely more stable than for the first team, and therefore the amount of designed-in flexibility would also need top be much less for the second team.
But changes are always looming.
Sign in to Reply
Frank Eory
8/2/2010 4:52 PM EDT
Although the author's perspective is from the software side of embedded systems, the same advice applies to the hardware side.
The only firm requirement designers can count on in new product development is that the requirements will keep changing, sometimes long after you've built the first prototype. When you approach the design with that mindset, you minimize the chances of a late change causing a major disruption.
I was glad he mentioned the concept of wrappers, and wish he had given it a little more emphasis. Wrappers are a very powerful way to abstract your subsystems and allow their internals to change. They have saved me a lot of grief over the years!
Sign in to Reply
JonPearson
8/16/2010 8:49 PM EDT
Thanks for reading and your comment. In the space allowed, going into more details on "wrappers" was difficult. I have addressed this concept many times in several articles, sometimes showing more of the implementation details.
I think I will consider how to get more into the meat of the topic in a future article.
Sign in to Reply
RWatkins
8/5/2010 11:10 AM EDT
After reading the article I was still confused. In the 30+ years since I graduated and started working with engineering electronics systems, both hardware and software, I have learned several hard lessons about specifications and requirements. The author is accurate in noting that customer provided requirements and specifications are never complete and generally change. His described design strategy of making software that is readily modified to adapt to changes is laudable. The biggest issue I have is not with the content but with the title as compared to the content, which would imply (contrary to the details in the text of the article) that requirements are not needed to complete software design.
Generally the customer will provide partial and changing requirements and/or specifications. This does not mean that the developer(s) should not maintain a living document that compiles and completes the requirements and specifications to ensure consistency in design and documentation of what was developed for the system. The documentation of what was done becomes critical in about 6 months, and lifesaving if changes or history is needed a few years out when the developers have changed employers or projects and are no longer available or no longer remember the details of what was done way back when...
Of course when developing specifications and requirements all engineers should remember the last few lines of "Twas the Night Before Crisis":
"and the Customer exclaimed with a smile and a taunt, 'It's just what I asked for, but not what I want.' " That is life, gentlemen.
Sign in to Reply
JonPearson
8/19/2010 12:07 PM EDT
Titles are meant to draw attention and entice us to read on, I think that has definitely happened. I cannot take credit for the title, though.
No successful project gets off the ground without any requirements, and I put forth that no project will be completed waiting for detailed perfect requirements. Designing in flexibility is the answer.
And there are many levels of requirements to consider: Marketing, Design, Test to name a few.
Designing (pushing forward on your project) without final requirements only makes it more important to document the design, especially the layers and wrappers that enable flexibility.
Thanks for reading.
Sign in to Reply
Silicon_Smith
8/5/2010 1:37 PM EDT
Similar is the plight of embedded designers working for OEMs/ODMs. Deciding on a platform and approaching a proto, the team might suddenly encounter a change in Spec or new price points. All of this turns the whole situation upside down and with the deadlines looming near, the whole process becomes very messy. Add to this, the change in expectations after proto and field trials and we have a full scale chaos!! On the other hand though, every aspect of a project is hard to forecast and plan at the outset. The only thing that matters at the beginning is the potential K$ !!
Sign in to Reply
JonPearson
8/19/2010 12:10 PM EDT
I would expand on your last sentence: the only thing that matters is the potential $$ and whether you can capture them. Being prepared to incorporate change without deep-reaching impacts to design (and schedule) is the way.
Thanks for reading.
Sign in to Reply
JonPearson
8/14/2010 7:37 PM EDT
Author Note: the cartoon I mention in paragraph 3 can be viewed at my blog: http://www.cypress.com/go/madness
Sign in to Reply
Patk0317
8/17/2010 4:54 PM EDT
This is the only way to design these days. Initial MRDs are never static. Given that a certain requested feature may not be implementable or the designer might find something better while trying to implement the request. That's the whole point of programmable - because you can make last minute changes or even in field upgrades (that you can charge $$ for)
Sign in to Reply
void(0)
8/23/2010 1:32 PM EDT
"never static" is an understatement. Better title for the article is "How extreme do you want it?". In ideal XP whole requirements-implementation cycle has to complete at least once/day, and usually is much more frequent. Plenty of projects start with no requirements and evolve over time. XP is often equated with "garbage in - garbage out", but, hey, sometimes we need that garbage!
Sign in to Reply