Identifying software requirements without confusing business users.
The “user community” for your software project doesn’t know what they want, so how can you? Like it or not, you have to pull ideas out of their heads and move everyone toward a common goal. It’s not easy, but it’s not as tough as it sounds.
We know that many software projects fail and that insufficient requirements analysis is the most frequently cited cause. But think about this: Analysis requires collaboration. Developers tend to speak in terse, acronym-filled sentences. Business people tend to talk about their problems and issues. Neither side truly understands what the other is saying, leading to false expectations and broken promises. How can you possibly analyze requirements in this environment?
Software professionals argue that the business people don’t know what they want. That’s partially true. How can they be expected to know what technology can do for them? Advancements in the field occur so quickly that what was almost impossible yesterday is commonplace today. The business folks, in turn, argue that developers aren’t focused on their needs. True again! Too often, developers are overly focused on technology. Business people don’t care. Just give them a solution that works reliably!
So how do you cross this chasm and get to a common ground?
One long-standing approach is to create a massive requirements document and get all the major players to sign it. I’ll bet many of you have been there and done that. It doesn’t work! Such documents are impossible to fully comprehend and are subject to widespread misinterpretation even if you can get key players to take the time to read them. They’re also a nightmare to update as requirements evolve.
How about creating a monstrous spreadsheet with all the features listed, along with priorities and stakeholders? Have you done that, too? It doesn’t work either! Technical professionals tend to like this approach because the spreadsheet serves as a checklist for implementation. Unfortunately, most people have trouble piecing together discrete functions into a coherent software application. Thus, their expectations of the final result will be wildly different.
There’s a better way.
Instead of writing, get into a room together and talk about the problems to be solved. Don’t concentrate on getting every detail in writing. Focus on extracting ideas, issues and needs. Communicate!
For example, if business users say they want to store information in a database rather than on paper forms, uncover the reasons why. Are they running out of physical space to store forms? If so, perhaps all they really need to do is scan the forms to create image files and store those images on a file server.
Is the goal to continue filling out paper forms while simplifying searches for information in the future? This is a more complex problem requiring optical character recognition or online data entry with the results stored in a database.
Or, do they want to enter and circulate information electronically and eliminate paper forms entirely? This is the most complex problem, requiring extensive design sessions. Business processes will have to change, and some level of retraining will be needed.
Developers have a responsibility to educate and inform. Talk to the users about trade-offs. Show them the risks and complexity inherent in trying to do too much, too fast. And don’t forget about cost and time. There’s never enough of either.
Time to start drawing.
Move to the whiteboard and rough out a solution. Crude? Yes. Effective? You bet! As you begin to capture major ideas and process flows, start to prototype the user interface with whatever tools you have available.
If you’re good with HTML, a browser-based user interface can be created quickly and inexpensively. You might choose a GUI development tool or even a PowerPoint presentation. Regardless of the tool, the goal is to mock up the major functions of the software in such a way that everyone can see and touch the result. Now you have multidimensional requirements. These have much more value than thousands of one-dimensional words organized onto reams of paper.
The software team will have a model for starting the build process. This model can readily be turned into use cases or stories depending on the development approach being used.
Business workers don’t need the latest technology. They don’t care about standards wars or programming languages. They need software they can really use. Give it to them!