Keep the Focus on Requirements

I wish they'd spent less time on the gee-whiz stuff and instead made a more ergonomically sound mouse design. Or added more programmability to the keyboard function buttons. Even better, they could have improved their firmware so the mouse driver didn't take five minutes to load on start up. In short, the modifications of the mouse/keyboard combo add complexity, cost, and points of failure to accomplish tasks that the computer already does -- while performing some of its standard functions less than effectively. ("I don't want to work on the basic functions, that's boring. Let someone else do it.")

Looks like someone in program management lost track of the requirements.

Adding unnecessary features just because you can is sloppy engineering. Mind you, I don't have an issue with redundancy in principle. For many mission-critical systems, redundancy is an essential part of a reliability strategy. I just don't think a desktop clock counts as a mission-critical system (and if I suddenly can't see/access the clock on my screen, I probably have far bigger problems than needing to know the time). Admittedly, the keyboard is new and further investigation may reveal the display to have marvelous functions like acting as a portal to another world. Me, I just want a simple, effective keyboard/mouse.

You can't arrive at your destination unless you know where you're going, which is why setting requirements at the beginning of a development project is so important. The job doesn't end there, though. You have to manage the requirements and avoid mission creep, which can consume significant amounts of engineering hours without, in a case like this, bringing significant benefit to the user. The vow of doctors is first: Do no harm. The vow of engineers should be first and foremost as well: Get the job done. Or, take a cue from Occam’s Razor: Choose the simplest solution.

Have you ever been on projects where your colleagues fell prey to mission creep? Where they got excited about adding functionality that the product or system didn't need? Is your philosophy "more is more" or "keep it simple, stupid"? What's your technique for staying focused on requirements and not adding unnecessary functionality? Tell us in the comments section below.

All you have to do is read through some of the Made by Monkeys posts to see that Kristin is definitely on to something. Today, there is so much focus on hitting a checklist of new and improved and so-called "cool" features that engineering teams often lose sight of the basics and the core mission of the product. It doesn't help that requirements are often handled by one system and the actual design by another system (CAD), and the two tend to exist in silos without much interfaction and data sharing between the two.

I don't buy a lot of things simply because they take too long to learn to operate because there is so much useless garbage in them.

A really good designer/engineer makes things more simple, not more complicated.

On my EV I won't have much of anything which I think will be a great selling point not to mention cuts much expense. I'll leave a nice space so if one wants to add aftermarket things they can. And my EV drive won't be the expensive mess most EV's use but Forlift EV drives instead for lower costs, more reliability.

Facts are most electronics are obsolate in 5 yrs so building them in isn't bright.

It'll also be made for the owner to fix by designing it so anything can be repaired or replaced in under 30 minutes, most in under 10.

Now we have cheap inputs of materials but those costs are going up with a bullet so better made, more simple products that last decades and can be upgraded will be the smart choices.

A really good designer/engineer makes things more simple, not more complicated.

Apple Computer's first mouse offering was as simple as could be - just one button to click. This didn't really meet the needs or desires of users; mice today have at least two, plus a scroll wheel.

Apple is very good at breaking ground with simple and elegant products, but to my view they always seem a bit too simple; the most popular products in the class have just a few more features. I-Phones pave the way, but popular phones have a few more basic navigation buttons.

Actually this is a function of product management and market management, not engineering. Someone has to be in charge, and at most companies that is a separate function. In this case, the button on the mouse just invokes the windows button function on the keyboard (just an alternate button, really). A good product management effort would have tried this out prior to specifying it. The engineers really just respond to the requirements set for them by the product managers or systems engineers (on larger projects).

I agree. Engineers are typically not the problem. It is the non-engineers or the engineer-wannabes that seem to create the majority of the problems - not intentionally, but through their ignorance. No silos (HW, SW, or HF) help! Silos are examples of regressive engineering management (unless you happen to be on a farm).

I was employed at a local tech company a few years ago. They install a new phone system. One day they scheduled an hour for us (the engineers) to learn how to use the new phones. How ironic - a room full of engineers (electrical and software) that had to be trained how to use the telephone because the thing had been made so complex that you couldn't just pick up the receiver and dial the damned thing.

Naperlou, as somewhat ex-circuit designers I agree as a designer we were just suppose to implement the design according to requirements. But believe it or not some places don't believe in generating requirements because they say it is a waste of time or money. I'm not talking about small companies I'm taking big defense contractor companies. It amazes me that they don't care or realize that poor or no requirements often results in poor designs. So pay me now or pay me later when it will cost you more.

Requirements should be generated by a systems engineer however a lot of places don't seem to understand systems engineering or the responsibilities. Often times when people find out I do systems engineering work they think I do IT, nothing could be further from the truth. I must admit I didn't completely understand what a systems engineer was until I got my master's in systems engineering. I had one company say I see you have a masters in systems engineering but what kind of engineering...like electrical, mechanical, etc.? I couldn't make them understand that "system engineering" was the discipline like electrical, mechanical, etc.

So as I see it, one of the main problems with requirements generation, analysis and the like is companies will stick anyone as a systems engineering and expect him/her to produce the technical documents like requirements with having a clue as to how to write requirements. Writing requirements is very difficult and important element to product/system/circuit development and shouldn't be taken as lightly as some of my clients and other companies do.

I will stop typing now, as systems engineering is one area that's frustrating to get companies/people to realize the importance of doing it and doing it correctly. Cheers,

Thanks Ockham!! When I was in undergrad systems engineering wasn't even offered as a degree. Now more and more colleges are offering it. Might I add that Johns Hopkins University in MD has an excellent MS Systems program. I may be a little bias since that's where I attended. lol

Kristin, that reminds me of the dotcom days. I was actually charged with developing an Internet enabled coffee maker, among other Internet enabled appliances that somebody was sure the world needed. Toothbrush, refrigerator, alarm clock, toaster? Yes, it all happened at one point in time. It's sort of like the patent medicine devices from Victorian Era; we really haven't evolved much, we just have different fads. I blame Marketing and Senior Management for most of the hype, and Engineers should do their best to lobby them for a more practical design. It becomes sort of a "me too" product requirement. If one wireless keyboard has an LCD display then Marketing is certain that the company will be up for auction if our company doesn't have one too.

This issue is rampant – not just in electronics but in every area of our lives. I remember when I was soon to become a mom and we were making our purchases for our baby. Do we buy the play pen that converts to a sleeper that also plays classical music if the baby moves and has storage for diapers and necessities? Do we buy the stroller that converts to a baby chair? We'll need a camera to record all of these special events. This SLR camera can also take videos. What I have noticed is that the more combined functionality a product has, the less it tends to do any one function well.

As a test engineer, we had very specific requirements as to what the test set must do and we were usually under time pressure. We always hoped for time to do what we called "bells and whistles," but functionality was always the primary goal. If we did get to the "bell and whistle" stage, we also weighed the value that was added. Was it truly enhancing our product or was it fluff, and if it was an enhancement – could we do it well? We didn't want to squelch creativity that could improve a product but we didn't want to sacrifice solid functionality to it either.

BTW – I am SO WITH YOU about that mouse. I can't stand it when my mouse or touchpad takes me to the twilight zone just because I inadvertently brushed it a certain way. The mouse's functionality should be number one since that is a critical interface to all of our computer tasks. Just sayin...

"The previous keyboard had very sticky keys, which if you're a person who types like a mad dog for a living, can be highly irritating, introducing unnecessary typos and reducing speed."

It sounds like you may want to look into investing in a mechanical switch keyboard -- they generally run about $100. This guide has about as much information as you could ever need on the subject. I code on an old buckling spring IBM Model M and I could never go back to a rubber dome. I don't know if you could find a wireless model though, as many of them are marketed as "gaming" keyboards.

It won't be too much longer and hardware design, as we used to know it, will be remembered alongside the slide rule and the Karnaugh map. You will need to move beyond those familiar bits and bytes into the new world of software centric design.

People who want to take advantage of solar energy in their homes no longer need to install a bolt-on solar-panel system atop their houses -- they can integrate solar-energy-harvesting shingles directing into an existing or new roof instead.

Kaspersky Labs indicated at its February meeting that cyber attacks are far more sophisticated than previous thought. It turns out even air-gapping (disconnecting computers from the Internet to protect against cyber intrusion) isn’t a foolproof way to avoid getting hacked. And Kaspersky implied the NSA is the smartest attacker.

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.