Requirements Gathering

One of the issues that we face as developers is that of gathering the end-user requirements. Many of us have spent countless hours in interviews with users who describe their solution in terms of what they want to see, leaving us to figure out how to merge this with our various development tools. In most cases, I have found this leaves a very large “grey” area where the developer and user are no longer able to communicate. The developer is focused on the implementation and code while the user is focused on usability and customization – and we’ve all been faced with the challenge of having to revamp our solution because the user forgot one key requirement.

In my recent projects, our team has been piloting the use of Wiki’s to help with the gathering of requirements. Basically, we will conduct an initial interview with the stakeholder(s) of the project. In the initial interview, we are only focusing on the identification of the problem. No solutions or possible solutions are ever mentioned. Our focus is to see what the stakeholder is facing in his day to day operations, so we will ask questions based on the current problem – not the expected solution. We will also use this meeting to gather the overall goals in measurable formats. For example, our goals might be something like:

• We would like to reduce the amount time required for data entry
• We need to be able to determine how many widgets we sold in a specific quarter
• We would like to be notified anytime we only have less than 10 items in stock
• We want to be able to view the details of any specific applicant and handle correspondence in a central location

In most cases, the users are much more capable of defining their intended goals, especially when a technology solution has not even been mentioned. This will allow your team to both define the problem and have measurable goals to reach as you begin developing the requirements.

After we have gathered the initial information from the stakeholder(s), we provision a Wiki site on SharePoint and invite all of the stakeholder(s) in as contributing members. Our notes are condensed and entered into the Wiki’s home page. We then set each of the goals as a separate Wiki page and begin fleshing out requirements based on the individual goal. Each goal page has sections for data, functions, reporting, communication and security. Each requirement will be listed in one of the sections.

As the requirements are attached to each goal, the stakeholder(s) are invited to revise or make notes on each requirement. This way, the developer and stakeholder are able to work in an evolving environment that minimizes the number of follow-up and analysis meetings that would normally be conducted, and all of the notes are organized by goal.

Once a good collection of goals have been established and further defined, we take the wiki pages and flesh out an official requirements document. This document helps to define the scope of the project, the need and impact of each requirement and an overall plan that both developers and stakeholder(s) can use to better understand the document. If there are places in the document that need further definition, it’s back to the Wiki for clarification of the requirements.

The official requirements document contains the following information, and becomes the basis of the project:

• Data – What are the requirements for working with data in the solution? How will it be accessed? How will it be stored?
• Functional – What are the major functions that need to be accomplished by the solution? (This is usually the list of goals provided by the end user)
• Reporting – What type of reports will need to be provided? Will custom reporting need to be available?
• Communication – Are there any needs to communicate about the items in the solution? How will this be handled?
• Security – What type of security is needed for the solution? Will there need to be multiple roles? Who will need access? Who doesn’t need access? How do we comply with regulatory requirements?
• Software – Is there any development tools or additional software that will need to be used or obtained? Will we need to use SQL Server? How about SharePoint?
• Hardware – Will this solution need any additional hardware? Do we need a new server? What about a router or switches? Can we get that color printer we’ve been dreaming about?

Additionally each requirement is given a classification of Mandatory, Required or Desired. Mandatory requirements must be present for the solution to function. Required requirements are needed, but the system will still be able to function if they are not present. Desired requirements are nice to include, but they are not needed for the system to function. With the sign-off of the requirements document, the stakeholder understands that any non-critical changes are to be included as a future version of the solution.

As I stated at the beginning of this post, we are just now beginning to implement this strategy. For the projects that have been included in this pilot, we are finding that both the stakeholders and the developers are able to bridge the communication gap more effectively. Additionally, when the requirements document is finalized, the overall creep of scope is minimized, leaving both the end user and the developer on friendlier terms with one another!

I would be interested to know if anyone has tried something similar in their endeavors with SharePoint. Please feel free to comment!