Clearly defined requirements are the essential building blocks to any undertaking and eventually leads to the success of the initiative. Whether the initiative is internal to the organization, or external such as client engagements, elicitation and documenting of requirements is critical. High-quality and structured requirements will mitigate financial discrepancies, reduce the number of defects, expedite quality assurance testing, and allow for quick implementation.
At DLT Labs™ we segregate requirements between internal vs client initiatives. The internal requirements continue to develop the core products, and therefore are documented as building blocks with the intent to depict the evolution of the platform. Client requirements are documented in a fashion that captures the immediate client needs and issues. Whether this is broken down across phases, or in an entire single document, the look and feel between the documents are different.
- Product Requirement Documents (PRD) — Internal initiatives
- Business Requirements Document (BRD) — Client initiatives
Classification of Requirements
Before being able to elicit and document requirements, the Business Analyst needs to understand the different type of requirements. Every initiative is unique in nature, and therefore to a certain degree, each requirements document is different. To understand how to properly utilize a requirements document template, the business analyst must understand the type of requirements he/she intends to capture.
- High-level business requirements — Typically these requirements include high-level statements to address the goals and objectives for the initiative. High-level requirements are usually found in scope documents or idea creation documents.
- Detailed business requirements — Each high-level business requirement is further broken down to understand specific functions and business rules.
- Product requirements — Detailed requirements providing functionality that will enhance the product. Product requirements may refer to existing requirements from earlier versions or can be a brand new standalone requirement.
- Stakeholder requirements — Detailed requirements from a particular subject matter expert or stakeholder to satisfy their line of business within the organization.
- Solution requirements — Describe the characteristics and often the business rules that a solution must meet to satisfy stakeholder requirements.
- Non-functional requirements — Describes the overall characteristics of the solution and quantify the overall deliverable.
- Functional requirements — Describes how the solution will ultimately behave.
- Transition requirements — Describes how a stakeholder or an organization will move from the as-is state to the desired to-be state at the end of the initiative.
One of the toughest tasks assigned to the Business Analyst is controlling the flow when eliciting requirements. Being aware of the type of requirements you intend to capture is critical, but how do you relate that to the specific initiatives? Moreover, when there are high-end executives, or strong personalities attending your sessions, how do you ensure everyone stays on the path? This is where two of the greatest assets to any Business Analyst will be tested and utilized, communication and organization.
Strong communication and organization skills will lead to the overall successful management of requirements from the time they are elicited, to the time they are implemented. Communication goes beyond verbal, it also includes written, body language, and listening. Communicating the clear objective and tasks, recognizing and listening to all parties’ views, and motivating SMEs to work together to come to consensus will make requirement sessions fluid and fruitful.
Organizing requirements into logical groupings is also a method to ensure proper execution of requirements management. For example, security requirements should be grouped as one topic, and therefore any stakeholders who are directly responsible should contribute to the definition of these requirements. The same methodology should be applied upon developing, where the solution and development are broken into groupings.
Up until this point, most of you reading will be under the impression that this article has taken the approach from a waterfall perspective. I don’t blame you, at the core of waterfall are requirements documents after all. However, most companies have taken a hybrid approach to development, and DLT Labs™ is no exception. Whether you’re working in pure agile, pure waterfall, or hybrid environment, understanding the classification of requirements, strong communication while eliciting, and the logical grouping (aka user stories in Agile) is very much applicable to overall requirements management.
Tips and Hits to Elicit Requirements
- Requirements are only as good as the sources (Ex. customers, users, internal and external experts/SMEs)
- Ensure the right resources attend the requirements sessions, and get meaningful information to them before the actual session.
- Preparation is key to getting information out to the team well ahead of the actual session.
- Be careful about requirements creep. Be aware of core business objectives and scope, and refrain from adding functionality outside of approved boundaries.
- Requirements sessions should be conducted efficiently. Control the flow of the discussions and keep the participants focused on specific and relevant topics.
- Functional decomposition by breaking requirements into logical groups is an easy manner for verifying requirements.
- Ensure you have a good strategy on tackling each requirement session, so therefore plan ahead.
Author — Shailen Parbhoo, DLT Labs™
About the Author: Shailen Parbhoo leads Product Management at DLT Labs. Shailen brings a vast experience in consulting as Product Manager/Business Analyst in several industries such as banking and aerospace, working on high profile projects such as Apple Pay and Airplane Health Management. Throughout his career the focal point has been placed on how to bridge the needs of clients with the delivery of technology.