The Community Blog for Business Analysts

Dan Tasker
Dan Tasker

Requirements in Context Part 1 - Just Know It!

I have long been a believer in the saying “Context is everything.” As a business analyst dealing with business users, understanding the context of the topic of discussion is essential. In thinking about what constitutes quality requirements it occurred to me that there are a number of additional contexts that play a role. Examples include the organizational maturity level (from Informal through to Optimized) and delivery context (green fields through to package acquisition).

This is the first in a series of articles about business requirements. My primary objective is to help business analysts improve their elicitation and documentation of requirements. With an increased awareness of multiple contexts I believe that the quality of the requirements documented can be improved, and subsequently lead to the better design, development and implementation of business systems.

Mark Twain is credited with saying, “Everyone talks about the weather, but nobody does anything about it.” The equivalent saying in the IT context would be, “Everyone agrees that good requirements are essential, but nobody does anything about them.”A perfect illustration of this is the classic IT cartoon “The Swings”:



What is not funny about this cartoon is that the situation it depicts is as true about business systems delivered today as it was when the above version was published. Over 40 years of struggling, and most often failing to meet user expectations, in spite of unimaginable improvements in technology.

I have no illusions that what I intend to present will magically make it all better. But these articles are at least my attempt to do something about it. If you are reading this it means you are interested in improving your BA skills. Hopefully learning about the impact of different contexts on requirements will lead to that.

The Business Information System Context

I find it virtually impossible to take off my business analyst hat. Any time a family member or friend mentions that they want something – a new car, an electrical appliance, I immediately go into ‘requirements mode.’ I start asking questions intended to help them focus on their thinking in order to lead to making the best choice. It occurred to me that it as I begin to present the various contexts related to requirements that I should set the context for this series of articles. The context of requirements that I intend to focus on is business information systems. And while a complete information system includes a hardware and a network aspect, the requirement contexts that will be discussed will not include these technical aspects. The requirements contexts will focus on business analysts interacting with business users to deliver the functional and information components of a system.

Please note that when I use the term ‘system’, from a requirements perspective that doesn’t mean that every requirement will result in a computer-based solution. Having gathered requirements a subsequent exercise is to determine which of them will be given automated support and which will be left as manual processes.

Functional and Information Components

The earliest “computers” were primarily electronic calculators. They allowed complex formulas to be broken down into individual computational steps. Having expressed these steps in a language the computer could understand the resulting instruction set was ready to receive the data to be manipulated. The end product was a set of calculated results.

When businesses began using computers their objective was to maintain data about their business. Computational requirements were minimal. Simple things like adding or subtracting deposits and withdrawal amounts from a customer’s account balance. The original computerized business systems all performed their functions by reading in batches of data, operating on each record as it went through the system, and producing individual results before the next record was processed.

With the advent of database management systems and access in ‘real time’ to computer applications, more and more business processes could be supported by computers. Today virtually every office worker has a computer on their desk. And thanks to wireless networks and portable devices workers (and customers) outside of the office have access to the information they need when they need it.

With the focus of business information systems being the support of functions that capture and utilise data I offer a variation on the Nike slogan “Just Do It”. The objective of the business information systems we gather and document requirements for should be “Just Know It.”

Functional Context / High-level Requirements

Having established the context for these articles to be business information systems, the journey itself will begin in the next article. In it I will present a technique I have used for many years to help establish the functional context for a requirements gathering effort. The more common term for this functional context is “Project Scope.”

I will also discuss the possibility of combining the scoping exercise with the producing of high-level requirements. The result of doing this reduces that requirements task down to hours rather than days (or weeks). This will be the first of several demonstrations of the strength of applying the thinking that “Context is everything.”

Next article: Requirements In Context Part 2 - The Functional View From 10,000 Feet

This entry was published on Oct 22, 2018 / Dan Tasker. Posted in Elicitation (BABOK KA), Requirements Analysis (BABOK KA) , Business Analysis, SDLC, Process, and Methodologies. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  57 members liked this article

COMMENTS

Kwame Awuah posted on Saturday, December 1, 2018 12:08 PM
I am on the verge of transitioning to BA Pro and these articles from these experienced professionals are becoming great tools for me.
Kwame  Awuah
Neetu posted on Thursday, March 26, 2020 9:12 AM
Dan,

This is a really very informative article and helpful for the BA aspirants as well as for those who wants to brush up their concept.

Regards,

Neetu Gaur
Neetu
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC