This article extends design thinking into a process and method that uses a range of common Business Analysis techniques to drive engagement through collaboration. It provides more structure to either side of the creative process to one better frame the domain of concern, and secondly after creativity has produced ideas, to prototype, refine, test and learn. The article also positions this process as a better way to arrive at a business case or pre-project phase, since it provides enormous insights through an engaging discovery process; something that would never occur within a traditional environment into investigation investment feasibility.

The first step to solve a problem is to frame it correctly. These aren’t the right questions to ask. The real question these BAs should be asking is, “how do I get my stakeholders to stay involved throughout the requirements process, so I can have their input at the right times during requirements discovery, analysis, and validation?”

In a recent Information Technology discussion group I am involved with, someone posed the question, "What is complexity?" I was surprised by the question as I thought it was understood what complexity was all about. Evidently not. The person posing the question was primarily concerned with complexity in system design...

This article explores strategy mapping as discussed within Business Architecture Guild BIZBOK, and attempts to extend the discussion by defining a set of information and graphical principles that allows strategy to be represented graphically.

The UML Component Diagram along with the complementary UML Deployment Diagram shows how a software solution will be delivered and deployed in the form of interconnected components that interoperate via well-defined interfaces. You can think of this as analogous to how electronic components are wired together, and in this context you should consider that any one component may be replaced by a different but compatible component with no adverse effect.

After doing business analysis in the tech industry for ten years, I’ve spent the last 2 years as a product manager. During this period, I’ve realized there’s more in common between the roles of IT business analyst and product manager than I had expected. On the other hand, there are also some aspects of the job that translate into valuable lessons for any BA interested in increasing the value they deliver to their organizations...

In my view BABOK (Business Analysis Body of Knowledge) v3.0, by introducing the BACCM framework, has provided the world of BAs the equivalent or extension of the famous triple constraints (scope, time and cost) that once revolutionized the project management world. BACCM, in fact, encapsulates the triple constraints and goes beyond by empowering the BA in their daily task to ask fundamental yet powerful questions at every stage of business analysis work.

Whenever I mention I am in the "Systems" business, people generally look at me befuddled, smile, and shake their heads. I can tell they haven't got a clue what I am talking about. Many assume it has something to do with computers, and those in the technology sector assume I am referring to software. Frankly, no.

Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.

This article provides an in depth study on the concept of traceability, together with its implications and applications within a business context. Traceability is a term used in the IIBA BABOK, among other professional practices, in the context of requirements where requirements are said to be traced that provides alignment of requirements to each other. This implies that there are different classes or abstractions of requirements such as stakeholder, business and functional requirements. Traceability allows the alignment between all types or abstractions of requirements, telling a kind of story to how they all interrelate. 

This is the eleventh in a series that explains the thinking behind the Volere requirements techniques— previous and future articles explore aspects of applying these techniques in your environment.

This article focuses on the often-asked question: why, when I ask for requirements, do people give me solutions and what can I do to get the real requirement?

This article explores the discipline of problem solving. Some might consider problem solving an art, while others might define it as science. The reality is a little in between since part of problem solving involves creativity, which by definition cannot be rationalized as science since we are basically unaware or not conscious of it occurring. Creative formulation of new concepts and ideas is a process lies deep within the sub consciousness and we are only aware of the output of the creative process; a new idea is a good example. We don’t understand how the idea was created, but we know we thought of it.

 Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

Solution Anthropology encompasses the work of anyone who works directly with the end users so the work is coordinated and consistent. Therefore Solution Anthropology is not one role, but a team of people with the responsibility to delight the end user and a broad skill set to accomplish just that.

 They took a software approach for designing MIDAS as opposed to a system approach. For example, they probably created a data base quickly, then tried to figure how to get data in and out of it. I would suspect the program source code was well written, probably using "Agile" techniques, but the fact remains none of it was designed to work in a concerted manner.