Requirements and Requirement Gathering
The first phase of a project will revolve around requirement gathering. During this time, you will meet with users, team members, managers and project stakeholders to ask questions and begin to document people and processes to create an outline of what it is you will be creating or designing. Requirement documents will then be used to shape the project deliverables, create timelines and help create a clear understanding between you and the client and the goals for the project. It is usually advised that all requirements are signed off by the stakeholders before proceeding to the next steps to prevent anyone marching in the wrong direction. As the project progresses, these requirement documents will pass from the business analyst to the technical team, functional team, testers and end users, creating a single point of truth and continuity for the project goals. The best requirements will typically be written at the task level and have sub-requirements written at more atomic levels if the task allows itself to be broken down. This will permit work to be split across resources more effectively and allow for more clarity during the testing phase.
A Functional requirement will outline what the system or process is supposed to actually do. It will outline what the system must do, how it must behave, how it is expected to react to failure and how it provides the business value.
A Technical requirement will be based on all the technical functions that the system must perform or fulfill. It will outline all coding standards, logical operations, technical specifications and dependencies on development order or impacts to other systems and processes.
A good requirement document will have the following sections:
- The Author, Created Date, Date Last Modified and some form of Revision Log.
- Overview and Scope
- What is the objective of the requirement and what does it cover? It will need to answer the questions of what the requirement is, who it is for and why it is needed.
- Assumptions and Risk
- Not all questions will have answers when a requirement is written and you may never be able to document all the gaps and holes you are trying to fill. In this section, be sure to list out all items you are making an assumption on, and carefully walk the client through those assumptions. If something is incorrect, the client will either surface the answer for you or will sign off on the assumption and the risk it creates. This way, if something goes awry later on down the road due to something or some system behaving not as you originally expected, it will justify a change order or a change in direction without scrutiny from the client.
- Dependencies
- This section will list out all other tasks, processes and items that must be in place for this requirement to be completed. This will help the project management team prioritize and outline a timeline of requirements that need to be delivered.
- The Actual Requirements
- The actual requirement section can be a simple paragraph or multiple pages with text, diagrams, flow charts and other visual aides to get the message across. There is no wrong answer to how much detail is needed and it is definitely better to lean on the side of caution and over-explain so there is little room for misinterpretation when the requirement is passed on to other team members.
- Pass Fail Conditions
- The passing conditions will relate directly to the signed off requirements. Anything outside of the passing requirements will be considered a fail, so there’s no need to explicitly list out every failure scenario under the sun. This section will be the first pass at what will eventually become the test scripts.
- Glossary
- Your requirement document is going to contain a lot of language that is very specific to the client. Each client will use their own acronyms, have their own code names for specific reports or processes and new systems may use all sorts of foreign naming conventions. As you learn about these and put them into your requirements document, do the next guys a favor and keep a good glossary section.
Are you interested in starting a career in consulting? Be sure to read the full book Jack of all Trades Master of Some; An Introduction to Consulting available on Amazon.