The Requirements Process

Written by Mani Ramasarma on August 14, 2018. Posted in Articles.

While it is second nature to many of us I thought it would help to put this up here – the various steps involved in eliciting, documenting and baselining requirements.

Do not be overwhelmed by the number of steps, over time it will all flow in one seamless sequence.

1. Identify stakeholders

Who are the stakeholders? A person or persons with an interest or concern in something. Google and you will find anywhere between 4 and 14 types of stakeholders. I look at stakeholders as project stakeholders, requirements stakeholders, etc. There could be some overlap but not always. For example., a VP could be a project stakeholder but not a requirement stakeholder. Project stakeholders are generally listed in the Project charter/concept document. Requirements stakeholders will be listed in the BRD or any variant of that. Keep the following in mind:

These are folks who will be using the system or affected by the system
Identify any ongoing projects or upstream/downstream systems that are likely to be impacted
Include all people in your list of requirements stakeholders.

2. Do you have a Statement of Work (SOW)?

In case you are buying a COTS product and have released an RFP, it is very likely the RFP contains a SOW that defines the high-level scope of the project. Should there be none start by defining the high level scope. Why? It is easy to define high-level scope and then distill into the detailed requirements. The possibility of getting stuck in the weeds is way too high the other way around.

3. Organize the requirements kick-off session

Here are the things to do:

Invite all stakeholders, project, requirements, etc.
Set the agenda and stick to it
Lead the session
Explain the 5W’s and 1H – who, what where, when, why and how of requirements.
Elaborate the requirements quality – Correct, Unambiguous, Complete, Necessary, Feasible, Verifiable and Traceable
Insist that ‘you’ understand the requirements. Documenting is impossible without a good understanding of the requirements.
Record the session (Announce it at the beginning., not all organizations view this favorably)
Circulate the summary of the discussion and seek feedback on a no-objection basis

Many times the stakeholders are not aware of the aspects and quality standards of the requirements. They also are under the impression that you, the BA, and they are on the same wavelength and understanding. It is better to clear the air upfront.

4. Check and validate AS-IS process

If the organization maintains an updated AS-IS process, I recommend buying a lottery ticket! You may be really lucky. Have the AS-IS process validated by the stakeholders to ensure it is up to date. If you are not lucky, document the AS-IS process. Simultaneously prepare a stakeholder interaction map that represents what transpires between any and all stakeholders. This is important as it can identify stakeholders that were missed in the first step.

5. Document pain points

For each of the AS-IS business process identified above critically evaluate with stakeholders the pain points. One way to do this is to mark the points on the process flows where the stakeholders feel things could be improved. Unless you are re-engineering the whole process, the pain points must be addressed as part of the requirements. On your part identify steps in the process that do not add any value and discuss with stakeholders the alternatives.

6. Identify high-level requirements

SOW/ high-level scope and pain points should serve as a good starting point to come up with high-level requirements. Share the list with the stakeholders and identify any missing ones. Ideally, there should be no more than 8-10 high-level requirements. Provide no more than a few sentence descriptions for each of the high-level requirements.

7. Chose elicitation techniques

There are over 50 of them identified in the BABOK. Not all are relevant for eliciting requirements. Also, each situation may demand using different techniques or a combination of techniques. For example, if requirements are non-existent, use brain storming. If they are nebulous, use questionnaire.

8. Organize elicitation sessions

Have a precise agenda and invite relevant stakeholders. Not all requirement stakeholders need be present in all meetings. It is not a good use of their time. Manage the sessions as things can go off-track very quickly. Record the sessions so that they may play them back if things are not clear. Circulate summary of discussion the same day and seek feedback on a no-objection basis. Give a day’s gap between elicitation sessions for you to document the requirements else you may not remember all that was discussed.

9. Choose the right template

Do not overdo the template. They merely provide a structure to the requirements document. The content is very important. Focus on that. Standard BRD templates have many sections to fill. Discuss with your organization if some of these sections can be left out. Of course, certain sections like an overview, in scope and not in scope items are mandatory. AS-IS process and TO-BE processes can be documented separately and references in the BRD.

10. Document requirements

It’s now time to document the requirements. Keep these in mind:

Quality standards
Do not combine two requirements in a sentence
Use a simple, active voice
Ensure logical flow to requirements. For example., checking user authenticity must precede every other requirement
Re-read the requirements, confirm they make sense and there are no conflicting requirements
Avoid implementation details as part of business requirements. For example., system must support multi-threading or parallel processing or JSP’s or some similar thing.
Don’t let existing system cloud your thoughts
Provide examples and samples where possible. It provides a lot of clarity

11. Define test scenarios

V-model suggests that test scenarios must be created along with business requirements. Not just positive but also negative test scenarios must also be considered. This is one way of identifying missing requirements. The scenarios will be elaborated into test cases at a later stage. Keep the following in mind:

For each requirement identify one or more scenarios
Always include negative scenarios
Role based test scenarios must be considered if they are important
Downstream and/or upstream test scenarios are important if systems are going to be impacted

12. Peer review artifacts

This is absolutely essential. Share the BRD; AS-IS flows, pain points, test scenarios and all other artifacts with a peer or a senior BA. This will ensure the requirements are of quality and every requirement is captured. It also ensures the test scenarios provide complete coverage of all requirements.

13. Request feedback

Seek feedback from business users. Update artifacts based on feedback received. If required organize more elicitation sessions to seek clarity. Test scenarios may have to be changed if requirements undergo a change. This is an iterative process.

14. Conduct sign-off walkthrough with users

This is the comprehensive final walk through with business stakeholders. In other words, it is the final chance for users to make necessary modifications, clarify requirements or add details if required.

15. Conduct walk-through with technical team

In case of in-house development conduct a walkthrough with the technical team. It also applies to COTS products or external vendors. This ensures requirements are technically feasible to implement and may require re-defining of requirements. For COTS products it gives an opportunity for vendors to identify gaps and ways to bridge it. This leads to the design phase in a typical waterfall model.

16. Obtain sign-off from business stakeholders

The final step in the process wherein business stakeholders agree on the requirements. Once done the requirements are ring-fenced and final. Any subsequent changes will result in a change request.

17. Baseline requirements

The signed-off requirements will be officially considered the first version. All changes will be incorporated and updated in this version.

Here is the diagrammatic representation of the process