Are you a Jurassic BA?

In your work, have you heard these phrases “Working as designed, but not as expected” or “It’s not a bug, it’s an undocumented feature.” or “Working as requested”? Each of these indicates a problem. I offer the possibility that the requirements left some room for poetic license and the developers could have inserted what they think the business needed rather than what they needed into the code. This could be a case of what I call the Jurassic BA. Let me explain this condition.

I love movies. My family has many favorites, one of which is Jurassic Park. This book turned into blockbuster movie describes an amazing discovery of dinosaur DNA left inside a mosquito preserved in amber waiting for the technology and knowledge to be discovered in the future. The thought is to use this DNA to create dinosaurs in a lab, open a zoo/amusement park and let the world marvel at the creatures that the Earth shook off quite some time ago. Fantastic idea! Well, the scientists were missing some pieces of the dinosaur DNA string. They found a solution and chose to insert some amphibian DNA to complete the string.

The business need was to control the dinosaur population and not allow any breeding in the wild, so they made all the dinosaurs female to ensure they didn’t breed on their own. However, amphibians don’t stick to that creation rule, and dinosaurs start being created in the wild,. They became unmanageable eventually breaking through their controlled environments and being born outside of the lab. The end of this story is brutal, people were injured, eaten and chaos broke out. Jurassic park was “Working as designed, but not as expected”! A Jurassic BA is an analyst who is guilty of delivering incomplete requirements to development teams. These teams are left with incomplete requirements (incomplete DNA) and they need to insert what they think was intended (amphibian DNA) into the code to complete the design. It can be brutal and dangerous, just like Jurassic Park. The problem of Jurassic BAs providing incomplete requirements to development teams impacts project teams, employees and customers. The impact of which is failed projects, lost revenue and/or corporate reputation and low employee morale. A successful solution would be to evolve Jurassic BAs into analysts that provide complete requirements.

At points in our career evolution we have likely been the Jurassic BA. With any luck, a peer review or requirement walkthrough caught the material missing requirements. How do we evolve from a Jurassic BA? There are many tools and techniques available to use to cross check for missing requirements. The critical thinking in elicitation, modeling, and design all rely on a foundational understanding of the process, data, external agents and business rules applicable to the problem we are solving. No matter what software methodology, company culture, system or product your business is using, these basics are what will safeguard you from the insertion of the amphibian DNA into your code! While there are many techniques and tools in our analysis tool belt, I offer up these four as critical to our career evolution to avoid delivering incomplete requirements.

1. Context Dataflow Diagram

This purpose of this technique is described in BABOK® v3; 10.13:”Data diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.” This diagram is critical to ensuring you know the interfaces, high level data flows, systems and people involved in your project scope. Teams appreciate the understanding this visual depiction of scope creates. The diagram shows the interactions your project needs to consider in your solutions. Although this is a technical diagram it creates simplicity out of complexity. Missing pieces can be identified early and included in your analysis for the solution. This can be used to describe current state as well as future state, visually showing differences in the future state design. A business analyst can avoid missing details when this technique is used early and throughout the project to confirm interfaces and dataflows to external people and systems.

2. Process Modeling

A Context Data Flow Diagram is a great foundation to identifying impacted business processes. Documenting business processes is BABOK v3 technique 10.35 described as”Process modelling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis.” Understanding the business process and data transformation throughout the processing highlights requirements to ensure data quality and completion. Without a viewpoint into the business process, business analysts are missing requirements. Process modeling, particularly using swim lanes, structures thinking. This forces a viewpoint from the user and system interactions and how work moves between stakeholders. Starting at the beginning of a process and walking through each step until the process ends enlightens understanding and uncovers missing requirements. Teams value process documentation to ensure accurate design as well as testing of the solution. The visual depiction of how work is processed is easy for teams to understand. This picture creates understanding of what work is being done rather than what work is thought to be done. Many elicitation techniques are used to discover the business process: Interviews, observation, workshops, and observation are common methods to understand business process. Businesses find additional value in process documentation for testing and training. It saves project teams time to have this documentation for additional phases or rewrites in the future.

3. Business Rules

Process diagrams are a great source of understanding business rules. Business Rules Analysis is BABOK technique 10.9. The purpose is “Business rules analysis is used to identify, express, validate, refine, and organize the rules that shape day-to-day business behaviour and guide operational business decision making.” Business rules are keystones for business. The rules govern how the business must be documented, processed and validated. Systems often enforce business rules, although not always. Business rules do exist outside of systems. All rules are important to understand because there are changes in technology that may allow for system enforcement of business rules where past technology did not. Finding a way for a system to enforce a business rule can create value. Business rules must be elicited, understood, and documented. Decision trees, tables, or models are tools for visual depictions of business rules. Process diagrams may include decisions that represent business rules as well. Business analysts must document business rules in an existing system when transitioning to a new system for a successful transition. Don’t forget the rules! This is a place where developers need to make their best guess if the requirements are not complete.

4. Prototyping

Capturing the interfaces, business processes, and business rules in models is a great foundation for complete requirements. Supporting these with a prototype of the proposed solution when the design is being discussed will help to confirm understanding and avoid the introduction of amphibian DNA to the solution! BABOK technique 10.36 is Prototyping. The purpose is “Prototyping is used to elicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.” A prototype will show the screens, processing, user experience and expected results for a solution. Prototypes can be simple, hand drawn on paper or a whiteboard. They can also be more complex and technical with screens that are clickable that users can navigate through. Allowing the business the opportunity to see the proposed design in a prototype is a crosscheck to see if the design will meet the needs and expectations of the stakeholders. Preparing for the prototype is another way of structuring thinking to discover any missing requirements.

Using these four techniques will help a business analyst evolve from a Jurassic BA to a highly effective BA. The ability to provide complete requirements saves corporations from teams inserting best guesses into the code and ending up with designs not as expected. Be complete and use the techniques to complete requirements. Let the Jurassic BA stay in the past!

Heather, a BA Without Borders