It is a well known problem that developers working on a platform have the worst time in their life trying to map the user requirement to the platform capabilities, wasting countless hours in requirement gathering and wasting more time in re-building the solution that was basically structured on assumptions. I faced solution that whenever a customer say Form the developer interpreter it directly to list. Remember you are building a solution to a customer not to yourself.
My Name is Muhammed Nabil I'm a SharePoint TSP with 6+ years in System Analysis, in this series I'm going to take you in a journey of how to gather requirements for SharePoint 2010 solutions. In this series we will cover:
- Functional requirements, from user profile and security group to site structure and SharePoint governance.
- None-Functional requirements, from capacity requirements to Hardware sizing.
First I'm going to start with the top 5 mistakes in gathering SharePoint solutions:
- Don't enforce SharePoint capabilities, educate your customer about the benefits and the workarounds.
- Solution match the requirement not the contrary.
- Site map is not the site structure, when creating site governance work bottom-up.
- SharePoint is scalable, use it for rapid development and agile approach. Don't rush the requirement gathering process.
- Build the user groups and security model up front, and enforce it with the site governance.
in the next part we will break down the requirement gathering phase, and how requirement gathering documents are structured and matching it to the SharePoint solutions.