What Do I Mean By “Solve The Problem Abstractly?”

Requirements and Design Phases

Looking at the phases I’ve described in my business analysis framework, I wanted to describe the major difference between the step for requirements and design. The artifacts created as part of these phases, which usually include documentation but can also include prototypes, can vary greatly. I’ve seen these steps take a lot of different forms and I’ve certainly written and contributed to a lot of documents and prototypes that looked very, very different.

As I’ve described in my presentations, the phases in my framework are:

  • Project Planning: Planning the engagement, what will be done, who will be involved, resource usage, communication plan, and so on.
  • Intended Use: The business problem or problems to be solved and what the solution will try to accomplish.
  • Assumptions, Capabilities, Limitations, and Risks & Impacts: Identifying what will be included and omitted, what assumptions might be made in place of hard information that might not be available, and the consequences of those choices.
  • Conceptual Model: The As-Is state. Mapping of the existing system as a starting point, or mapping a proposed system as part of requirements and design for new projects.
  • Data Sources: Identifying sources of data that are available, accurate, and authoritative.
  • Requirements: The Abstract To-Be state. Description of the elements and activities to be represented, the data needed to represent them, and any meta-information or procedures needed for support.
  • Design: The Concrete To-Be state. Description of how the identified requirements are to be instantiated in a working solution (either as a new system or as a modification to an existing system) and the plan for implementation and transition.
  • Implementation: The phase where the solution is actually implemented. In a sense, this is where the actual work gets done.
  • Test Operation and Usability: Verification. Determining whether the mechanics of the solution work as designed.
  • Test Outputs and Suitability for Purpose: Validation. Determining whether the properly function system solves the actual problem it was intended to solve.
  • Acceptance: Accreditation. Having the customer (possibly through an independent agent) decide whether they will accept the solution provided.

The requirements and design phases are sometimes combined by practitioners but I want to discuss how they can and should be differentiated. Also, given the potentially amorphous and iterative nature of this process, I’ll also discuss how the requirements phase interacts with and overlaps the conceptual model and the data sources phases.

As you can see from the description of the phases above, I refer to the requirements phase as coming up with an abstract solution to the problem under analysis. People have a lot of different conceptions of what this can be. For example, it can contain written descriptions of actions that need to be supported. It can be written solely in the form of user stories. My preference is to begin with some form of system diagram or process map to provide a base to work from and to leverage the idea that a picture is worth a thousand words. That is to be followed by descriptions of all events, activities, messages, entities, and data items that are involved.


Even more specifically, the nature of all the data items should be defined. Six Sigma methodologies define nine different characteristics that can be associated with each data item. They can be looked up easily enough. I prefer to think about things this way:

  • Measure: A label for the value describing what it is or represents
  • Type of Data:
    • numeric: intensive value (temperature, velocity, rate, density – characteristic of material that doesn’t depend on the amount present) vs. extensive value (quantity of energy, mass, count – characteristic of material that depends on amount present)
    • text or string value (names, addresses, descriptions, memos, IDs)
    • enumerated types (color, classification, type)
    • logical (yes/no, true/false)
  • Continuous or Discrete: most numeric values are continuous but counting values, along with all non-numeric values, are discrete
  • Deterministic vs. Stochastic: values intended to represent specific states (possibly as a function of other values) vs. groups or ranges of values that represent possible random outcomes
  • Possible Range of Values: numeric ranges or defined enumerated values, along with format limitations (e.g., credit card numbers, phone numbers, postal addresses)
  • Goal Values: higher is better, lower is better, defined/nominal is better
  • Samples Required: the number of observations that should be made to obtain an accurate characterization of possible values or distributions
  • Source and Availability: where and whether the data can be obtained and whether assumptions may have to be made in its absence
  • Verification and Authority: how the data can be verified (for example, data items provided by approved individuals or organizations may be considered authoritative)

These identified characteristics provide guidance to the participants in the design and implementation phases. Many of the data items may be identified as part of the conceptual model phase. These are the items associated with the As-Is state (for cases where there is an existing system or process to analyze). New data items will usually be identified as part of the requirements phase, both for modified parts of the original system and for the elements needed to control them. Data items may also be removed during the transition from the conceptual model to the requirements if an existing system is being pruned or otherwise rearranged or streamlined.

I wrote here about one of my college professor’s admonitions that you need to solve the problem before you plug the numbers in. He described how students would start banging away on their hand-held calculators when they got lost (yeah, I’m that old!), as if that was going to help them in some way. He said that any results obtained without truly understanding what was going on were only going to lead to further confusion. The students needed to fully develop the equations needed to describe the system they were analyzing (he was my professor for Physics 3 in the fall of my sophomore year), and simplify and rearrange them until the desired answer stood alone on one side of the equals sign. Then and only then should the given values be plugged into the variables on the other side of the equals sign, so the numeric answer could be generated. Problems can obviously involve more than single values for answers but the example is pretty clear.

So, the requirements should identify the data items that need to be included to describe and control the solution. The design might then define the specific forms those representations will take. Those definitions can include specific form of the variables (in terms of type and size or width) appropriate for the computer language or tool (e.g., database implementation) in which the solution (or the computer-based part of it) will be implemented. Those details definitely must be determined for the implementation.

The requirements descriptions should also include how individual data items should naturally be grouped. This includes groupings for messages, records for storage and retrieval, and associations with specific activities, entities, inputs, and outputs.


An important part of what must be captured and represented is the information needed for the user to interact with and control the system. The conceptual model, particularly when a simulation is involved, mostly contains information about the process itself, but can clearly simulate a limited scope of user interactions. The requirements phase is where it’s most important to incorporate all contexts of user behavior and interactions.

The two major contexts of user interaction involve manipulations of data items (typically CRUD operations) and initiation of events (typically non-CRUD operations). Another contextual differentiation is the operating mode of a system. Modes can involve creation and editing, running, maintenance, analysis, and deployment, among others.

Skills Required for Different Phases

Identification of activities and values can be performed by anyone with good analysis skills, though it always helps to also have architecture and implementation skills. Business analysts should have the requisite skills to carry out all actions of the requirements phase.

The design phase is where practitioners with specific skills start to be needed. The skills needed are driven by the environment in which the solution will be implemented. Solutions come in many shapes and sizes. Processes for serving fancy coffees, making reservations at hospitality and entertainment venues, and manufacturing hand tools can be very different, and the skills needed to design solutions can vary widely.

A standard, BABOK-based business analyst should be able to analyze and design a process for serving customers directly in a store. Designing a computer-based solution will require different skills based on the scope, scale, and components of the solution envisioned. A solution based on a single desktop might require basic programming experience. A solution based on peer-to-peer networked computers might require experience in programming, inter-process communication, and real-time considerations. A simple, web-based system might require knowledge of basic web programming, different levels of understanding of tools like WordPress, or other automated web-builder tools. An enterprise-level, web-based system might require knowledge of DevOps, server virtualization, cloud computing, and clustering. People mostly seem to refer to this skillset when they use the term solutions architect, though I interpret this term more widely. Designing a manufacturing system might require knowledge of engineering, specific physical processes, and non-trivial knowledge of a wide range of computing subjects. A knowledge of simulation might be helpful for a lot of different solutions.

No matter what skills are required or thought to be required by the design practitioners, the business analyst needs to be able to work closely with them to serve as an effective bridge to business customers. I’m certainly capable of creating designs in most if not all of these contexts, even if I don’t have some of the specific implementation skills. No one knows everything, what’s important is to know what’s needed and how to work with and organize the requisite practitioners.

The skills required for the implementation phase are definitely more specific based on the specific nature of the solution. A business analyst needs to be able to communicate with all kinds of implementation practitioners (in both directions!) in order to serve as an effective liaison between those implementors and the business customers they serve.


Solving the problem abstractly, to me, means writing a comprehensive set of requirements that facilitates the creation of an effective design. The requirements are the abstract representation of the To-Be state while the design is the concrete representation of the To-Be state. It describes what’s actually going to be built. The implementation results in the actual To-Be state.

This entry was posted in Tools and methods and tagged , , , . Bookmark the permalink.

Leave a Reply