Granville (Randy) Miller at SD West 05
Granville (Randy) Miller described how to work with requirements in the context of the latest set of concepts developed by Microsoft as part of the newest version of the Microsoft Solution Framework. One of the challenges that makes requirements engineering so daunting a process for me is the difficulty in envisioning the various types of users, when I am dealing with a vast user audience. Often, the identities become a blur and I sometimes find myself trying to develop requirements for an average user, when in fact the better approach would have consisted of stratifying the user audience more.
Microsoft has come up with an intriguing approach, which it is donating to the software development community: visualize the personas in great detail. For example, rather than thinking about meeting the requirements of some theoretical programmer, Microsoft has developed (after much research) a persona for each of several types of programmers. For example, Mort is the name of a persona with a wealth of personal and professional attributes that make it easier to figure out how Mort would use a particular programming tool. Because he doesn't like copying and pasting, Mort might prefer a syntax helper and indent manager built into a source code editor. And so on.
Imagine you're building tools to be used by an agent who's suave, debonair, quick-witted, with street smarts, a good memory and a short attention span. These are helpful attributes, but it's still difficult to figure out how such a user would use a certain set of tools. On the other hand, if one imagines the user to be James Bond, then the issues become a lot more clear (as well as emotionally rewarding. One isn't just writing software for some user somewhere, but for James Bond. Suddenly, one can envision how that user would react in a particular scenario, and one can develop the requirements accordingly.
There's an amusing scene in a recent James Bond movie where the technology liaison hands James Bond a thick user manual about his new car. Bond flamboyantly refuses to read it and instead "wings it" and figures out how the equipment works. To someone who had constructed or studied the Bond persona, this would not be a surprise. By implication, the set of requirements for a user such as Bond would include high usability (including intuitive operation and learnability), high robustness and high durability. Inspired by these visions, a requirements engineer can do a far better (and more enjoyable) job of developing requirements.