Requirements Semantics

[rcauvin]

Several semantic differences have arisen during discussions in these forums. Any discussion of requirements should begin with some basic stipulation of what a requirement is.

How do you define the word "requirement" in the context of product and software development? How do requirements differ, if at all, from design? How do you know when you've specified the "what" instead of the "how"?

[achen]

<<Several semantic differences have arisen during discussions in these forums. Any discussion of requirements should begin with some basic stipulation of what a requirement is.

How do you define the word "requirement" in the context of product and software development? How do requirements differ, if at all, from design? How do you know when you've specified the "what" instead of the "how"?>>

Roger you are baiting me. I thought we agreed to disagree on this one.

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

That being said, the business often times cares or wants things that they shouldn't care about or want, so they do have to be careful not to demand things that truly arent requirements.

Here are some things that may be requirements in one context, but may be design in another context:

Blue buttons vs. red buttons
Using Java instead of C
Using MD5 instead of SHA-1 hashing functions
Creating a shopping cart that can be saved and restored with the prices automatically getting updated.
etc

[rmaciver]

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

I like this a lot, a great definition of a requirement. It is true that many stakeholders cross the line we "techies" would draw between requirements and design. Often we need to probe to determine what the requirement really is. One I've gotten a few times is "Must be .NET, not Java". While on the surface the stakeholder is making a design/implementation choice he shouldn't be, further discussion revealed something different. The organization was having significant issues with managing different JRE versions on client desktops. The stakeholder is really giving us a requirement about simplifying that.

Another distinction it would be interesting to discuss, is the notion of a requirement versus a quality; quality being things like “Must support 1000 concurrent users”, “Transaction must complete within 2 seconds”, “System must be available 24x7x365”. These type of qualities tend to drive implementation decisions more than the functional requirements, but are often very illusive.

[ebacus]

I think that rmaciver is right in that qualities (or more broadly, non-functional requirements) are tougher to grab a hold of than functional requirements. They don't shake out of use cases nearly as well, and it seems they can come from a larger variety of unrelated sources.

As far as the original question around requirements semantics, I think there is a tradeoff between ambiguity and scope that goes on with how narrow or broad your definition of the word "requirements" is. An extremely broad definition like achen's "If the business or user care about it," I think is the smarter side to be on. It does create ambiguity that would need to be addressed, but I think that is preferable to missing something that falls outside your definition of a requirement, but is just as important.

The semantic differences going on in the forum most likely fall out of broadly defining "requirements," but they are a small price to pay for the enhanced quantity and quality of content the board gets from keeping all, or at least most definitions fair game.

[rcauvin]

<<Several semantic differences have arisen during discussions in these forums. Any discussion of requirements should begin with some basic stipulation of what a requirement is.

How do you define the word "requirement" in the context of product and software development? How do requirements differ, if at all, from design? How do you know when you've specified the "what" instead of the "how"?>>

Roger you are baiting me. I thought we agreed to disagree on this one.

In a way, I can't disagree, because I don't know what your definition is :-)

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

That being said, the business often times cares or wants things that they shouldn't care about or want, so they do have to be careful not to demand things that truly arent requirements.

Can you go into some more depth on this point? What does it mean to be something that business users care about? How do you know when what a business user says he wants isn't "truly" a requirement?

Here are some things that may be requirements in one context, but may be design in another context:

Blue buttons vs. red buttons
Using Java instead of C
Using MD5 instead of SHA-1 hashing functions
Creating a shopping cart that can be saved and restored with the prices automatically getting updated.
etc

I like examples :-) Maybe you could pick one of these examples and explain under what circumstances it is a requirement, and under what circumstances design?

[achen]

As far as the original question around requirements semantics, I think there is a tradeoff between ambiguity and scope that goes on with how narrow or broad your definition of the word "requirements" is. An extremely broad definition like achen's "If the business or user care about it," I think is the smarter side to be on. It does create ambiguity that would need to be addressed, but I think that is preferable to missing something that falls outside your definition of a requirement, but is just as important.
.

Where I think roger is coming from is the following logic chain. Let's say you have a business problem, your phone sales reps take on average 5 minutes searching for the customer in the database. Your business goal is to reduce that time to 5 seconds.

At the highest level, the requirement is simply "reduce average customer search time to 5 seconds." You might even say that you are done with the requirements.

Someone has to get into the guts though and build the system. Someone has to decide is the problem a performance problem or a usability problem. Lets say that it is a usability problem. Who are the people that determine how to resolve that and is the solution to that requirements or design?

If I specify that the support rep must be able to search by last name, partial names, customer ids, address, phone number etc. Is that requirements or design?

Lets say you can agree that the above are requirements, then what if my usability experts say that most often last name and first name are used to search and that hotkeys which match the old mainframe keystrokes will gain another 10s. So I specify that certain hotkeys need to be available and map to certain functions. I also specify that hitting enter in the field itself will start the search vs. having to click a button. I then specify that partial matches come back with key identifying data to make it easy for the support rep to scan and ask the caller which record is a likely match. The usability people also remind us that 1/5 of the male population is green/red color blind, so we avoid putting error messages in red.

Are all of those things design? I think it depends on the capabilities of your teams.

We maybe should have said "The system shall be viewable by red/green colorblind people" which in many cases might be a lot better, on the other hand it might be better to specify the exact color scheme because the developers might not understand that red/green means that purple or yellow can sometimes be confusing as well.

From my point of view all of those things are requirements but you do need to be careful to understand the why behind the requirements to ensure that they truly are needed. The design would be the underlying implementation, what search matching algorithm is used to create the partial matches, the object model, the controls that are used to display the data etc.

The "absolute" which seems to work for me is that if the business cares about it, it is a requirement.

[rcauvin]

From my point of view all of those things are requirements but you do need to be careful to understand the why behind the requirements to ensure that they truly are needed.

Anthony, I think you covered the different levels of specification well.

I'm still not quite sure how you define "requirement", but you seem to believe it should encompass most of the specifications short of the mention of software implementation entities (classes, methods, etc.)

You rightly emphasize the importance of understanding "the whys behind the requirements". Do you have a word for them? Should someone document them? If so, should they be specified, to the extent possible, in unambiguous and measurable terms? Should the QA team test them? What relation do they have to use cases?

[sehlhorst]

Hey guys, I've posted my thoughts on the Tyner Blain blog about this - I wanted to incorporate a couple diagrams in my response. Hope you'll check it out.

Requirements vs design - which is which and why

And thanks for hosting a great forum - I don't get here nearly as often as I should, but I've been lurking for a while. I believe your contributions here are helping us all get better at this "software" thing.

[rcauvin]

Hey guys, I've posted my thoughts on the Tyner Blain blog about this - I wanted to incorporate a couple diagrams in my response. Hope you'll check it out.

Requirements vs design - which is which and why

And thanks for hosting a great forum - I don't get here nearly as often as I should, but I've been lurking for a while. I believe your contributions here are helping us all get better at this "software" thing.

Scott, one of your recent blog entries brought to mind another way of looking at this issue. If we look at it in terms of skills and roles, it's not just a semantic issue.

Say we're specifying requirements for an order entry system. Should we include user interface specifications in the "requirements"? No worries, you say; that's just a semantic issue. So we do it: we specify the steps the user will go through to enter and view orders in the system. We might even include a click-action-response table. The developers love it; we've precisely specified the user interface they must implement.

But who should be specifying user interfaces? What sort of skill set is appropriate for such a role? Eliciting requirements is a completely different kind of activity from designing how the user will interact with the system. Most requirements analyst have had little or no training in user interface design. Is it appropriate for requirements analysts to specify user interfaces?

You might say, "The requirements analyst doesn't design the user interfaces but merely elicits the user interface requirements from the UI designer and then documents them." Think about the implications of this statement. We now have the requirements analyst playing the role of a glorified documentation specialist, doing little more than taking dictation from the UI designer. You would think a company would hire a UI designer who could precisely document the UI she designs, wouldn't you?

I hope I'm not offending anyone with these questions, but I think they get to the core of the roles, skills, and activities in a product development process.

[achen]

But who should be specifying user interfaces? What sort of skill set is appropriate for such a role? Eliciting requirements is a completely different kind of activity from designing how the user will interact with the system. Most requirements analyst have had little or no training in user interface design. Is it appropriate for requirements analysts to specify user interfaces?

You might say, "The requirements analyst doesn't design the user interfaces but merely elicits the user interface requirements from the UI designer and then documents them." Think about the implications of this statement. We now have the requirements analyst playing the role of a glorified documentation specialist, doing little more than taking dictation from the UI designer. You would think a company would hire a UI designer who could precisely document the UI she designs, wouldn't you?

I hope I'm not offending anyone with these questions, but I think they get to the core of the roles, skills, and activities in a product development process.

Roger this is a great sample scenario. You are absolutely right in saying you dont want your requirements analyst taking dictation. On the other hand your usability specialist may not know what needs to happen in all the various error conditions and may not know all the error conditions. So in any given team you need to work with the strengths that you have.

What we have found is that most UI people are good at making mockups, however they mostly act as graphic designers.

Most usability people are good at testing your interface and suggesting modifications of what is there, but they arent good at finding all the nooks and crannys where things can go wrong. They need you to tell them the error conditions and they will tell you some good ways to display them. Often times there are multiple people collaborating on a specification and each of them contributes their portion. This may mean that the product manager is just cutting and pasting work products that others on the team have created. On the other hand the product manager is the one that that takes the pieces and creates a detailed spec.

The UI specialists, usability experts and developers all contribute in significant ways, but it is up to the product manager (business analyst) to create the overall specification.