Capture the details
The ability to provide clear and concise requirements to developers is not only the most critical criterion for being a good BA but it is also a sure-fire way to gain respect amongst the technical team. Depending on the organization’s structure and availability of resources, a developer can be assigned to a project at any point, so access to complete and detailed requirements will impact their ability to hit the ground running on the project. This can be tricky because you don’t want to provide too much unnecessary detail as this will lead to excessive amounts of documentation that the developer is likely to bypass. There must be a balance. Requirements that are not complete can lead to assumptions that developers have to make, which can lead to problems down the line. The BA will need to be able to provide requirements that minimize assumptions. The BA will also need to ensure that all assumptions are documented and verified. As business analysts, we are expected to provide well-organized requirements that are suitable for various audiences and a range of perspectives. For instance, stakeholders will want to see details regarding processes, user features, and outcomes while developers care about things such as data elements and the source of data.
The BA will need to capture this information in a way that will allow the developer to move forward with development without ambiguity. General techniques that are essential to the developer viewpoint may include (but not limited to) the following:
- Acceptance Criteria - Whether you are documenting user stories or traditional requirements, detailed acceptance criteria will provide guidance to the developers while coding so that they are aware of the expected outcomes. This is also critical for acceptance testing.
- Data Modelling – This technique is often executed by more technical roles such as a data analyst or systems analyst, however, the BA should be equipped with the understanding of proper modelling notation for Entity Relationship Diagrams or Class Diagrams in order to confirm that the relationships between the data meets the stakeholders’ expectations and conforms to associated requirements.
- Roles and Permission Matrix – Developers will be creating groups and roles for the product, which often have various levels of security. The BA will need to clearly outline the roles of all impacted stakeholders as well as the permissions and capabilities each role should have. Having this information clearly documented will not only make it easier to verify with the business, but it will also allow the developer to be much more efficient during development analysis.
Make Implicit Requirement Explicit
In most cases, stakeholders provide more thought and input to key system features or functional requirements during elicitation because these are the areas that are most familiar them. These are the explicit or stated requirements. There are also numerous implicit requirements that are just as important as those explicit requirements, however, they are often overlooked. Implicit requirements are “implied” through the statement of other requirements. In some cases, stakeholders are so familiar with a process that they may not think what they are discussing requires explanation. In other cases, stakeholders assume these requirements are inherent within requirements that are explicitly stated but often they are not. In many cases, implicit requirements may come in the form of non-functional requirements. These non-functional requirements are critical to the performance of the functional requirements and may include categories such as efficiency, scalability or security. If these kinds of requirements are not addressed, it can result in poor product performance.
Because the nature of implicit requirements is more technical, the developer is often left to make assumptions when they are not addressed during requirements elicitation. We all know that assumptions can lead to trouble, especially for the developer who has to do the rework if it’s wrong. As BAs, we can support developers by being skilled in drawing out implicit requirements and making them explicit through clearly documented functional and non-functional requirements. Capturing implicit requirements involves asking questions that may be more difficult for the stakeholder to answer; however, it will lead to more thoughtful conversations regarding the overall expectations and user experience. The addition of these requirements will minimize the guesswork that may or may not backfire on the developers and allow them to focus on their primary functions more efficiently.
Provide feedback ASAP
The business analyst’s ability to provide feedback to a developer depends on the organizational structure as well as methodologies used. This aspect also depends on the BA’s subject matter expertise, communication skills and willingness to be hands-on. One of the most critical points of feedback for the developer is the Quality Assurance (QA) process. This is because QA provides feedback to the developer early on the development process. In most cases, development and QA teams have little exposure to business processes so there may be several bugs or defects that go undetected during QA because they don’t have the subject matter expertise that the BA would generally have. Most developers would appreciate if the BA partnered with the QA team to identify defects or misinterpreted requirements earlier in the process (during QA) as it would lead to far less rework during User Acceptance Testing (UAT). In addition, when fewer defects and requirements changes are identified by the end users in UAT, the business analyst and technical team appear more competent.
When defects are presented to developers further down the line, they may forget the rationale of why they coded something a certain way or what the overall objective was all together, so early defect identification can make a big difference. Defect resolution isn’t the only way the BA can provide feedback to the developer. As a BA, going above and beyond from a development perspective often requires being more technical. This means being familiar with systems and data structures within the organizations, providing input during design sessions and reviewing design documentation. These can be especially critical to ensuring that the designs are aligned with the requirements that have been specified.
Anticipate developer questions
A developer friendly habit in the business analysis process is to anticipate the types of questions a developer or anyone on the technical team would ask. If we as business analysts considered the more technical questions during the elicitation processes, it will eliminate some of the back and forth down the line. One way to approach this is to take notes of questions and concerns that are presented by members of the technical team during requirements reviews or workshops. Keep a running list of all of the questions and try to determine if there are any trends with the types of queries that are raised. Continuously refer back to these trends so that you can account for them in future elicitations efforts. This tactic will lead to richer more comprehensive elicitation results. Another approach is to refer back to the Lessons Learned documentation from previous projects to extract any valuable developer concerns that may need to be addressed for future requirements elicitation.
Understand how developers work
Understanding how the developers in your organization complete their work will significantly improve development efficiency. This doesn’t mean that the BA is expected to know every fine detail about the development space; however, as BAs we should have a high-level understanding of the development workflow. One of the key elements the business analyst should understand is the software development and tracking tools that are used in the development space. When defining the requirements architecture, knowing how developers are assigned work and how feature development is tracked can prove invaluable when communicating, maintaining and tracing requirements. It would be largely beneficial to create a requirements viewpoint that directly aligns with the existing development workflow. A comprehensive requirements management tool that directly integrates with software development and tracking tools used by the development team would be ideal, though it seems to be a rare feature in many organizations.
Another key point to understand is how developers perform unit testing, peer reviews and handle defects that are reported. A general understanding of this workflow will help BAs set fair and realistic expectations around the development process. In addition, if the BA is familiar with and has access to the tools used for these tasks, it may be possible to keep track of the development progress without having to constantly prompt the developer for status updates. This will allow the developer to focus on more critical matters.
Know the person behind the code
One of the simplest ways to nurture a relationship is to get to know someone personally. In many cases, developers have unique personalities and it can often be a challenge to understand their way of thinking. Getting to know developers personally will help break down many of the barriers that often cause harm to the work environment. Developing a personal relationship doesn’t take a lot of effort. Simple things such as going to lunch or coffee with developers can easily uncover common interests that can enhance your work relationship. Because of the technical nature of the developer role, it can be easy to treat them like a machine and forget the personal aspects of the relationship. Remember that developers are people first and getting to know someone’s personality and background can often impact how you respond to them as an individual. It’s also more likely that a developer will go above and beyond when they are working with BAs and stakeholders that they know personally. So, nurturing your personal relationship with developers can go a long way!
In conclusion
Above are some tactics to help business analysts get more engaged with developers and improve the business analyst-developer relationship. BAs must provide adequate support to developers by capturing the details that will allow them to move forward. In addition, the business analyst’s ability to capture and communicate implicit requirements and provide prompt feedback is essential. Furthermore, BAs should be prepared to anticipate the more technical questions and elicit requirements accordingly. The willingness to understand the development workflow and develop personal relationships with developers will serve the BA greatly. Strong relationships with developers will not only improve project implementation, but it will also lead to increased customer satisfaction and make your job as a business analyst much more enjoyable. BAs who do not have good relationships with developers or the technical team can expect resistance, miscommunication, and a lot of rework.
Author: Michael F. White, Business Analyst and Founder of The Business Analysis Doctor, LLC
Michael has an extensive background in business analysis, project management and coaching. He has driven innovation at some of the top financial institutions in the nation and holds a Doctorate in Business Administration. To learn more about The Business Analysis Doctor, LLC visit https://thebadoc.com