Software Best Practices

I have been teaching requirements for years now and I still don't have a good way to talk about problem space vs. solution space. I think it is critical to make the distinction and give the students a way to see it for themselves. Otherwise, they get into the trap of very detailed requirements that blur into and past design. You know the ones, "We got to have a drop down list of four items." Any ideas out there?

Earl, Are you implying that "We got to have a drop down list of four items" can't be a requirement? If so, I disagree. The customer is paying the bills. It's their money, they can require whatever they darn well feel like. If they choose to require use of a drop down list on the UI then that is clearly their perogative.

The way I explain it is that building software is fundamentally a decision-making process. All kinds of things need to be decided, from what's in scope vs. out of scope all the way down to "what should I call this variable?". Requirements, in a very real sense, are simply decisions that the customer chooses to make and thus impose on the developers. "Design" could then be thought of as "making the rest of the decisions that the customers deferred to us so we can finally know what lines of code to actually write".

In another dimension entirely is the question of "what was the decision about?" Any customer-made decisions about business policies to be enforced or business processes to be carried out ("problem space") are the so-called functional requirements. Any customer-made decisions that constrain the use of automation technologies ("solution space") are the so-called non-functional requirements. It should be apparent that the customer is unlikely to defer very many decisions about business policies & business processes to the developers. We could conceivably refer to those rare decisions that did get deferred as "functional design". Clearly, unless the customer is very techincally saavy (and has a bucket-load of time on their hands), they are unlikely to want to make many of the technology decisions (as I said, the non-functional requirements) leaving them to the developes. We could call the left-over decisions "non-functional design" if we wanted to.

So it should be clear now that a customer could, and for very good reason, decide that they "got to have a drop down list of four items". Maybe they've thoroughly considered all of the alternatives: radio buttons, text fields, etc. for accomplishing the same thing and have decided that no other alternative than a drop down list is acceptable to them. Therefore it's not the developer's choice. It's a requirement.

Now, having said all that, I think the real question is "did the customer really consider all of the available alternatives before making that decision?" It's the developer's duty to at least question the customer's decision, "did you realize that this same thing could be accomplished with radio buttons and might that be a better solution to your problem?" If the customer says, "Hmmm, hadn't thought about that... Are there more possibilities than just that?" then we've successfully defused the not-really-a-requirement situation. On the other hand, and as long as the customer says, "Yup, we thought about that and we decided after all that it's simply got to be the drop down list" then there's your requirement.

IMHO, it all boils down to the "Five Whys" technique, not the fact that it's problem space vs. solution space.

 

I agree with everything SteveT wrote. The difficulty is when the customer thinks they want a drop down list with 4 items but they don't know enough to know that that will make the UI harder to use, or be inconsistent, or violate a UI guideline. The "requirement" is in what would traditionally be called the "solution space," so some people would say it's none of the customer's business. In this specific example, the BA or developer just needs to do more education of the customer about what the implications of requiring a drop down list with 4 items are. If, after all that, the customer still wants a drop down list with 4 items, then I agree with Tockey that it's a requirement. Requirement = what the customer chooses to require.

In terms of the more general issue of "problem space" vs. "solution space," I think it's a false dichotomy. It's exactly analogous to strategy vs. tactics. One level's tactics is the next level's strategy and vice versa. Dividing the requirements universe into problem space vs. solution space implies that the universe is simple enough to be divided into two parts.* I like Gilb's Planguage approach of hierarchical requirements -- no more than 7 at any given level in the hierarchy. Since you can end up with several thousand requirements overall stratified into many, many levels within the hierarchy, I think that exposes the weaknesses of 2-level organizational schemes.

*"There are two kinds of people; the kind that divide the world into two kinds of people, and the kind that don't"

Well, I agree and disagree! I think you can talk about problem space AND solution space. But I also agree that one person's solution is another persons problem. The first issue is how do you tell that you truly understood WHY (as Steve Tockey) you are doing it if you have no idea of the problem? The second issue is how do you know you need to "educate" the customer (as Steve McConnell) if you are "required". Either of the two above answers is of little help to the zillions of people who ask something like, "What goes into the Marketing Requirements and what should go into the System Requirements". Or the related, "What should I validate against and what should we verify?" Whatever spews out of a customer's mouth? The issue here is being clear on what you have asked me so solve or build for you. That, as far as the customer is concerned, should be a black box. If that "thing to solve" is a car, then the entire car is a black box and defines the solution space. People, trasnsportation infrastructure, rules & regulations are the problem space. If the customer askes for a wood streering wheel, then they have ventured into the solution space and you can say nicely, "Good idea, tell me more why a wood steering wheel is important," because you know they are out of their domain. It may be the best idea but treat it now as an idea. If that "thing to solve" is a transmission, then the engine, chasis, people, transportation infrastructure, etc. is all part of its problem space. The deal is here that without being clear of what you want me to solve/build, I have no basis to know if you have given me just one solution that may or may not be an appropriate solution or a improved understanding of what we are trying to solve. Because let's face it. The customer will start talking in the problem space becasue that is all they know. Just becuase they say it doesn't make it right. It makes it an important clue to find out what it is they are trying solve.

Earl's second issue first: '... how do you know you need to "educate" the customer (as Steve McConnell) if you are "required"?'. That's what the "Five Why's" technique is all about. Literally every time a customer gives you a "requirement" you should turn around and ask "why is THAT the requirement?". One of two things will happen. Either they will go into a long, drawn-out explanation or it will be as simple as "Well, if we don't do that then my business won't work". In the "my business won't work" case, you've found the real requirement. In the long, drawn-out explanation case, analyze the explanation and it will guide you closer to the real requirement. You then turn around and ask "why is THAT the requirement?" about the statement that was closer. The technique is called "Five Why's" because you almost always run into the "my business won't work" answer before the fifth cycle so going for five cycles virtually guarantees you'll unearth the real requirement.

On Earl's first issue: "how do you tell that you truly understood WHY (as Steve Tockey) you are doing it if you have no idea of the problem?". This is one of the reasons why I'm such a fan of the "perfect technology" approach and OOA modeling of requirements. The OOA ends up being a precise model of the business policies that need to be enforced and the business processes that need to be carried out by the software, completely independent of any and all technology. As I say, "Every software system exists to automate somebody's business (however abstract that business might be). If I'm going to be successful at automating their business then I need to understand that business at least as well as--if not better than--they do". The OOA is literally a blueprint of the business. Knowing what needs to be accomplished independent of technology allows me to propose multiple technology-dependent solutions and evaluate them to find the best one.

As Earl has been teaching the course at my company the "Problem Space vs. Solution Space" concept has really helped us with the major problem of trying to get to the underlying needs of the customer. Marketing so often gives Engineering the solution with no rationale or background to the problem. I think modeling is useful but models are constructed as the output of conversation. When discussing the "Problem Space" using the words "the user needs..." or "the user can..." often keeps us out of early solution space discussions (which we all like to do). - Jan

 

 >The technique is called "Five Why's" because you almost always run into the "my business won't work" answer before the fifth cycle so going for five  cycles virtually guarantees you'll unearth the real requirement.

Or is it just that well before the fifth why the customer has strangled the questioner?  :) 

When I tell people "the customer is not always right", I often get into a debate about the customer paying the bills so we have to do it the way they said. The customer often doesn't care that a drop down may make the application more difficult to use or violate UI guidelines. But what if the customer wants us to do something that is illegal or not ethical? That's usually where I win the debate. If we all think of ourselves as consultants, even if that isn't our job title, it makes these kinds of decisions easier. Our customers have accountants, lawyers, investment counselors, etc that they turn to for advice and they may or may not listen to them. I think the job of software construction is in many ways, similar to those people...we do things that make the customer's business run better and in turn, hopefully, make them more money.

I work for an ISV that sells software to the government and I sometimes get requirements from marketing that violate the Americans with Diablities Act. Clearly the requirements are flawed as we can't sell to the government in this case. I then become the consultant and go back to marketing to tell them why things can't be done how they've said.

So, how do you separate problem space from solution space? I've found that Use Cases help me define what the user needs to do without saying how the software will do it.

 

I agree that the customer *isn't* always right, but they do have the final say because yes, it is in fact their money that's being spent.

The customer may not care if the drop down makes the app more difficult to use or whatever. My point here is that "doing our duty" involves pointing out what the implications of their decision will be.

For things that are relatively minor--like a usability issue--I can live with a customer making a wrong (IMHO) decision. I let them know the consequences and they wanted to go that way anyway. Fine. It's their dime.

OTOH, if they are asking for something illegal or unethical then it's a whole different story. I see two options in this situation. One is to point out the illegality/unethicality and put in place adequate documentation that if/when someone gets caught (as often happens) then my rear end is covered to show that it wasn't my decision to go that direction. The other is to start shopping for a new customer...

I may be wrong but it sounds like everyone posting here does contracting work rather than working for a corporate IT department.  In the case of contract work the customer really does decide on all requirements because it is their money.  If the customer insists on doing something stupid, and you fully explain to them why the request is stupid, you've met you professional obligation and should do as the customer requests.  You really can't stop someone from doing something stupid if they are intent on doing it, if you refuse to do what the customer wants they can always find someone less principled that will be happy to do the job for them.    

If you work in a corporate IT department you are a little more focused on ensuring that correct design decisions are made.  There is an exceptionally large incentive to do this given that you most likely will maintain whatever system was developed.  In addition if you are an employee of a company you have a responsibility to ensure that resources are not wasted.  A profitable company increases the chance you will continue to be employed and might even increase the chance you receive an end of year bonus, if you company happens to give employees a bonus.      

 

 

I think our task is to make things clear to the customer. It is common that a customer states his requirements in solutions rather than the real requirement. In that case we have to split up the requirement in to things: the 'real' requirement and the solution that is proposed. In the example mentioned the first would be that the user must be able to choose between four items. The second, that this requirement must be implemented through a drop down list.

The first is a functional requirement. The second is a special type of a non-functional requirement: prescribed solutions or design constraints. We will find this type of requirements on many different levels. It differs from the platform we will have build the solution, through for example the framework that should be used, to the detailed level of the example of the drop down list.

By splitting up the requirement in two, we have to find the rationale for both. In that way, we have a means to discover if there is a real reason for the proposed solution. If there is no rationale, there is no reason to cling to the solution. If there is, you can deliberate wether the requirement is conflicting with other requirements and if there is reason enough to cling to it.

And of course, if your project encounters many requirements on this detailed level, it is time to discuss with the customer if this is what he really wants. Feed him with the consequenses like an inconsitent user interface, increasing costs, and so on.

I like to think of it as a requirement that is in the problem space as fixed and one in the solution space as flexible.

A requirement in the solution space should map to a requirement in the problem space but should ALWAYS have at least one other requirement that you have or can discard.

So for the "We've got to have drop down list of four items" (which in itself is a terribly worded requirment!) you might have something like:

• PS1: The user needs to be able to choose one item from the set of wibbles
  • SS1.2: The user is presented with a drop down list of wibble items, of which four are visble and from which they can select one
  • SS1.2: The user is presented with a full list of wibble items with a radio box next to each and are able to select one
  • SS1.3: The user is present with a list of wibbles and a text entry box. Each wibble is selectable and if clicked on the text box is filled in with the name of the wibble. The user can type in characters and the list is narrowed to show only wibbles whose name starts with the currently entered characters

Where you have only one solution to a requirement you should probably always go back and add another one!

Then if your working with a language or toolset that allows rapid development and feedback you should try more than one solution and let the users decide what they like better

Steve Tockey:

So it should be clear now that a customer could, and for very good reason, decide that they "got to have a drop down list of four items". Maybe they've thoroughly considered all of the alternatives: radio buttons, text fields, etc. for accomplishing the same thing and have decided that no other alternative than a drop down list is acceptable to them. Therefore it's not the developer's choice. It's a requirement.

 

To me, if the developer is not free to choose the implementation then it's constraint rather than a requirement. The requirement is the ability to select something. As a constraint it should probably be stated that radio buttons or text fields are not acceptable user interface elements. It should be clear to the customer and the developer that such constraints are negative in nature since they will negatively impact the performance of the contract. We also need to make a judgement on the fairness of the constraints since too many constraints could make performance impossible - a breach of contract.

As a contractor, once my client tells me how to do something, they have breached our contract since its a contract for services rather than a contract of service. This has legal and tax implications, in the UK at least. The money I make from a contract comes directly from my fee. Within that I have my costs and my profit. I have to be able to choose my implementation since I must be able to profit or lose by my choices. If I am not free to choose, that is I have been unfairly constrained, the revenue can declare my contract with my client a sham and claim tax on my fee rather than on my wage. In return I can claim employment rights from my client.

The legal and tax implications go away on in-house projects but the problems remain. It would be as well to operate as if the customer and the developer were separate entities even when they aren't.

Paul,

 You are incorrect in who defines the requirements of a system.  Requirements are defined by the customer given that the customer is the one actually paying for the work.  The developer's job is simply to take the requirements as stated by the customer and develop a system that meets those requirements. 

Steve Tockey:

OTOH, if they are asking for something illegal or unethical then it's a whole different story. I see two options in this situation. One is to point out the illegality/unethicality and put in place adequate documentation that if/when someone gets caught (as often happens) then my rear end is covered to show that it wasn't my decision to go that direction.

 

Perhaps a bit off-topic, but I think this only applies to the unethical part of the equation. The illegal shouldn't be done regardless of how much documentation you get. I will indulge in a bit of hyperbole here and mention that you can't get away with saying "I was just following orders".

 

Kevin 

Scott Dickinson:

Paul,

 You are incorrect in who defines the requirements of a system.  Requirements are defined by the customer given that the customer is the one actually paying for the work.  The developer's job is simply to take the requirements as stated by the customer and develop a system that meets those requirements. 

You're oversimplifying the relationship between the customer and the developer. My customer can ask for whatever they want, but they'll only get what I'm willing to give them for the price I set; otherwise they'll have to go elsewhere. Both customer and developer are involved in specifying the requirements. And those requirements become the performance criterea for the contract. If I simply give a customer exactly what they ask for, they'll almost certainly end up with something they don't want; and I won't get any repeat business.

Paul,

I never indicated that the process does not include some amount of negotiation on what type of system you build.  You negotiate with the customer on what requirements will and will not be included in a project, you negotiate on a price that will be charged to develop the system, you negotiate on quality issues, you essentially negotiate on every aspect of the project when the work is being done on a contract.  Still, in the final analysis, the customer has the final say because they can either accept your proposal or reject it and go with another vendor.    

I also never indicated that you are forced to produce low quality systems simply because the customer is demanding that you do.  My father was a systems analyst for over 30 years and the only advice he ever gave me was to ensure that you always give the customer what they need, not simply give them exactly what they are asking for.  In reality, if the customer is really making unreasonable demands, you always have the option of refusing to do the work.  If the customer is exceptionally difficult to work with you probably don't want the work anyway.

Sometimes the customer comes to you with a problem and you are given the responsibility of solving the problem.  In these instances you have a partership where you work with the customer to analyze the problem and define what is required to solve it.

In other cases the customer does the analysis themselves and gives you their solution which you are required to impliment.  In these instances the customer becomes exceptionally upset if you try and do something that is different than they requested.  It really does not matter if the solution you personally come up with solves their problem, they get upset that you failed to do exactly what they requested.  I have a friend that is an IT manager that literally got yelled at for taking the time to develop a inexpensive solution to a problem because he did not do exactly what his customer wanted him to do. 

It is true that the developer or system analyst works with the customer to define what is reqiured to solve a problem.  The customer then makes a final decision on what ultimately is within and outside project scope.  I am not sure how long you have been developing systems but I have never heard of a developer being able to include requirements in a system if the customer did not approve them or is not willing to pay for them.  As I said, in the final analysis the customer have final authority on what is included in the project. 

 

Scott Dickinson:

I never indicated that the process does not include some amount of negotiation on what type of system you build.  You negotiate with the customer on what requirements will and will not be included in a project, you negotiate on a price that will be charged to develop the system, you negotiate on quality issues, you essentially negotiate on every aspect of the project when the work is being done on a contract.  Still, in the final analysis, the customer has the final say because they can either accept your proposal or reject it and go with another vendor.

In my final analysis, either party can walk away. This is the ultimate veto and both parties have one. If I allow my customer to direct what I do then I put myself in the service of that customer. This turns our contract (regardless of what may have been written beforehand) into a contract of service with all the legal and tax implications I wrote about before. My customer can require any product I am able to make. But to retain the status of a contract for services I must be free to make it in the way that I see fit. If I don't retain that freedom, my customer can cut into my profits (which are part of the agreed price) by requiring that I take a needlessly expensive route. It is only right that such an action be considered a breach of contract.

Here's a term that contractors in the UK are encouraged to include:

“The client shall not control, nor have any right of control as to how the company is to perform the services. The client recognises that the company offers specialist services at a high level of expertise and as such the company cannot be told how to perform the services or the manner in which they are to be performed.” from Contractor UK

 

Here was one situation we found ourselves in one of the project:

In the initiation stages of the project, a very high level requirement was done. It seemed to indicate that this could be a problem that seemed to fit "Business rules" space. We then had to understand the business rules space - so had some vendors do some demos.
Next was the deep dive stage - when requirements were getting detailed out. After quite some time and lots of discussion later, we figured that the business consultants and business analysts were looking at this as a Business rules issue and trying to describe things around it!
This is when we used problem space v/s solution space technique. The "business rules" was categorized as "solution space" and the team concentrated on just "problem space" a.k.a. business requirements. Later in the project, after the requirements were laid out, the solution approaches were looked at. It turned out that a business rules engine alone could not possibly solve the business problem we had at hand.

So - Though not all requirements process can use the solution space v/s problem space definition; it is a technique that could be used in certain situations - In this case  it was used  to  just  set the  mindset  in  certain (right?) direction.
 
Thoughts, comments -  welcome!

- A

I think that this story illustrates why approaching the requirements work with concepts of "problem space" and "solution space" is so powerful. It allows the requirements analyst to work with the customer to fully define the problem/opportunity. Now, as a customer, I can define the problem with enough detail that only one or two solutions will possibly work. For example, instead of saying I want to use Fubar as my database software, I can say that we have 10 years of Fubar knowledge, are fully skilled in Fubar programming, have Fubar support staff, and that any solution must not increase our database support costs. Now the solution designer can either choose to use Fubar OR better be able to explain how Bufar database will meet my requirements.

I find that situations where "business rules" are actually procedures steps embedded with the current technology. A business rule that each person must sign off on the routing slip on department communications is an example that is married with paper technology. I remember working trying to implement the "business rule" until we discovered that it was in the solution space. The problem was that we needed to make sure that everyone had a chance to read the department communication (we couldn't confirm that they read it, even under the current system). The use of email solved that problem without using a routing slip. We could solve the "problem space" requirement without using the old technology solution.