What requirements refining techniques have worked best for you?

Question

When you need to refine requirements from your customer or customer representative, what techniques have worked best for you? By best, I mean what techniques have ultimately resulted in delivering the right product and keeping the relationship positive.

---Background---
Our customer representative group elicits requirements from our system's end users. The group hands off those requirements to the development staff, which is responsible for analyzing the functional requirements and delivering the implementation.

The initial requirements, as expected, are never unambiguous, clear, and consistent. So, there ends up being a bit of informal back and forth, along with more formal refinement in milestone meetings as we move through the development lifecycle.

What I have found is that the customer representative group gets defensive or impatient when they are pressed to rework the requirement so that it is unambiguous, clear, and consistent.

Answer 1

The engineering perspective will always be different to the customer perspective. So we start by implementing the things that we know need to happen - the core functionality, with a very basic front-end. Demoing that to the customer then helps clarify in their own mind what it is they are trying to achieve, at which point they ask for a bunch of extra features. Most of these will usually be achievable without too much pain, because we haven't yet started implementing that area of code - we focussed on the essential core. Features that clearly turn the project upside-down are usually obvious to the user as such, and get marked down for future versions.

Attempting to narrow define the requirements to early on can be difficult - the customer doesn't really know what they want, let alone the customer representative group (Why aren't your engineers talking directly to the customer?!).

Answer 2

What I've learned from a requirement-heavy defense project is that trying to pin down the system's requirements into a concise set of "shall" statements is effectively impossible, if those requirements are meant to stand alone.

What does work is to provide the facility to have elaboration for those requirements easily added. This could be additional explanatory text, test procedures, diagrams, models; anything that makes things clearer, to help capture what's intended. It's essential that both the system provider and the stakeholders agree that this elaboration has equal weight to the "shall" statements themselves.

We've used use cases as one way of capturing the behavioural aspect of the system, though more as part of the system design than the requirements. In retrospect, use cases could have helped defined the system, though the danger there is that they get to prescriptive (more "how" than "what").

Answer 3

From context I guess your customer representative group are business users, selected to represent the broader user base - rather than analysts or requirements specialists who are representing a separate population of users.

If so, the customer reps are probably not trained in delivering unambiguous requirements; so you will need to choose a technical person to do it for them. This could be a developer who has a reasonable understanding of the problem domain or it could be an analyst.

While you would probably be within your rights to send back the unclear requirements and just ask the users to improve them, they will get frustrated because this isn't something they really know how to do. What I would do is get your analyst to read the users' version and rewrite it in a clearer form - then have the users check it and sign off. You will need to invest in having someone with a bit of both technical and domain knowledge, but it will be worth it.

Alternatively, prototyping can provide a powerful way to elicit the real requirements if the users can only express them in a vague form. It can be more time-consuming than using a good analyst, but you will probably end up with a better result because the prototyping process will help uncover requirements that the users weren't aware of in the first place.

Answer 4

the absolute best requirements refining technique i've seen is quite simple: let the developer talk to the customer. Anything else inserts an unnecessary middleman, wastes everyone's time, and dilutes the customer relationship.

If your developers don't know how to talk to the customer, train them.

Answer 5

With some customers, creating a mock user interface or "wireframe" can be effective because it gives them a chance to see how the app will flow and make comments whereas they may not read a document. However, there is a risk that they will think that is a near completed app.

A formal technical review with the customer participating can also be useful, where all aspects of the requirements are reviewed for understanding.

Answer 6

At least one person needs to fully understand the business requirements. Stakeholders (customers, representative group, domain expert, manager etc..) may use different lingos or have different expectations of the issues. If the problem is complicated, it would be counter-productive for the developers to start thinking about "how to design this" before defining "what the issues are" in the beginning. (I am not saying the entire problem domain of the application needs to be understood before coding)

In that type of situation, writing things down on paper would definitely help.

1. To document the issue, you have to agree on the terminology.
2. Once it's on paper, all stakeholders can read it and correct it if necessary.
3. Once it's on paper, you can dig it up later when you need to.
4. You can use that to explain the problem to the developers.

This again can happen once at least one person understands all parties concerns and background knowledge.

Usually you can talk to the people, see sample output etc.. and figure things out if you know the domain. If not, you have to start from building Business Domain Model. Here is one way to get it out.

1. Tell them to describe the problem in complete sentences, and you write them down on the white board. You can use Tetris as an example. Describe Tetris in complete sentences.
2. Circle the nouns.
3. Underline the verbs.
4. The nouns and verbs are the starting point for the domain model. Turn them into UML Class diagram or just boxes and arrows, and try out different names. Add more lines or arrows if you discover relationships.

Answer 7

The best requirements refining technique, is to actually build something. Build a little, this can be a prototype, a concept or a raw version. Demo it quickly to the customer, get feedback.

Repeat.

Look at Agile methodologies like SCRUM.

The process of handing off from one group to another rarely works. Requirements change all the time, and you should be prepared and ready to accept that.

Have someone from the customer group embedded in your team, or even better an actual customer if possible.

Answer 8

I've heard good things about the Nine Boxes technique. It's about interviewing the customer asking him specific question to try to cover every aspect of the story.

This technique comes from a Keith Eades New solution selling book.

Answer 9

The trick is to get experienced developers (who have done requirements before) to sit down with people who will use the product and ask (over and over)....

What do you want to "do" and NOT how do you want to "solve" it.

Our customers are always asking for a solution, but we are good at boiling down to the problem, because sometimes, the solution is easier than implementing the fix the customer came up with.