Managing Product Development

If you haven’t read Joel Spolsky’s entry on office architecture stop and read that first. Finally, an office in which people can successfully work alone andwith other people — and who don’t have to worry about keeping their voices down. I’m amazed at the space per person (425 sq. ft if I understood). Most offices give people 80-100 sq. ft. My home office is 22×14, 308 sq. ft. I have room to spread out my various current projects, room to meet with one or two people, room for a flip chart and of course all the machinery I need. The offices must feel palatial to the people at Fog Creek.

What Joel describes is requirements starting with the users. Notice that he doesn’t separate functional requirements from non-functional requirements. What people call non-functional requirements are the attributes of the system that make it usable — or not. When you start with the users, and describe requirements holistically as Joel did, (well, ok, he has some design, such as “offices with doors”), you describe what makes the system (in this case, the offices) usable.

Esther and I are teaching consulting skills to architects this week. We have a variety of simulations as part of the workshop, and we’ve noticed that great architects act in certain ways:

• Great architects look for multiple alternatives to explore.
• Great architects look for how the user claims to want to use the system, and continue to probe on currently-visible extensions for how people may want to use the system in the future.
• Great architects discover the primary system attributes that will drive the system and build on that. One architect described this as building from the inside out.

The primary system attribute, what other people call a non-functional requirement, is often unclear. For our simulations, the attribute was the ability to support a physical load. For software systems, it can be some aspect of performance, reliability, security — or some combination. Here’s an example. Our telephone systems in the USA are build around a primary system attribute: the system will have uptime of greater than 99.999% over the course of a year. (The telco requirements are probably higher than that, but it’s a lot of 9s after the decimal.) That means that you can virtually always pick up a land-line phone and get a dial tone. That requirement drove the architecture of the telephone systems, both for each central office and all the interconnections.

If you find that primary attribute, or the combination of attributes, the system architecture alternatives appear — to me it looks as if they become clear to architects by magic.

The lesson I’m taking away this week is that if you want a coherent architecture, it’s more important to discover the primary system attributes rather than all the functional requirements. No matter how you approach requirements, make sure you take a holistic approach. Don’t use techniques that separate functional and non-functional requirements. If you do, you won’t see the architecture emerge.

One of the most difficult problems in software development is knowing how to elicit and discuss requirements. It’s difficult because the people who are supposed to know the requirements don’t always have a clear idea of what they want. And, even people with tremendous communication and other soft skills don’t always have good ways of asking questions.

I’m starting to learn about The Right Question Project, and it appears to support requirements elicitation techniques, along with accountability for both the people generating requirements as well as the people attempting to implement the requirements. I don’t know a lot about this yet, so I’m still investigating. Another possibility in your requirements elicitation arsenal.

Many people who define requirements use some form of documentation to organize their requirements. Too often, that documentation is in the form of a text document. Because text is so bad at describing what a user interface does, the text becomes a design document for the user interface. Then the developers and testers are stuck trying to implement and test someone else’s dicussion of the user interface.

Writing the UI description in text is a poor choice. Instead of writing the UI, try a paper prototype. Paper prototypes are (low cost, low fidelity, and high return) a technique to discuss the UI without the words in the way. At the end of a prototyping session, you know where you stand. You either have a prototype, or you need more discussion. But no one’s trying to figure out why the requirements demand a drop-down menu instead of a text box.

In many of the assessments I perform, requirements are a big deal. Too often, the monolithic requirements documents are too hard to read, too detailed, and insufficiently detailed, all at the same time. I try to build levels of requirements documents, where document doesn’t have to be text. In the case of a GUI, pictures are worth much more than thousands of words.