Functional Analysis & Allocation
But, hey, that's ok, because where I was feeling overwhelmed at all the massive uncertainty of how to build a firefighting robot, all this analysis work is paying off. I have a better idea of the problem, and how to solve it, as well as a better sense of the feasibility in time and cost of this project (my budget is a mere $150 and I have until March 7).
Where the story left off was with gathering requirements. The next step in my Systems Engineering Lite kind of approach (the goal is to follow the spirit of the most useful techniques) is Functional Analysis and Allocation, where one organizes the functional aspects of a system into a hierarchy called the Functional Architecture, and then allocates requirements to the functions and sub-functions.
The primary goal is to both decompose the problem, and identify the need for additional requirements. We still aren't really solving the problem, mind you, just sort of organizing the solution. Some functions in this robot: Search for a Room, Search for a Candle, Extinguish the Candle, Move, Steer, Avoid Collisions. There's quite a few more. I arranged these in a simple hierarchy. Navigation covers moving, steering, object avoidance. Control Activities covers the step by step process of searching rooms, finding the candle, extinguishing it, and so on.
Using a matrix (above right), with requirements on the left and functions at the top, I just put an X in the box where a requirement is to be met by a given function. I started with the high level functions first and decomposed as best as I could. If you find more functions are needed to address unallocated requirements, add those if you can. Then I used a series of N2 Diagrams (below right) to model and further decompose the system, and to organize it into a meaningful hierarchy, while identifying subfunctions.
You could start with high level functions, and put them in the diagonal (blue) in a square grid. Outputs of each function appear to the right or left of the function. Inputs appear above or below. Thus, each square represents an interface between functions.
The top-most row in grey represents external inputs (like from users) and the rightmost column in grey represents external outputs (to users). You could have external systems, like if your robot were interacting with another robot, or with a television or something.
Next you decompose each high level function into subfunctions using additional N2 diagrams. You might find that a requirement hasn't been addressed by a function, so you need to add a function. As you add functions, be sure to update the requirements allocation in the matrix.
Perhaps you find you want to combine two top level functions. Or maybe you just need to think through all the subfunctions of a particular high level function. The N2's make this easy to do, and while you're doing this, update the matrix (if I had Vitech CORE, I could build N2's while simultaneously, automagically creating the function hierarchy). I simply kept the matrix and N2 diagrams in sync manually.
After you feel you've captured enough functions and subfunctions to cover the requirements--and in enough detail to jump into selecting your solutions--go back to the matrix a final time and update allocations for the subfunctions.
Right now, most or all your requirements are allocated to high level functions (X marks the spot). You want to allocate requirements to subfunctions (you can do this while decomposing, too), but keep the allocation to higher level functions so you can see an overview. When it comes time to find a solution for a given subfunction, you have fewer requirements to consider.
You're basically dicing up the elephant in preparation to eating it (metaphorically speaking of course).
If you're curious, here's the current version of the matrix and N2 diagrams in Microsoft Excel format: RequirementsAllocation.xls
Previous: Gathering Requirements
Next up: Architecture Synthesis