Gathering Business Requirements
Quality business requirements offer tremendous advantages to a project. In addition to the rapport that they help to build with the client who feels that they have been understood, they produce the following benefits:
- They create an unambiguous picture of what needs to be delivered
- They define the metrics for project success
- They help to produce more accurate planning and costings
- They help with scheduling and resourcing
Business requirements should be written in such a way that they are understood by business users. Technical jargon should be rarely included, and if it is, the jargon should be well defined within the requirements document.
Related Content
Many analysts fall into the trap of defining technical requirements when business requirements are defined. For example, the requirement to "include VPN connectivity between Internet connected laptops and the corporate WAN" (*1) is not actually a business requirement. The real business requirement may be to "provide secure, encrypted connectivity between Internet connected devices and the core corporate services - email, web and applicationX." (*2).
So what is the difference between the two? There are a number of major differences between the two phrases;
- The first requirement uses technical jargon, this immediately alienates business users who may or may not understand what the 'VPN' will enable them to do. One could create a VPN with no access to some core services and technically the requirement would be satisfied even though the client would not. The engineer who eventually designs and implements this solution is given no indication about what specific services need to be tested in order to comply.
- The first requirement limits the possible solutions. There may be better alternate solutions to a VPN that are instantly eliminated due to the phrasing of the requirement.
- The second requirement is easily tested and verified by any business user. It does not require an Information Technology professional to confirm success.
- The second requirement is clear in terms of the services that the business needs from this solution. This ensures that no additional time or effort is wasted trying to make other applications work that don't need to.
Business Analyst Career Pathways
Strategies for Gathering Requirements
1. Identify the key stakeholders for the business requirement. Projects normally provide this information on initiation, but sometimes it is necessary to include additional business units in order to complete the business representation in the solution.
2. Identify relevant contracts, agreements and documentation. These include road maps, strategy papers, vendor agreements and architectural documents.
3. Seek input from the business representatives regarding their business practices, concerns, thoughts and expectations relative to the project deliverable.
4. Collate all documentation and business inputs identifying in scope and out of scope business drivers relative to what the project is capable of producing.
5. Analyze all the in scope items and articulate them into a document. Ensure to avoid ambiguous words such as 'better' and 'streamline'. Consider a complete stranger reading those requirements - if they would make sense to a stranger with no background knowledge of the project then they are clear.
6. Seek endorsement from the stakeholders, the document should make sense to any key stakeholder identified in step 2.
