The Book, The Movie, and the Business Document

Communication using only words – whether verbal or written – leaves much to the imagination. Which is part of the appeal when it comes to reading for pleasure?

Think of a book you’ve read and enjoyed which was later interpreted as a movie. With the book, your interpretation of the appearance of the settings and characters is a product your imagination, which is shaped by your unique life experience. Every reader of that book comes away with a somewhat similar, but different perspective.

An author can narrow down some of the variance in interpretations by adding more descriptive detail. Think of a book you’ve enjoyed for its vivid descriptions of setting and depth of character development. This can be great for a riveting novel that we wish would never end.

Perhaps, upon leaving the movie based on a book you’ve read, you considered (or commiserated over) how different the characters and the scene were from how you’d imagined them. Your interpretation of the words in the book is as valid as anyone’s. It just didn’t match those of the producer of the film, and possibly, the author of the book. This makes for interesting discussion and critique.

In the book’s cinematic version, with the addition of the audio and visual elements, all viewers come away with a shared mental image of the appearance of the settings and characters, because the additional sensory dimensions make them more explicit. Similarly, visuals, such as pictures, diagrams or other types of models can be helpful in our business communication because they eliminate much of the “imagination,” or ambiguity of words, making meaning more explicit. Visuals serve to calibrate the natural differences in our mental images.

Now, unlike that great book or movie, most of us don’t read business documents such as a requirements specification for enjoyment. And unlike the book, there can be significant repercussions when one reader’s interpretation of the content varies widely from another’s. The Big Thick Document (BTD) is a product of the notion that increasing a document’s length to add more detail will improve the communication value of the document. Unfortunately, the opposite is more often the result because the longer document is, the:

  1. Less likely to be read
  2. Less likely to be understood if it is read
  3. More likely errors or omissions are to be overlooked, as readers tend mistake length and detail for precision and accuracy.

Thoughtful use of visuals – even, and especially in rough or early drafts – adds a dimension of “understandability” to the ideas expressed in documentation that is not possible in a mostly text-based format, and at very little additional cost. In fact, often it is more work manipulating language to describe something than it is to represent it visually. To this end, a white board or a blank sheet of paper and a drawing utensil are valuable tools when it comes to working through ideas to establish common understanding.

A few questions we may ask to help us optimize our efforts:

  • What can we give business stakeholders who want to confirm for us that we’re on the right path that isn’t overwhelmingly long and difficult to decipher?
  • What can we give delivery team members that, first, summarize the details and provides context, then, expresses the details in as easy a form as possible to understand and use to do their work?
  • How can we strike an acceptable cost/benefit balance in doing these things?

By Bartosch Salmanski


Testing Nonfunctional Requirements in an Agile Lifecycle

Effective nonfunctional testing is often the forgotten testing task. It can be the elephant in the room that no one wants to talk about.

To start with, nonfunctional requirements (NFRs)—such as performance, reliability, installability, scalability, usability, security, availability, and so forth—are hard to quantify. Just as importantly, finding someone who has the depth and breadth of knowledge to define NFRs is usually a challenge.

In a traditional waterfall cycle, we may have some definitive NFRs in the system or requirements specification. In safety-critical systems, NFRs are much better defined, but for many commercial software development environments, NFRs remain elusive and tend to be a “late in the lifecycle” testing activity.

As organizations embrace agile, NFRs may be an even greater challenge—both functional and nonfunctional requirements must be considered and validated in each (short) sprint. Ideally, NFRs are a continuous focus during each sprint, instead of being left to the last one.

Here are some ways to better address NFRs in your agile development lifecycle.

Defining nonfunctional requirements:

For brand-new products, use analysis, experiments, and comparative testing, and collect or test user expectations.

    • Analyzing the technical, data, and network architecture will yield important characteristics and constraints.
    • Design experiments and do comparative testing to evaluate and select the best alternatives.
    • Speaking with users and asking successively detailed questions can help quantify NFR expectations. For instance, if customers say, “I need it to go fast,” you can further define what they mean by fast. You also can demonstrate the product to users and get their feedback immediately, such as by saying, “Let me load this home page for you, and you tell me if it loaded quickly enough.”

For evolving products, use analytics tools to mine existing application and system data.

  • Analyze data from customer usage—clicks, workflows, feature usage, errors, abandons, and so forth.
  • Analyze information from production systems, including resource usage (memory, process, CPU, and input/output rates), network traffic characterization, security attack attempts, and database statistics.
  • Review help desk and issue tickets for outages, defects, enhancement requests, and user errors.
  • Use video and screen-capturing software to record user sessions and analyze problem areas.

Documenting nonfunctional requirements:

In waterfall methodologies, NFRs are included in a separate document or category in the repository. But in agile, NFRs normally cut across several user stories, or even the entire system, sp require some special consideration.

  • First, ensure that NFRs are being discussed and defined during the agile release or theme planning and that a conversation around how to test these characteristics is started.
  • Define scenarios that cut across stories. A scenario describes a real-world example of how people or organizations interact with a system. Scenarios then act as constraints across stories, and they have rules and restrictions that must be met.
  • Alternatively, create backlog items for each NFR and link user stories to these NFR backlog items. These will later be estimated and scheduled into the appropriate sprint.

Continuously testing both functional and nonfunctional characteristics across sprints is the key to delivering a minimum viable product.

By Michael Sowers

How Can a Business Analyst Help You?

Sometimes project stakeholders I work for or with aren’t familiar with the role or the value of the business analyst. I’ve posted about Karl Wiegers’ Bills of Rights previously, and think those are a great way to introduce the role to a new business stakeholder who may not be familiar with the types of value a BA can provide, and what he/she should do to help the process along.

A few days back, while waiting for a meeting to begin, I jotted down a few quick ideas of my own that I thought I might share with stakeholders with whom I hadn’t previously worked if questions arose over what help and services I can provide by fulfilling my role as a BA.

I didn’t put a great deal of time into this list, and it is by no means conclusive, but I thought I’d share in case it may be of value to someone.

As a business analyst, I can help you:

  • Develop your business case, and determine whether your business case is viable and warrants investment of company resources.
  • Distinguish a business problem’s symptoms from its root cause, and help you discover the true root cause.
  • Ensure that all of the key questions have been asked, and their responses documented.
  • Ensure that issues are captured, resolved, and their resolutions documented.
  • Provide you with the honest perspective of a disinterested “third party” who is beholden to no particular business unit or stakeholder.
  • Make sure that the right decision makers are involved in the project and have an opportunity to provide input.
  • Identify all the systems, processes and users that are impacted by the business problem, and/or the solution.
  • Ensure that the system/process users’ interests are known and communicated to other project stakeholders.
  • Fill in gaps in your current-state process documentation. You need to understand how things work today if you’re goal is to fix today’s problem.
  • Understand the solution options that are available, and help you and the other project stakeholders prioritize those options based on their merits, and eventually select the best option.
  • Feel confident that those who will implement the solution understand what is required of them and of the systems or processes under their purview.
  • Provide you with quality specifications and process documentation that will serve as a valuable reference regarding decisions made and solutions implemented.

As I said, this is a quick-hit list. Some of the items are rather specific; others could be decomposed into numerous other sub-items. What items might you add? Are there items included here that you think fall outside of the normal responsibilities of a business analyst?

By Jonathan Babcock

Business Analytics

There is a major change happening in the IT industry—the use of big data and analytics to guide how businesses are run. Many companies are embracing analytics as part of their core strategies.

Unfortunately, some of those companies think that they can just purchase an analytics solution, implement it, load and collect data—and poof! all their problems will be solved. There are many software solutions available for business analytics, but there is also still a need for requirements analysis to ensure the right solution is selected and implemented correctly.

Business analytics implementations need software requirements, just like any other commercial, off-the-shelf solution. There will be business requirements, functional requirements, non-functional requirements, and business rules. Requirements models help us understand how people will use the solution and help guide the configuration of the system according to the business rules.

The process to elicit and develop requirements for business analytics projects can be broken down into four steps, as shown in the following diagram. I’m going to focus on the fourth step: Define the data transformation analysis requirements. Find more information on the other three steps in the white paper “Forward Thinking for Tomorrow’s Projects: Requirements for Business Analytics.”

Business Analytics 2

In an analytics project, once you have identified the data and understand how users want to consume and use the results of analytics solutions, then the main focus is on determining what analyses must convert the data into in order to get those results.

Sometimes, users just explore the raw data objects and attributes because they don’t really know what they want. However, it’s important with big data to at least zero in a bit on what kinds of problems users want to solve and what type of analysis they might want on the data. Otherwise, the analytics solution might do too much and be too overwhelming to be useful.

Good business analysts (BAs) can help stakeholders figure out what they want from the solution by brainstorming what possibilities exist with analytics solutions.

Business analytics solutions can enable future-state strategic analysis, such as exploring “what-if” scenarios. For example, “What if we could offer a new service and predict what our future sales would be for that service—before we ever deploy it? How would that be helpful?”

A good analytics solution with the right data can run models and algorithms to enable these types of data predictions. That said, prediction models and usage scenarios still must be specified in the requirements so that the analytics system can be configured correctly. Furthermore, the analyses that transform the data might require computations, statistics, or that other business rules be applied to the data prior to its being delivered in the solution.

Business analytics projects need software requirements defined, just like any other project. The approach is slightly different: Prioritize using decisions, define how information will be used, specify the data needs, and define the analyses that transform the data. When defining those analyses, we can’t assume the analytics solution will just come configured to do what we need our solution to do.

By Joy Beatty

Business Analysts Need to Build Trust

I recently attended a virtual IIBA meeting for the Los Angeles chapter, and the topic was the interesting “The Influencing Formula:  Three Steps to Influencing When You Don’t Have the Authority”, given by Elizabeth Larson from Watermark Learning.

What really resonated with me was step one:  Build Trust.  Being in a consulting role, building trust is something that I must constantly do.  Sometimes it is with a new client, sometimes it is with a new stakeholder within an existing client, sometimes it is with a new colleague.  But building trust is an ongoing and never ending activity for me.

As part of the discussion about building trust, the “Four Cores of Credibility” by Steven Covey was mentioned.  This was taken from Mr. Covey’s book, The Speed of Trust.
Business Analysts Need to Build Trust 2


Essentially, credibility is made up of Character and Competence.  Character is built from Integrity and Intent.  Integrity is achieving results in an honest and principled way.  This is the basis for of all trust.  Communicating your intent is next.  No hidden agendas, this is being upfront and honest.

Competence is built from Capabilities and Results.  Capabilities is keeping your knowledge, your skills and your abilities current and relevant.  Continue to learn and grow.  Results is achieving what you set out to do.  You have to deliver in order to have trust.  You can have the other three cores, but if you don’t have results, then you don’t have trust.

As a Business Analyst, I absolutely need the trust of the people I work with in order to do my job.  For without trust, then it does not matter how hard I work, or how fantastic my requirements may be, they will not be regarded as good and effective unless I have the trust of the team with whom I work.

I encourage you to think about what trust you have of your stakeholders.  If you do not have their trust, which of these four cores are you missing?

by Betsy Stockdale

5 Things that make a GOOD business analyst GREAT

1. Good business’s analysts don’t have to know everything; they just need to be good at knowing where to find what they need and knowing whom to ask. My husband taught me that it’s okay of I don’t know exactly where the artifact I need maybe but I certainly know where and how and from whom I can get it.  They don’t stay stuck because they know how to get what they need to move forward.

2. Good business analysts are great communicators, they know how to keep everyone one in the loop and how to track the status of everything they ate responsible for. They are great at communication management.

3. Good analysts are good problem solvers. Call it the engineer in me, but the ability to think critically goes a long way in our ability to analyze anything. They know how to ask the right questions, and in many different ways until they arrive at the most unambiguous and detailed answer possible.

4. Good business analysts know how to resolve conflict among their stakeholders to move the project forward. They know how to sell what’s in it for each party so that personal agendas are put away in favor of the common project vision and success.

5. Good business analysts are continuous learners. They are always on the look out for new techniques or new industry tools to make their work better and increase their productivity. They recommend these tools or techniques to their team, they bring it into their organization and sometimes even teach others these techniques or how to use the tools they have discovered.

New Framework

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec odio odio, laoreet ut feugiat vitae, eleifend at augue. Aliquam libero mauris, vehicula a volutpat tristique, varius quis erat. In ullamcorper odio vel urna aliquet vestibulum. Aliquam libero mauris, vehicula a volutpat tristique, varius quis erat. In ullamcorper odio vel urna aliquet.