The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Defining Effective Product Requirements

How do you establish effective requirements?

In my experience, requirements is a very touchy subject in the development community and is highly subjective.  To some people its a few random sentences written with crayons on a napkin, and to others its several hundred pages of detailed analysis based on extensive interviews, market research, user groups, and sales trends.  A lot of people also tend to push product requirements, functional specifications, and technical implementation all under the general "Requirements" umbrella.

I've always thought of requirements as a set of necesities or conditions that are "required" to solve a problem.  Thats it, plain and simple.  They shouldn't involve implementation or design.  Rather, they should address what's needed to provide a solution to a concrete problem.  I think this is where the majority of development breaks down.  People, and in turn their organizations, don't take the time to really think about what they're building and why. 

My question to everyone here is this.  How do you define effective requirements and how do you or your organization go about obtaining them?
Martin Beechen Send private email
Thursday, March 01, 2007
Product requirements are ordered lists. That definition is so powerful I'm going to give you the last two words again.

Ordered. Lists. Say it aloud.

The lists are elements that must exist in the product or product development process. They might be features, resources, budget limitations, platform requirements, icon colors (cornflower blue!) or metrics.

The ordering part is the management process, of working to get all the items on the list into the right spot, from most to least important. The more contribution and buy-in on the ordering at one point, the better.

Good product requirements (aka ordered lists) are in a very precise order and in consistently-sized detail. Note that you don't need to go into excruciating detail, just that if you're handwaiving over the grammar checker as a requirement but obsessing about whether or not the spellchecker will accept Klingon surnames, you are not being consistent.

Ordered lists. It's that simple (and that hard). Good luck.
Robby Slaughter Send private email
Thursday, March 01, 2007
In most cases you can not because the requirements are not known, they are only speculated at.

Situations where you can devise accurate requirements in advance of design are rare.

In other cases, only known solution is iterative development.
Meghraj Reddy
Thursday, March 01, 2007
In the old days we used to have a formal technique called 'requirements anaysis'. 

Anyhow, one would end up with an ordered set of requirements with a data dictionary explaining what the terms were.
Andy W Send private email
Thursday, March 01, 2007
Requirements are ordered lists where the value of the ordering key of any given element of the list is identical to the ordering key of any other randomly selected element of the list.

OK that's just what it seems like sometimes.  In truth, there are two requirement types.  "Do it this release" and "do it sometime later".

If on the initial pass there are not enough "do it now" requirements to fill the alloted time, then some will be promoted.  If there are too many, then some are demoted; the time is increased; or the project fails. 

As to the original question, requirements tend to be fluid.  This is why the world has various (lower-case 'a') agile development techniques that try to keep a 'release' to a fixed amount of time, so you can focus only on the requirements that can be delivered in that time, and instead commit to a large number of discrete releases rather than some release 3 years down the road and a 5000 page requirement spec, which will be out of date 2 months into the project.
Dan Fleet Send private email
Thursday, March 01, 2007
@Robby Slaughter

You said, "The lists are elements that must exist in the product..." and you said, "The ordering part is the management process, of working to get all the items on the list into the right spot, from most to least important"

I think these two statements together kind of undermine each other.  If every item in the list is truly necessary, then they are each equally improtant - missing any one of them results in a product that is missing something essential.

@OP  My thinking is similar - requirements are essentially characterizing the necessary (and also sufficient) conditions for an acceptable solution.  I'm not sure of all the details of the process my organization uses to collect requirements, but they do a pretty good job of it.  I know one technique they are currently looking at is Quality Function Deployment (QFD)
Friday, March 02, 2007
"... and is highly subjective."

You also need to take into consideration your audience's expertise. And this is where I think the real crux of the problem lies.

For example, let's say I have a superstar programmer who's been with the company for ten years, and knows the business processes inside out.  I've also hired a college student who just graduated last week and has no true work experience. It will be almost impossible to write one set of requirements that satisfies both - the amount of detail the newly hired will need, can confuse and/or insult the experienced programmer. Targeting it towards the superstar will leave the newly hired, bewildered.

In reality, "product requirements" may be reviewed by a wide range of people, including your developers, the QA staff, marketing, legal, shipping and distribution, post-sales customer service, finance, and even possibly C-level executives. Within each group, you might have people familiar enough with the technology to understand bare requirements, and people who are complete luddites. Writing a single set of requirements that satisfies everyone is like setting out to write a screenplay for a movie that 98% of the country will enjoy seeing.

Towards that end, quite honestly the only "effective" product requirements I've actually seen are from people who understand this and have established some sort of framework that gets the right requirements to the right people. I.e., they have a technical description for folks like me, a marketing plan for those folks over there, an executive summary for the CEO and so forth, as opposed to one single document.
Friday, March 02, 2007
Strider, consider these requirements for a car:

- Must have side-impact airbags
- Must have seatbelts

Clearly, both are important. But the seatbelts are *more* important. Getting everything on the list is key; then you have to work to put the list in the right order so crucial elements bubble to the top and less important ones go to the bottom.

Jump down to point #13 on Joel's article on scheduling, and see what he says about Excel 5. He makes the point better than I do.
Robby Slaughter Send private email
Friday, March 02, 2007

Maybe I'm just being dense, or maybe I'm just being a overly precise:

- Must have side-impact airbags
- Must have seatbelts

Since you *MUST* have each of these, how can one be more important than the other? An output which lacks either one is unacceptable (definition of "must"), right?

It would make sense to classify options this way where one is more important than another, but for things which are required, it's an all or nothing game.  Each one is just as capable of destroying the entire value of the product (i.e. causing the product to fail) as the other. Each one puts the same amount of value in jeopardy.

Consider requirements for a building:

- Must have horizontal support (floors), and
- Must have vertical support (walls)

Clearly both of these are equally important.  If you get behind you can't just say, "Oh well, let's skip the walls so we can get back on track." No one's going to buy space in a building where the floors are just stacked up in a neat pile, one atop the other, eh?

Anyhow, I agree with everything else that you wrote, so I'm probably just being nitpicky.  It's just that there is a certain lower bound on the set of features beyond which the product's value goes to zero.  Everything that constitutes this lower bound forms an equivalence class with respect to priorities.
Saturday, March 03, 2007
“Requirements are order lists” is correct. Or isn’t? They are a "To do .." list right? They tell what needs to be done for the solution to be accepted by the customer.
Or they tell to the development team what to do to have the QA signing off on the implementation.
Everybody can have a “To do“ list but they are not identical within an organization.
The problem with those order lists is which one is the “Product requirements”?
A program manager prefer the list to contain some information, an experience dev (as somebody mentioned before) will have a different “to do” list that a new grad dev, and no one will be like the one the tester will prefer.
Why not start with defining the purpose of the product requirement, the scope and the place in the information flow within the development process?
I believe clarifying those points will clarify what we talk about.
Mihai Iuga Send private email
Monday, March 05, 2007
Effective product requirements depend significantly on the type of product to build, the budget and the customer.

Defense contracts for mission-critical applications costing several million neccessitate very formal and rigourous requirements.

Joe down the road who wants some add-ins to his QuickBooks software for a budget of a few hundred bucks and a pint of beer indicates something completely different.

We develop systems for customers as consulting as well as our own IP (products) and the way we develop for these markets is different too.
Paul Norrie Send private email
Tuesday, March 06, 2007
Martin, you may have misunderstood something important about requirements. They are not what YOU (the developer) require to do the job; they are what THE CUSTOMER requires from the software.

I have no opinion about ordered lists, but the requirements spec should describe (from the customer's point of view) what the software should do.

It's true that in almost all cases you can never pin down exactly what the customer wants at the start, but some developers use this as an excuse for not talking to the customer at all. With Requirements the more you know about what the customer needs the better your software will be, even if you don't know everything.

I just had a requirements meeting; it lasted an hour and I discovered two important things they needed that I hadn't thought of, and one I thought they needed that they didn't. That hour has saved me probably a couple of weeks work.
DJ Clayworth
Tuesday, March 06, 2007
DJ, regarding your comment:

"Martin, you may have misunderstood something important about requirements. They are not what YOU (the developer) require to do the job; they are what THE CUSTOMER requires from the software."

I think you've misunderstood the point of my post.  I'm basically saying that everyone thinks about requirements differently (your explanation is a good example of that), and wanted to get an example from everyone of what they think requirements are.

To elaborate a bit on your point, I think that simply trying to find what the customer requires from a piece of software is flawed.  99% of the time, customers have no ability to effectively articulate what they require from a piece of software, and with rare exception, developers can't either.  Simply trying to figure out what a customer requires assumes an inherrent understanding on behalf of either the developer or the customer/client about what the problem is.  Without a precise and clear definition of a problem, there is no way to effectively establish what is required to solve it.

With that in mind, here's what I do when I define a requirement.  (regardless of whether is a client, customer, or product).

1.  Identify the problem.
  Establish the problem I'm tyring to solve. I should be able to clearly articulate the problem and specifiy its root cause.  I should know who it affects, the circumstances under which it occurs, its frequency and repeatability.  I should also have some sort of supporting information for my findings.

2.  Define requirements
  With the identified problems in mind, identify capabilities, characteristics or quality factors that bound the product or process I'm dealing with.  This is key, as I'm defining a necesary characteristic for solving the problem(s) I've identified.  IMHO, these should be concise, design free, verifiable, attainable, and unambiguous. 

3. Design an approach
  Produce a design (technical or otherwise) for satisfying the requirements.  I'd go into more detail, but I feel its beyond the scope of this discussion.

4.  Implementation
  Build what was designed.

In my experience, most people don't do #1, and then like to combine #2 and #3.
Martin Beechen Send private email
Tuesday, March 06, 2007
I think we're all in violent agreement in this thread.

It seems like everybody is saying in one way or another "you really need to figure out what you are trying to do before you do it" and also, "most people tend to rush through this part and get to the 'fun stuff' of actual coding."

Obviously, there are lots of ways to figure out what you are trying to do before you do it (aka "Define effective product requiremetns."). I like the ordered list approach. Others like to get the customer in the room. Some people want to produce reams of documentation. But it seems we all agree that just diving in is inadvisable, and, tragically common.

Thank you and good night.
Robby Slaughter Send private email
Tuesday, March 06, 2007
Defining effective product requirements is incredibly hard for some problems.

Consider a design team working on a "safe" car.

Bob, from Marketing,has been conducting studies and focus groups that indicate a lot of interest in cars that are safer in a collision. He is concerned with how to package a new “safe car” in a way that is positive, sexy, and up-beat.

Christine, from Engineering, is very concerned about
making the doors too heavy, but she has worked on
structural integrity in the past and is excited about new technologies that, while expensive, could make the doors both stronger and lighter.

Harry, the representative from the Management Team, sees the big issue as cost – top management is pushing affordability and value as the new strategy to increase sales.

Alan, from IT, has a mandate from his management to get this team to use the new CAD (Computer Aided Design) system on this project.

There are team members who represent Regulatory Affairs, Finance, Graphic Design, Power Train, and Quality Assurance, as well as team members from several major
suppliers, including electronics and interior materials.
Each player has their own individual experience, personality type, and style of thinking and learning.

Each player adds a new jagged line to the graph. The individual diversity among these players can make consensus on the real requirements virtually impossible to achieve.
Mark Pearce Send private email
Friday, March 09, 2007
Yikes Mark!  That is where the 'non-goals' portion of the spec comes in handy.  While it may certainally be difficult to pull some of the weeds, in the end you will have a more beautiful garden.
Elizabeth Donovan Send private email
Tuesday, March 20, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz