New things keep crossing my desk, not all of them typically within the technical writer’s purview…at least in my previous life. Welcome to life outside of the Matrix. One of these tasks was eminently doable, the other one not so much. I’ll get the bad news out of the way first, since I really hate to admit I don’t know what I’m doing.

Generating Requirements

Ever heard of requirements decomposition? The idea is this: you start out by establishing the top-level requirements for a product. Say you want to build a fighter jet. Great! What are the top-level (“Level One”) requirements for something like that? Well, they might be something like these (completely making these up, by the way):

• Fly at Mach 2 for up to 1,000 miles
• Have a flight radius of 500 miles
• Be able to carry up to 2,500 pounds of bombs
• Be able to land on an aircraft carrier in all types of weather
• Be able to detect and engage intruder aircraft at a range of up to 250 miles
• Et cetera

So what would Level Two requirements look like, and how would those requirements tie back to Level One? As I understand it, the “Level Twos” would be broken out by the aircraft’s subsystems: structures, powerplant/engine, weapons, radar, landing gear, etc., and technical requirements would then be assigned to those subsystems, with the engines having one set related to performance, durability, etc., the weapons systems having range requirements, etc. Take this craziness down another couple levels and the problem for the English major becomes obvious: what am I supposed to put here? I don’t know how to build jet fighters, I’m just the marketing guy who can explain why the fighter’s cool.

So anyhow, thanks to the help of several engineering peers working through the process over the course of a couple late nights, the requirements were put back in shape. But this did require me to have a chat with the program manager about thinking too highly of my ability to “speak geek.” Maybe I can learn more in the future, but under a deadline is probably not the best time.

Designing an iPhone App

This project was a little more fun, since I have some daily familiarity with my iPhone and what it can do. And apparently there are now apps to help you design apps such as App Cooker, which was the assigned tool of the day. Well, let’s start with the basics: App Cooker doesn’t have a user guide or a help function, both of which would have gone a long way toward keeping me from cursing at the bloody thing for 15 minutes before I decided to write a complaint note. That produced a result: the owner-developer, no less, emailed me and offered to talk me through the app on Skype so I could actually use it. He was a nice young man (sounded younger than me, anyhow) from Nice, France and his English was a heck of a lot better than my French.

The real trick for me was using a finger/touch-based interface. The late Steve Jobs might have felt he knew better than consumer “what we wanted” when it came to user interfaces, but he’s dead wrong with some of us. What’s my biggest gripe with iPad and iPhone touch interfaces?

There’s no way around this, folks: I’m a klutz. Fair to poor fine (and gross) motor skills, iffy eye-hand coordination, a long history of failing physical education classes, cutting and pasting, furniture assembly, plumbing repair…okay, you get the idea. So when Mr. Smooth is introduced to a computer interface that requires careful placement and movement of the fingers around small lines or buttons, hijinks are likely to ensue, along with a steady profusion of less-than-cordial language.

The fun part for me on this app thing has been brainstorming the organization and functionality of the interface. I know how I want it to work, but I appear to lack a lot of the patience or basic abilities to make those ideas a reality. We won’t even discuss my two- or three-course “adventure” in C++ programming; I’ll save that sad story for another day.

The point I’m trying to convey after a rather challenging week is that I am bumping up against the limits of my abilities, real or assumed. That’s to the good, I suppose. The problem is that it’s always frustrating and humbling to not be able to do something easily right out of the box. I remind myself that I’d rather be challenged than bored, but “challenge” can equate to “frustration” until competence arrives.

Keeps the brain fresh, anyway. Peace and happy thoughts, y’all.