A requirement is a feature or characteristic requested by a stakeholder that may form part of the proposed solution.
There are certain fundamentals in relation to business analysis and your ability as a business analyst to gather, document, analyze, present and manage business requirements remains a core component of this profession. Moreover, your job as a business analyst, a conduit of change and an analytical professional who sits at the heart of digital transformation, is to understand, implement and present these changes back to the business.
Requirements are elicited so that they may be recorded for future consideration. Further analysis is then conducted to determine if they should or should not be included within the solution.
Ultimately, requirements determine what a solution should provide and how well the solution should perform.
What is a Requirement?
If you are to transition into the world of business analysis having a clear fundamental and foundational grasp and understanding off requirements is essential. A requirement is:
- A need perceived by a stakeholder
- A capability or property that a system should have
- A documented representation of a need capability or property
In the world of agile software development, requirements are gathered and refined constantly, but high-level requirements are usually gathered at the very start of a new project so the vision of what is to be built and what the solution should look like can be grasped and understood from the start. Its only once high-level requirements have been gathered further analysis, scrutiny and refinement can take place.
Requirements in Agile and Waterfall
As mentioned or implied, there are different software development methodologies available. Perhaps the greatest contrast is between waterfall and Agile software development and more explicitly how they view the gathering of requirements. As a business analyst you need to understand both approaches because every company project and organization will have its own unique perspective on how this important work should be conducted. Moreover, the method in which and the attitude in which you treat requirements varies amongst agile and waterfall methodologies.
Agile
Within agile requirements gathering and refinement is a consistent part of the software development lifecycle. What this means is requirements are constantly being scrutinized, refined and analyzed. This is not only normal within agile, but also expected.
Furthermore, requirements, usually in the form of user stories, go on to form the basis of test scripts, a subject we will come back to later. Therefore, within the lifecycle of an agile build, requirements are a constant variable and component of the project.
Waterfall
Within waterfall software development this is not the case. The reason why waterfall has become the name of this style of software development it's because each phase of development is distinct and each phase cascades downwards into the next. What this means for you as a business analyst is when you are gathering your requirements, once this phase is finished there is no further scope for requirements work. So, the time you spend with your stakeholders listening to them, gathering their requirements, analyzing and documenting their requirements is final; once this work is done this phase is finished.
The implications of this can be quite drastic.
The reason is, when you are gathering your requirements, your stakeholders need to be aware that any changes to what they've asked for comes at a high cost. Not only in the monetary sense, but also in terms of development time both in terms of personnel and solution delivery timelines. Most if not all software development companies, or developers then enter the realm of Change Requests (CRs).
Change Requests
A Change Request is submitted when previously agreed requirements must be altered to accommodate the new requirements. On the surface this may seem innocuous or a standard practice but depending on the size of the change, the scope of the change(s) and so on there can be heavy implications for change requests. As a principle a CR costs resources, however within a software development methodology besides true agile, change requests are inevitable. This is because when a stakeholder provides requirements seldom do they have perfect perspective and may not fully understand the extent of implications of what they have asked for. In addition, what they describe up front versus what they are then demonstrated might not be in perfect alignment. Unless there is complete or good enough alignment between what the stakeholder has requested and what has been delivered a change request is the inevitable outcome in order to bridge that gap.
Understanding change requests is crucial to your understanding of requirements especially if you are to be a business analyst within financial services or any sector that embarks or is embarking upon mass, industrywide digital transformation. This is because whilst many traditional companies have fantastic intentions of truly being agile, the fact remains that there are many other factors that come into play when it comes to the software development methodology adopted. Typically, more senior members of the team need more reassurance for costs and timelines and waterfall development, since phases are distinct, provides clearer perspective on development times and costs and this makes planning and resource allocation slightly easier. This understanding alone drastically affects how requirements are gathered, documented, presented and managed.
What inevitably happens is a hybrid methodological approach two development whereby the use of agile components such as user stories and backlogs are used, but the rigidity of requirements gathering from a typically waterfall project is fused with agile.
Why is this important?
As a business analyst you must be aware that the demand of your skills, experience and expertise is only demanded due to digital transformation, software migration, modernization and overall IT change.
The problems with requirements
This is a list off some of the most common problems with requirements. Without well gathered, analyzed and documented requirements your project will fail. Some of the most common reasons why requirements are not good enough include:
- Insufficient and ineffective requirements and analysis conducted
- Inefficient time allocated two requirements analysis because too much time allocated two development and testing
- Poor alignment of developed system to business strategy
- Poor requirements management
What we can see from this list and this list is not exhaustive, but when businesses don't allocate both time and sufficient resources to requirements analysis, documentation and gathering, projects not only fail, but developers and testers develop and test the wrong solution. Moreover, the entire outcome of the project hinges on the gathering, analysis and documentation of business requirements.
Also, poor requirements will lead to unsatisfied and unhappy customers, which feed into profits, and will lose business. Therefore, not only will you have unhappy stakeholders, but you could also end up with unhappy customers too. Furthermore, you should not underestimate the importance of astute, considered and accurate requirements management as the entire project and outcome balances on them being accurate.
Wailia and Carver (2009) Identified over 90 causes of requirements errors in a study that considered over 149 research papers. Key problems with requirements identified during this study include:
- Lack of relevance to the objectives of the project
- Lack of clarity in the wording or ambiguity
- Duplication or conflict between requirements (contradiction)
- Requirements that assume a technical solution rather than stating the features to be delivered by the system
- Stakeholders from the business failing to identify all the requirements
- Inconsistent levels of detail
- Business staff and analysts making assumptions and taking their own knowledge for granted and failing to ensure there is a common understanding
The conclusion is like the conclusion above and reiterates the point with empirical evidence. The fact remains simple and clear: poor requirements equal poor solution or even worse, no solution.
Now we have understood what requirements are, why they sit at the very heart of every digital transformation initiative and why ineffective and insufficient gathering of requirements or poor requirements management leads to failure we must now look at how we alleviate these issues. Moreover your job as a BA is to ensure requirements are accurate, high levels of analysis has have been conducted, robust and careful documentation has been applied and overall high levels of requirements management, in which you are usually in charge of have taken place.
The RE Framework
The RE framework what's developed to help improve the quality of requirements by clarifying the activities to be carried out when defining requirements. as a business analyst you need to elicit, analyze end define requirements carefully so these artifacts provide a firm basis for developing business and software solutions; the RE framework helps business analysts do this.
The RE framework sets out five core activities, and the pivotal interactions between them. The five key interactions are:
- requirements elicitation
- requirements analysis
- requirements validation
- requirements documentation
- requirements management
Like all frameworks and models, the value is derived through application. Each project business organization etc we will tweak the model. however, the crux of requirements management can be found in the RE framework. According to Deborah Paul and James Cadle in business analysis 4th edition, one of the strengths of the RE framework model is the explicit separation between requirements elicitation and requirements analysis.
“Analysts are encourages during elicitation to draw out information, uncover tacit knowledge and discover requirements; during analysis, the business analysts examine the results of elicitation work in order to define the requirements that the solution should deliver.”
Actors within Requirements Management
Requirements are suggested by individuals or groups who seek some functionality or benefit from that proposed business change. Therefore, understanding and knowing how to categorize stakeholders is critical to effective requirements management, click here to read our guide on stakeholder management.
