Let's face it, most business users know what they want but struggle to express it clearly enough for developers and testers to produce applications that meet their needs. This dilemma usually reaches its unfortunate zenith when IT makes its delivery and the users can be heard muttering, "Is that what we asked for??"

Why is it that business requirements are so hard to pin down?

Maybe it's the language we're using. Wayne Hom, CTO of Augmentum (a contract software development provider) said this: "Even among native English speakers, different people can interpret the same set of words in different ways. Expand this to a global scope of international English, and the problems only grow worse." Users and developers talk differently because they think differently, have been trained in different disciplines, use different tools, and have (very) different vantage points. This creates a natural communication gap (some would say chasm) between the user and the developer that very commonly results in disappointing deliverables.

So how do we bridge this communication divide and correct unproductive development cycles?

First, let me state what I believe is not the answer . . .

1. Developers minimizing or neglecting user input during the requirements definition phase in order to simplify the project.
2. Users glossing over development difficulties and details.
3. Developers pretending that they understand the users' needs when they do not.
4. Users ignoring developer input when the developer knows better what the user really wants or needs.

So what's the answer? Below are my "Top-10" suggestions for shortening the requirements phase and giving it more precision, so the final deliverable fits. Some of these approaches are made possible only by the graphical nature of Workflow Solution and the way it's able to communicate with business users. That's the reason I wrote this article and that's the reason I'm confident others can benefit from these suggestions.

My Top-10 List

1. Have an agile software development mindset. A proven way to increase customer satisfaction is to adopt agile software development methodologies which value responding to change over following a set plan. This means a developer's mind-set will welcome changing requirements, even if they are late in the development cycle. Exploit the fact Workflow Solution supports iterative production that delivers smaller working versions of the software on a more frequent basis.
2. Remember your users have higher expectations than they used to have. The industry's movement to cloud computing has driven user expectations even higher. They know, if not from their own experiences inside your company, what their colleagues and counterparts at other companies are saying. In short, the secret is out and users know their requests can be met, and met in much shorter development timeframes than just a few years ago. And they expect periodic simulated process reviews, not a single 'big bang' UAT step at the end. Know your audience.
3. Hold your users accountable for what they request. In your discussions about particular requirements, in a non-threatening way, make sure users know their choices and decisions will be documented in the official spec log along with their initials. This step helps eliminate the, we didn't ask for that conversation downstream and holds users personally accountable for their requests.
4. Get Q/A and testers in early. Depending on the size and complexity of a project, QA/Testing can play a defining role in its overall success. Don't forget to include them in the early design sessions so they can make contributions, and equally important, get a jump on developing their own test plans and test strategy early in the development cycle. It's too costly for testers to identify design problems after implementation. Get them involved early.
5. Use Workflow Solution to model the process. Since the tool looks and feels a lot like Visio, use it to model your process from the start. Users are able to follow the process diagrams you build, and in reality you've already started the development effort on your project, thus killing two birds with one stone.
6. Build prototypes early in the design phase. With Workflow Solution you have a tool that allows you to rough out a portion of the overall process and show it to your users. Pick meaningful bite-sized pieces of the overall process, build it, and then show it to your users using the tool's simulator/debugger feature. Make sure they are satisfied with the individual pieces before you connect up the overall process. A little extra time spent upfront visually reviewing these smaller segments with your users should save you enormous time (and frustration) down-line.
7. Document as you go. Documentation is often overlooked in a project until the final step. Because the tool provides a number of inclusive ways to document the process you're building, I suggest you include documentation as you go. Here are the ways I document my projects using Workflow Solution:
   1. Rename all components with clear descriptive names;
   2. Add extra "Annotation Components" to the process as needed;
   3. Add useful documentation under the "Model:Primary / Documentation" tab (found to the left of the Component Toolbox);
   4. Create an HTML report at the end using the "Model Report" function found under the "Plugins" drop-down menu in the Designer.
8. Include frequent design review sessions with the users. Don't be afraid to hold short 30-60 min meetings with your users to review the progress, direction, and assumptions you've made. These sessions should be scheduled on a regular basis. Again, the graphical nature of the tool encourages great communication and gives you confidence you're on the right path. And one of the most rewarding things you can do during these sessions is make the users' requested changes and suggestions on the spot, and then show it to them using the simulator/debugger feature.
   
   **Warning - I've found this can be a two-edged sword as well. Once users/managers see how easily changes are made and how little effort it takes on your part, they are much more likely to ask for the moon. Manage accordingly . . . you've been warned :)
9. Include managers in some of your review sessions. Managers are painfully aware of the historical miscommunication that has occurred in past development projects. That's why I suggest you invite them into some of your design review sessions so they can see firsthand how well the two groups are able to play together using Workflow Solution. The cooperative atmosphere, clear communication, and newfound productivity in these meetings will give your management team much needed hope.
10. Keep end-user expectations in mind. Remember that the application you're building is no longer something you're developing behind the scenes in a lab; the application is literally what the user sees. And typically what the user sees and what a developer does are two different things. That means you're going to need to think differently. Think from a user perspective. See things from their eyes. Put yourself in their shoes with their deadlines, demands, pressures, etc.

I recently read an interesting SDTimes article on the web (written by Tina Gasperson, Oct. 15, 2008) that included a number of quotations that directly relate to the topic at hand. I hope these quotations will help give a broader perspective on the necessity of involving users in the overall application development cycle and the benefits one can realize from doing so.

Bola Rotibi, an analyst with MWD Advisors: "The customer doesn't know all the technology required; they just have a need, which they express in the language you and I communicate in. Because the customer doesn't know all the technical aspects of creating an application that meets the need, requirements are often too loose and vague."

Bill Gates, Chairman, Microsoft Corporation: "It is important for testers and developers to have exposure to [their] customers, but it should be different from the program manager's exposure."

Bj Rollison, Testing Architect, Microsoft Corporation: "Microsoft relies on program managers to translate customer needs into reasonably unambiguous requirements and build prototypes early in the design phase. Relying on developers to design a software program would be similar to relying on an engine mechanic to design a car. Engine mechanics could probably design a car with some really cool bells and whistles, but the only truly satisfied customers would be other engine mechanics."

Imad Mouline, CTO of Gomez: "Look at the application from the outside as early in the cycle as possible. Things perform differently with client-side processing; are you taking that into account when doing performance testing? The response time of an application is influenced more by the client-side rendering time than by the network or server."

Ron Schmelzer, senior analyst at ZapThink: "If you design a system so rigid that you have to get it right the first time, it's guaranteed to fail. Developers would much rather the requirements be well defined and not change. It would make life so much easier. But that's just not the reality."

"The best way to act is incrementally, meaning that you design bits; you don't design a huge system. You plan to go back and revise the things you've designed, in an agile way, to reduce the penalty of being wrong. The cost of each change has to be low. We have to be judicious. The dollars we spend can't just be 'pay and pray.' We have to be cost-justified in this environment."

Wayne Hom, CTO of Augmentum: "If you look at most development, requirements are viewed as an input into the development process. What we need to do is simulate, as early as possible, the software experience for the users. That 'virtual reality' experience of the software before it is ready lets users refine their conceptualization of requirements and provide feedback to QA so that all the bad news is vetted out early. Making the user experience the driving process of software development rather than a support process is the key to creating the simulations quickly and cost-effectively."

Mark Eshelby, Director of Product Management, Compuware: "Collaboration is the key. You do this by helping everyone to sing from the same sheet. You're not asking QA to weigh in and say, 'I don't think the button should be here,' but you're giving them an opportunity to say, 'Did you think through all the details?' If QA is a part of the communication beforehand, they can help figure that out. Bringing in QA at the beginning of the project also lets the team get a jump on testing. They now have extra time to generate test plans for validating the requirement so that tests are ready and available earlier in the development life cycle."