As a BA you will naturally want to do as good as a job as you possibly can. This means capturing every single requirement relevant to the project, and detailing all possible nuances. Doesn’t it? Well this certainly should be your aim, but it is unlikely ever to happen that way. Don’t beat yourself up about this fact. Capturing all requirements perfectly isn’t really practical. Why?
Scope can change throughout a project, which doesn’t help. Difficult to capture everything if the goal posts keep moving. Changes in deadlines and budget can also effect your job. Then there is the client, probably the biggest single varying factor in any requirements gathering process. Some clients are a great help, some aren’t, some don’t really want to be involved, some just aren’t able to help very much.
But it doesn’t really matter. SharePoint can come to the rescue. As you will know SharePoint is a fully fledged project with its own expansive feature set. Just as you should consider the platform throughout requirements gathering, you can use the SharePoint feature set to short cut defining requirements. Don’t spend time asking questions about specific functionality (or documenting it endlessly) when you can simply specific specific SharePoint features. For example:
- Don’t specify ‘News items’ but instead use the out of the box ‘Announcements list’
- Don’t specify custom analytic reports, use the out of the box ones instead, found in Central Administration
- Don’t specify a custom approval workflow, use the ’3 step Approval WF’ instead
What you will need to do though, is to demo the functionality so the client understands exactly what they are getting. Oh and it goes without saying (or maybe not, as I am seeing it) that if the out of the box functionality is totally unsuitable you might not be able to use it.