Requirements, Requirements, Requirements

Requirements are important. Really important. Too often though, this vital part of the engineering process is only partially completed or omitted all together.

This project is no exception. D'oh!

So what do we want to make? That's easy:

  • Robotic The Luggage

Ah, this isn't quite right. Whilst this is technically correct (the best kind of correct), it's not enough to go off and build something. Imagine you're trying to get a friend to build The Luggage for you, but they've not read any of the books. If you tell them to go and build a robot, without any details, who knows what they'll make? Might be a Wall·E (good news), might be a T-101 (definitely bad news).

Let's have a better think about the details of what it'll take to make a robotic The Luggage. Perhaps this will be a better set of requirements:

  • System
    • Robotic The Luggage that acts and looks like the "character" in the Discworld novels by Terry Pratchett
    • Autonomous operation (user will likely be drunk)
    • The Luggage should express the emotion of "agression"
    • The Luggage must have lots of little legs that move
  • Mechanical
    • The Luggage must be about the size of a shoebox
    • The Luggage must move around at about walking pace
    • The Luggage should accelerate to full speed in less than 1 second
  • Electronics and Software
    • The Luggage must be internally powered
    • The Luggage must have a brain inside to control itself without external input

Hmm, that might just do it. One important thing to note is that (hopefully) the requirements don't define the solution. This is important to allow very creative solutions (even if you think you know what the solution is going to be), so it doesn't say anything about wheels, batteries or Arduino at this stage.

Next comes a really fun part: concepts. Watch this space!

2 thoughts on “Requirements, Requirements, Requirements

  1. By including electronics and software in your requirements you preclude making the thing out of sapient pearwood, which is surely the best solution.
    Are you following some kind of generally recognised project lifecycle and methodology with these posts?

    • Damn. You're right! Bloody solutioneering.

      General methodology here is what I consider to be the typical engineering lifecycle: requirements, concepts, detail, build, test. Although the later posts will focus strongly on the build side.

Comments are closed.