Requirements and Architecture

 

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.

Leave a Reply