8 reasons why XLS is pants capturing requirements

Your users often don’t know what they really want. They think they do and express their needs as Business Requirements. Your job as an analyst is to try and interpret them and understand what is really required.

But first, you need a consistent way of capturing, managing and analyzing the requirements. The tools used by your IT team are too heavyweight and complex. You could build an app. But where would you find the time? So instead most people reach for a spreadsheet or create a huge requirements document. It seems quick and easy, but in the long run it will kill you.

"The top reasons for project failure are incomplete requirements 
and poor scope control"

Standish Group – 25 years of research into project failures

8 reasons why spreadsheets are a bad idea.

1. Requirements have a lifecycle that needs to be formally managed. Everyone should be able to raise and submit a requirement. But after that, it needs to be formally assessed, prioritized and managed.

2. Requirements are more than a wish list. They need supporting information which could be notes but may also be in external systems; documents, webpages or screenshots, photographs of sketches on whiteboards..

3. Requirements need analysis and investigation. Every requirement needs to be considered in the context of the business and technology to understand how to implement it. They do not sit in isolation.

4. Requirements need collaboration. To assess and understand what is required takes a combined effort; the user who submitted, architects, Salesforce Admin, IT.

5. Requirements need traceability and line of sight. This is linkage from requirement to business processes impacted to release that it is implemented in.

6. Requirements need to be grouped and prioritized. Business changes and technical implementations are phased in releases. Requirements need to tagged to one or more releases so they can be filtered.

7. Requirements are created during process mapping. As the business processes are captured existing requirements are incorporated and new requirements are identified. Requirements add detail and context.

8. Requirements need enterprise scale and security. They live beyond the life of a single project and should be managed and controlled in an enterprise app.