CAROL: No, we're not going there. What do you recommend for organizations that are really constrained by Internet time?
ALAN: Okay. First of all, let's look at the three aspects of requirements management that are essential for any company who is doing Internet time or not. And they are: Elicitation, to make sure you understand your market needs.
ALAN: It's triage - that's the second item. That's to make sure that what you have decided to build is something that can be built given your schedule and time constraints. And here you have to face reality and basically look at a subset of the full requirements, you've got market needs, to decide which ones really need to be built. And the third aspect of requirements management is specification, where actually writing down electronically or on a piece of paper, maybe on the back of an envelope if necessary, what it is you're actually going to build or of the external behavior that the system is going to be, so that developers can move ahead and build that system rapidly without constantly asking questions.
ALAN: Those are the three things.
ALAN: Now, traditionally...
CAROL: Maybe you could take me through that. Pretend that I'm a system developer and I am in one of your classes, and I have my own ideas about how I should do requirements and usually they're on the back of a napkin and then I start coding. What would you tell me?
ALAN: I have no problem with people documenting requirements on the back of an envelope, if the envelope is not then thrown away.
ALAN: Now, it depends whether the envelope is acceptable or not has to do with what your environment is. If you're in a situation where you're building a custom system for a client, you actually cannot get away with just an envelope, because you need the customer and the development organization to sign off, acknowledging that there is a common understanding of those requirements.
ALAN: And the back of an envelope probably won't suffice. So, you probably need at least a list of requirements in electronic form, for example, a spreadsheet, or a database, or a requirements management tool of some kind. If you are doing a, say a dot-com type site, an E-commerce site, a B to C site, and you have to get out there extremely rapidly. You don't have a particular market that you actually can find customers and talk to them. I would not object to a detailed list on the back of an envelope; it might just work.
ALAN: It might be the right level of detail for that kind of business. But in general when you try to get to a marketplace, let's say you're building a product that's going to be commercialized and spread en masse around, then I think you need to do something more than the back of an envelope, and after the break, we will elaborate on what that actually is.
CAROL: Good. And we'll be back with more of Dr. Alan Davis after these short messages. Welcome back, I'm Carol Dekkers, and we've been talking to Dr. Alan Davis about software requirements management in Internet time. If you're working for a dot-com or you're working for any company that's under a lot of market constraints today, you need to still document your requirements for software, but there are some tricks and tips that maybe you don't have to be as rigorous as you are with some of the