I will admit that I have been very silent over the last year. There are a variety of reasons, but one of the primary reasons is that the focus of my work has been evolving with the new world of the cloud.
First, I want to wish you a Happy New Year! I hope this coming year is a great one for you and your family. Of course, the new year usually brings with it resolutions — the things we hope to accomplish or change in the upcoming year. So, as it relates to SharePoint, here are my goals for this year:
- Gain a better understanding of Silverlight and begin building solutions around Silverlight and SharePoint to deliver RIA applications that can run both in and out of the browser.
- Obtain the new SharePoint 2010 certifications for both Configuration (70-667) and Development (70-573).
- Begin investigating and using third party applications within the context of solutions delivered to clients (primarily Nintex Workflow 2010).
- Submit new articles for consideration by the new Nothing But SharePoint website founded by Mark Miller, Joel Oleson and Jeremy Thake.
- Contribute to the new public SharePoint blog to be published by Tribridge, my current employer (I will provide the URL once the blog is available).
- Learn more about social computing and how use the existing Social Capabilities of SharePoint 2010 to improve business communication. Also to understand when and how to expand the Social Capabilities of SharePoint 2010 for use within business.
With these goals in mind, I expect that many of the articles published on this blog are going to revolve around Silverlight, SharePoint 2010 Client Object Model or WCF Data Services, Social Computing and ways that third party components can enhance the development experience within SharePoint.
I’m looking forward to learning new things and sharing those experiences with the community. I welcome your participation and insight as we learn together. Again, Happy New Year!
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!