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:
First I'm going to start with the top 5 mistakes in gathering SharePoint solutions:
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.
where is the "next part" of this requirements gathering best practices ?
Ditto....the next part..your on a roll...
Could you explain :
Site map is not the site structure, when creating site governance work bottom-up.
It would be good to see the next part, has anyone found it ?
I have a question related to the non functional requirements. My client wants a site that looks good and is eye-catching. But I do not know how to document it in the requirements document. (A requirement like - The site should be eye-catching - is not measurable ). Please can you give a few pointers about the non-functional requirements especially the "look and feel" aspects.