Introduction
Most CIOs would agree that the lack of proper business analysis and inadequate QA of the Business Requirements Document (BRD) has a significant impact on the ultimate success of software development. A poorly prepared BRD may result in the omission or the limiting of necessary functionality and introduction of inappropriate technical design and programming. If the ’causes and results’ of poorly prepared business requirements are well known and understood, why is there a significant amount of instances occurring and accepted by management and the project stakeholders without challenge?
Experience suggests that the main barriers to the creation of a comprehensive quality-based BRD are rooted in the absence or weakness of enforceable corporate policy, associated procedures, reporting, and governance. These situations are exasperated further by employees who ‘don’t go the extra mile’ in the business analysis by failing to look past the ‘low-hanging fruit’ to identify root causes and better approaches to improvement of the underlying business processes and work activities.
Employee shortcomings that directly contribute to an unacceptable BRD cover:
- Detail user needs in ambiguous, incomplete, incoherent, and not cohesive terms.
- Ignore the needs of cross-functional employees with transactional process workflow and reporting roles.
- Wrongly identifying SRS requirements as BRD requirements. (Business requirements define what must be delivered to provide value. System requirements describe how the software will fulfill business requirements.)
- Mistake stakeholder goals, objectives, or expected benefits, as business requirements.
- Failure to verify that the underlining business activities and processes reflect the current (as-is) and/or future (to-be) environments, as articulated by the end-users.
- Agree with business requirements as gospel and not challenging stakeholders with ‘best practices’ for streamlining and improved productivity among the business activities, processes, and software.
- Accept obsolete business rules used currently or previously in legacy systems.
- Absence of proactive brainstorming sessions to assess and test enhanced workplace user interfaces, interactions, and behavioral scenarios for a possible scope upgrade.
- Deference to corporate ‘sacred cows’: blind loyalty and avoidance of criticism or challenge of long-established but non-productive beliefs, policy, process, being supported by a tenured manager or fellow employee.
Understanding the purpose of a software development project is crucial to be able to elicit and analyze business requirements. When you know and appreciate the source of the business needs, and what impact it will have in the company, it will easily be able to ask the proper questions to gather and prioritize requirements.
“45% of system functionality developed is never used. This is mostly a result of organizations’ failure to define business requirements. In addition, the vast majority of systems delivered fail to provide expected business value.”
The Standish Group
With corporate information and the supporting system technology mission-critical assets, company executives must safeguard their existence and survival with appropriate goals, strategies, and policies. Since the BRD is a crucial element of Stage 2 (Analysis) of the Software Development Life Cycle (SDLC), it is judicious that the SDLC be the principal focus for attention and formality.
Using the SDLC approach as guidance, stakeholders, and project team members are led through a set of structured activities to elicit stakeholder needs in the form of a refined collection of system-level life-cycle phases.
“Only 40% of CFOs find that their IT investments are producing the returns they expected.”
Gartner: How to Optimize IT Investment Decisions
BRD and SRS: The Differences
There is much confusion on the meaning of the ‘business requirements” and ‘system requirements’ terms within system development. The problem is that many people believe they are the same. They are quite different as business requirements define what must be delivered to provide value. System requirements refer to how the proposed system will achieve business requirements. There is also a lack of appreciation on the BRD importance as some organizations only prepare an SRS in the analysis phase.
Business Requirements Document (BRD)
The BRD describes the business features, functions, and behavior that a software application will or will not include from the viewpoint of the end-user within a Concept of Operations (CONOPS) scope. The BRD consists of stakeholder quantitative and qualitative needs and provides input to the System Requirements Specification (SRS).
System Requirements Specification (SRS)
The SRS contains the functional requirements (represents behavior), non-functional requirements (illustrates characteristics), and use cases that the software must fulfill to meet BRD defined customer requirements.
Many IT activities address business requirements within system requirements. Some believe that the difference between business and system requirements is simply at the level of abstraction. Others view business requirements as high-level and ambiguous and decompose into detailed system requirements. In their thinking, if a need is specified, it’s a system requirement, whereas if high-level and vague, it must be a business requirement. This notion is misleading and contributes to the misunderstanding between the unique distinction and uses of BRD and SRS.
So long as IT leaders continue to follow this flawed approach, they will keep producing the same inadequate BRDs and SRSs, developing unusable software functionality that provides marginal value. The below table provides the key differences and highlights the importance of completing both a BRD and SRS in the SDLC Analysis Stage.
“It’s our own ability to have an idea and go after the idea and make it happen. That’s what at the end of the day defines us.”
Satya Nadella
Business Requirements & Business Analysis
It is inconceivable to envision the ideal software solution, identify every user’s need, and foresee future potential challenges or risks that might occur in the development activities without a highly-effective business requirements analysis effort. However, there are many company and project situations and events that may negatively impact a successful phase that can be avoided or mitigated.
For example, critical missteps regularly occur, within business requirements gathering, in an attempt to provide stakeholders ‘what they want versus what they need’! During the translation of user needs into business requirements, unwarranted ‘want vs. need’ tradeoffs are predictably the order of the day. Corporate power politics that embolden personal agendas and protect ‘sacred cows’ is also a driving force in placating stakeholders.
Why do these unnecessary and insupportable instances happen, and why are they seldom challenged? First and foremost, is that placation is the easy way out for the IT team as it avoids quarrels, delays, and possible project cancellation. This condition typically results in:
- Use requirements as submitted without an exhaustive study and consideration for more effective and efficient functional capabilities.
- Replicate an outdated legacy system or business process as a starting point.
Organizations without a dominant business analysis culture and dedicated leadership provide routinely encounter obstacles to serviceable business analysis. A critical approach to remove this problematic setting is the set-up of a formal business analysis competency. This structure ensures the continual production of consistent and comprehensive requirements documents that enable a more accurate elicitation of user needs and consensus.
The scope of the Business Requirements methodology, shown in the below graphic, includes stages for planning, discovery, analysis, prioritizing, and baseline of the Business Requirements Document (BRD). This method supports the SDLC, as the Analyze. Phase 2.
The business requirements methodology uses the Business Analysis Body of Knowledge® Guide (BABOK ®), a recognized ‘best practice’ as a reference for the business analysis efforts. This widely-used tool provides a process and methodology reference defining the tasks that support practical business analysis. Essential features include techniques for eliciting, analyzing, and managing requirements.
The BABOK® Guide includes:
- Business Analysis Planning and Monitoring
- Elicitation
- Requirements Analysis
- Requirements Management and Communication
- Enterprise Analysis
- Solution Assessment and Validation
- Underlying Competencies
The BABOK® consists of the below elicitation techniques for business analysis use.
The elicitation techniques, based upon the unique project setting, can be combined to ensure the successful discovery and consensus of the business requirements.
A point of confusion regularly found in business requirements gathering and analysis efforts are among the words – the customer – ‘needs’ and ‘wants.’ The selection and use of ‘wants’ wrongly as ‘needs’ will have adverse impacts on the quality of the requirements and result in the preparation of a failed systems requirements specifications.
The below definition highlights the critical differences between ‘needs’ and ‘wants.’
Need: what customers believe will solve a current/future problem or opportunity consists of:
- A customer who requires a benefit. (Who?)
- An object to deliver value to the customer. (What?)
- A context to provide the object to the customer. (When, Where & How?)
Want: what customers think they need but not necessary or a priority.
Project Management Institute (PMI), Pulse of the Profession Report
Business Requirements & Brainstorming
Brainstorming can elicit new knowledge, ideas, and possible solution opportunities for the development of new or replacement software. The technique is best done in a group as it uses the energy, passion, and intensity of the team to stimulate and creatively share ideas in a collaborative setting. This technique is most effective when it focuses on one particular topic, rather than covering a broad spectrum.
Brainstorming is a useful practice that can help a team examine particular business process problems and opportunities and generate a wide variety of practical requirements. By not limiting the number of ideas generated within a given time frame, exceptional suggestions, including the unexpected or “outside of the box,” thoughts and scenarios can be identified and tested.
The collective nature of brainstorming can have the added benefit of creating cohesion among the different stakeholders, benefiting the organization as well as the project team. When employees brainstorm, they not only share ideas and concepts, but they learn from each other, collaborate better, and become more tolerant. Brainstorming can be an effective way to drive less imaginative team members to awaken their creativity and get their juices freely flowing! Further, this technique can help more easily obtain buy-in from team members as they were involved in defining the requirements.
Business analysts can use brainstorming to discover ideas, identify root causes of problems, supporting business requirements.
During requirements gathering, brainstorming generates a variety of ideas from a group of people and identify possible solutions to problems and may also be combined with voting to prioritize ideas.
The graphic, on the left panel, shows a selection of widely-used brainstorming techniques considered as helpful for use in particular scenarios.
Creative ideas do not suddenly appear in people’s minds for no apparent reason. Commonly, they are the consequence of trying to solve a specific problem or to exploit an opportunity.
Albert Einstein’s theories of relativity were not sudden inspirations. They were the result of a massive amount of mental problem solving, trying to close a discrepancy between the laws of physics and the requirements of electromagnetism within the scientific thinking and practices of the time.
“As I say to our own team: ‘Never protect your past, never define yourself by a single product, and always continue to steward for the long-term. Keep moving towards the future.”
Ginni Rometty
Business Requirements & Quality Considerations
Soliciting and collecting business requirements is a critical initial step for a software development project. The goal is to create a BRD that effectively identifies real user needs for use as a reliable input to the preparation of the Systems Requirements Specification (SRS), and subsequent software design and development activities.
The key challenges faced in the business requirements gathering include stakeholders that wrongly:
- Identify different and conflicting ‘needs’ than their colleagues.
- Address the technical solutions at the expense of the business’ needs.’
- Identify user ‘wants’ as user’ needs.’
- Prioritize the requirements: value range from mission-critical to low.
The quality of the deliverable measures professionalism! Problematic BRDs can sabotage, reduce credibility, compromise team-building, and diminish consensus on the scope and context of business requirements. They also can undermine the clarity of the elements, create confusion, suggest poor communication skills, and convey a lack of attention to detail. These conditions can result in misleading or factually inaccurate information and cause stakeholders to question the integrity of the requirements or the employee abilities they perceive as unprofessional.
The sad truth is that many companies appear resigned to inaction while employees struggle to produce badly written, poorly structured documents.
What discrepancies can make a business document a candidate for rejection? Experience supports that most seasoned business and IT leaders believe that without question, they can readily recognize poor documentation. It generally takes less than a few minutes for most experienced workers to judge the quality and acceptability of a BRD and similar deliverables.
The professionalism of business requirements documentation can be significantly improved, with adherence to the ‘good’ and avoidance of the ‘bad’ characteristics presented below.
Stakeholders have the final vote on acceptability, and if they recognize that the initiative as low-quality, they will reject and further doubt the value of the underlying plan.
However, with the high instances of unacceptable business requirements documentation regularly witnessed in the workplace, a refresher, on the specifics, is necessary.
The prime characteristic of well-written BRDs is the use of a standard and consistent template that is reusable for all corporate software development projects. The model includes an array of relevant sections, as shown on the BRD graphic.
Writing is an essential soft skill, but most apathetic writers can improve their ability by learning to avoid the most common mistakes. There is no standard or best practice way to compose outstanding business requirements. It is mostly a matter of experience from the problems encountered and lessons learned from past software development projects. Writing acceptable requirements and similar documents takes skill, practice, and patience.
The BRD should be completed in conformity with consideration for known language arts and document formatting and assembly mistakes and faults, as outlined below.
“Uncontrolled variation is the enemy of quality.”
W. Edwards Deming
The Way Forward
At Knowledge Compass we bring together nearly four decades of thought leadership in business and technology strategy, the latest tools and best practices, and a seasoned consultant team with the competencies and talent to help our clients improve productivity and profitability of all enterprise business and support activities.
Knowledge Compass explores and develops valuable new insights from business, technology, and science by embracing the powerful technology of ideas and brainstorming. Our consultants engage customers in challenging discussion and experimentation to expand the boundaries of business science and practice and translate creative ideas into practical solutions from within and beyond business.
Working with Knowledge Compass means a collaborative approach to understanding your current business model, strategies, and key business requirements and goals.
Knowledge Compass provides consulting services with the use of an array of Frameworks, Analyses Tools, and Interactions from their Best Practices Consultant Toolbox.
