GeekDad does it again!

Covering a ShmooCon presentation on a disposible spy computer for under 50 bucks. (Article)

For those of you unfamiliar with spy computers or spying in general there is a long history of creating listening devices of all kinds and how you secret them into the spaces of those you wish to spy upon.  A gentleman named Brendan O'Connor details his search and build dilemma of creating a very inexpensive device out of easy to obtain parts. 

The purpose of a device such as this would be to deploy it into an area and use it to do any number of things and relay that information back via wireless so it can be captured and analyzed without the knowledge of the person you are using it on.

Why is this important?  Hardware and Software is becoming easier and easier to come by and understanding how this type of attack would be carried out is paramount to understanding how to defeat such an attack.  Who would be attacked?  In theory given the relative low cost and low need for expertise to build it....anyone is a target

The video is a bit long but Brendon is charismatic and quick behind the podium and you may just learn a few things to protect your business or your home.  You certainly will no longer look at that padded envelope or box of stale crackers quite the same way again.

Defining Requirements: Getting the Truth

Often the challenges of designing something simple or complex are fairly straight-forward. What is often not straightforward are the customers needs and wants. The challenges surrounding this process have given way to lots of tools to pull out the real needs and wants but ultimately as a Systems Engineer you need to know when to "dig some more" when presented with a statement/requirement from the customer. I am not 100% certain that this gut feeling of needing to dig is something that can be taught but some of the warning signs can fit into patterns.

I want to hit one today.

"The system must perform [some function] in [some amount of time]."

First of all we all probably see that this statement is not written as a shall statement. We will all notice this and seek to fix it. However, much like a patrolling police officer notices a missing tail light and discovers someone driving without insurance we need to investigate any time shalls are put together with odd wording. Most people do not write particularly well. The thought is clear in their mind but it simply doesn't make it onto paper or its true intent is assumed to be understood. That assumption is what we are trying to avoid.

Anytime you get a requirement with a time hack on it you need to ask some probative questions. The first thing you should do is define the start moment and end moment. You are simply looking to define the task that needs to be accomplished. Often during this bounding you will stumble upon a poorly outlined task or an assumption about how the design will be implemented. You want to avoid numbers that assume design.

A design requirement is bad. A requirement that assumes design and impacts other requirements in a broad fashion with something like a time interval is potentially going to insert lots of complexity into your design for no reason.

Lets say the task is "raising a platform" you must ask the question. Why the time requirement? What drives the need for that platform to raise in a certain amount of time? At this point you should also make sure you have a requirement for height. You may find that the requirement is based on a timeline you are not aware of or a function that needs to happen during this process. Whatever the base reason is, it will likely reveal functionality or design that was assumed or understood from the customer that is likely not captured in your requirements.

So now that you understand the bounded task you may understand also why it is timed. If you manage to nail both those things down the requirement may be able to stand on its own. However it leads me into a few more questions.

Is it our intent to test this performance? Or is this simply a portion of a larger time requirement.

If its part of a larger time requirement you will want to budget this requirement. It may in fact be that the rest of the system will not eat up enough of the higher level time requirement and that this particular function could perform on a longer timeline and not impact overall performance. This discovery could potentially lead to tradeoffs in hardware or software that could potentially reduce the constraints on the system as a whole and lead your team to cost saving discoveries.

Its important to ask questions even when the requirement seems very straight forward. It can eliminate scope creep in the future as you discover what the real intent of the requirement was far too late in the game and the issue eats into budget. Bounding the requirement and asking the reasons behind a requirement often will lead to a better understanding of your customer and possibly a lower cost/complexity solution even if it means a few more requirements.