IT business analysis (ITMINE) https://itmine.by ru IT Business Analyst is About... the IT https://itmine.by/enarticles/tpost/c05ubp5051-it-business-analyst-is-about-the-it https://itmine.by/enarticles/tpost/c05ubp5051-it-business-analyst-is-about-the-it?amp=true Mon, 16 Jun 2025 12:34:00 +0300 Business analysis Does an IT business analyst need an IT background (a certain breadth and depth of knowledge in information technology)?

IT Business Analyst is About... the IT

Debates about what an IT business analyst needs — beyond the ability to work with information and people — show no sign of slowing down. On the contrary, the line between “this is absolutely essential” and “why bother, let’s just write some code” is becoming increasingly blurred. This shift can partly be attributed to the dominance of Agile. At the same time, the widespread digitization of industries is drawing in professionals from all backgrounds. A common sentiment nowadays is: “I have no technical knowledge or skills, but I want to be a business analyst because development is hard, and BA work doesn’t seem to require being a full-fledged IT specialist.” This trend isn’t inherently negative, but the way it’s unfolding can be disheartening. The consequences? a) We see an influx of poorly executed software products trying (and failing) to digitize our lives. b) Teams hire continuously, yet still struggle to move the train forward. This article isn’t a secret formula for becoming a “true” IT specialist as a BA — it’s more of a personal reflection on some key BA attributes that are often overlooked. Let’s begin with the technical foundation: the IT background.
Does an IT business analyst need an IT background (i.e., broad and deep knowledge of information technologies)?

There’s no clear consensus. This debate has been around for years and will likely continue. Why? Because the role of an IT business analyst varies significantly across companies and projects. Take, for example, a random tester or developer job posting: aside from describing the project, testing types, or programming languages and frameworks, there’s not much ambiguity. But analyst job postings? Unless they’re written by someone who truly understands the role, they’re often vague. You’re likely to be left wondering: what kind of analyst are they looking for (requirements, BI, business processes); what will I be doing (solving client problems, managing requirements, analyzing processes, creating prototypes, sipping cocktails with clients); what’s my actual title — and does it even matter (business analyst, systems analyst, requirements analyst)? Even the BABOK (our main body of knowledge) is so broad that it isn’t IT-specific and doesn't answer these questions clearly. If we truly had to master everything in the BABOK, some might ask: “Why aren’t we billionaires already?” Ultimately, a BA’s role is shaped by two things: 1. The IT domain in question. 2. The specific company, department, or team — and how they define the BA’s responsibilities.
As a result, some analysts design databases, while others transcribe client input and pass it along to the dev team with minimal processing. The former group knows they need technical expertise. The latter may wonder why they need to understand databases at all — aren’t they just passing along clients' and user's needs? Here’s the thing: everyone’s right. Outside of specific corporate bubbles, IT business analysis lacks standardization. Sure, there’s common theory most of us study, but there’s no one-size-fits-all framework for BA responsibilities in IT vs. non-IT environments. And that’s perfectly fine. Every company needs its own layer between clients and developers — one that fits its service model.
So what should aspiring BAs do? One approach is to build a broad, high-level knowledge base — making yourself adaptable across a variety of tasks. Let me give a non-technical example. I’ve interviewed analysts who considered themselves highly valuable, but in the context of a new role, brought almost nothing to the table. Why? They had solved complex problems at their previous company and assumed that success automatically translated elsewhere. Unfortunately, they never studied anything else. Imagine a candidate who believes nothing exists beyond user stories. They’ve mastered splitting and merging stories like a Jedi, know Jira and Confluence like the back of their hand, and can recite INVEST principles if woken up at night. But then they enter an environment requiring detailed requirements, formal artifacts — and their mindset collapses. “I thought specs were obsolete.” Apparently, the world only consists of Waterfall and Agile, which is light and darkness, and user stories work everywhere, right? And that’s a best-case scenario. Sometimes, candidates have worked on such narrow tasks that they’re essentially unemployable outside their former company.
Applying this to the IT background: possessing it significantly enhances your value as an IT business analyst — regardless of company-specific nuances. I’d even go as far as to say: teams developing IT solutions shouldn’t hire BAs who lack an IT foundation. While some projects may function without it, they rarely do so efficiently. Here’s an analogy I like to use: imagine a BA as a consultant at a car repair shop — serving as a bridge between clients and mechanics. Their job is to ensure a smooth experience for the client. The client shouldn’t need to deal with tough mechanics who lack communication skills. Now imagine that this “bridge” is polite and offers coffee to clients and nothing else: their role is to extract the "pain" from the client and pass it to the mechanics; then they decode the mechanics’ jargon and relay it back to the client, hopefully with minimal distortion. Sure, that works. But wouldn’t it be more effective to teach the mechanic to offer coffee? Now imagine Consultant 2.0 — they’re not a mechanic, but they understand how cars work, recognize common issues and can explain symptoms clearly. This version of the BA can analyze the problem upfront; discuss possible solutions in layman’s terms; estimate the scale of work involved; communicate clearly with both mechanics and clients; interpret feedback through a lens of professional competence.
What are the signs that a BA on the team is, to put it bluntly, not really an IT person?

  1. The person works as an analyst but regularly asks questions like “How do I write requirements for X?”. This often reflects a wider team issue — companies reach out to external BA consultants with requests like: "Our analysts are struggling — they don’t know how to write requirements for UI/integrations/algorithms/data/etc." (Um, but isn’t that the core of the job? How did it happen that your analysts can’t actually do their job?)
  2. The rest of the team firmly believes that BAs are unnecessary on the project (they get paid for nothing, hinder real work, aren’t worthy of any respect — choose your line).
  3. This BA’s requirements are the stuff of a mad scientist’s fever dream. “When the button is clicked, it should burst into flames, scream at the user, and initiate an antivirus scan on their machine.” This includes not just feasibility issues, but a general disregard for fundamental qualities of good requirements. For instance: when asked to describe integration with an external system — here’s some random info for you ("I don’t know what an API is or why it matters here"). When describing UI elements — here are the font and color specs ("Wait, you needed something else? Validations? Events? Data? What are you even talking about? I just thought this looked cute.")
  4. When talking to the client, the BA is unable to answer independently and constantly replies with “I’ll check with the dev team and get back to you.” While this can sometimes be the right approach, it shouldn't be the default mode. Even worse — the BA can’t lead a conversation without developers present. Their role boils down to dragging the devs into every meeting and whispering in their ears what English term the client just used.
  5. At internal meetings and events, the BA wears a serious “thinking face” but clearly doesn’t understand the team’s technical discussions. To compensate, they smile a lot and bring coffee to the team. The team appreciates the BA’s communication skills and appearance, but is increasingly leaning toward point 2 above.
There can be many reasons behind these symptoms, and I’ll explore one of them in a future post. But very often, the root cause is the analyst’s weak connection to the IT world. The result is what I described at the beginning: frustrating products and teams that don’t work well as a unit. The effects may not be immediate, but they’re inevitable.
What can we do about it?

Let’s set aside companies with their internal processes and decision-making criteria, and focus instead on what you can do if you want to enter the wonderful world of IT through the “IT Business Analyst” door.

Question one: Do you need an IT background?
Short answer: yes, absolutely.
Question two: How much IT knowledge do you need?
Short answer: who the hell knows... If a single book could fill all tech gaps for all analysts, it would be a masterpiece. The challenge is that the scope of an analyst’s work varies widely. Today you might be learning about APIs, tomorrow it’s iOS UI guidelines, and the day after that — a complex IT system with a lot of hardware-software integrations. Still, every technical domain is built on a core set of principles. And there’s also a frequency factor — for example, you’re far more likely to encounter a relational database than a non-relational one. That’s how most IT education is structured: years of foundational, broadly applicable knowledge first, followed by specialization.Your goal, then, is to define the scope of this foundational knowledge — in both breadth and depth. This isn’t a trivial task, and everyone has their own opinion. Based on my experience working with analysts — teaching and collaborating — here’s what I consider a solid IT foundation:

  • Basics of computer science (what information is, how it’s measured, and how we work with it digitally)
  • Fundamentals of hardware and software (what software is, and its main types)
  • Principles of computer networks
  • How software is developed (architectural components, algorithms, common languages/technologies, software types)
  • The basics of working with databases
Question Three: How do you acquire this foundation?
Short answer: study — ideally, with hands-on immersion. Hello, Captain Obvious.
If you're just starting your life path and higher education is still ahead of you, consider choosing an IT-related major. When you spend years on the foundational topics listed earlier, you begin to think like an IT professional — and speak like one, too. Personally, I’d much prefer someone with a technical background and decent communication-level English than a silver-tongued communicator fluent in idioms and Shakespeare, but lacking technical foundation.
If you already work in IT — as a developer, QA engineer, designer, etc. — and want to transition into a BA role, congratulations: you’re in an ideal position. You already have the technical foundation, so let’s move on.
If you already have a degree (not in IT) and want to switch fields, that’s a tougher path — but entirely doable. First and foremost, accept that you will need to become an IT specialist. Allocate time, be patient, and create a learning roadmap — a proper level-up plan for your character.
Here are some resources and tips:
1. Start with Vinay Trivedi’s How to Speak Tech. Many people recommend this book, and I agree — it’s an excellent starting point. It is concise, so approach it with thoroughness. Never skip confusing parts just to keep reading.
Rule of thumb #1: if something isn’t clear — look it up, research it online, ask IT-savvy friends. Do everything you can to truly understand the topic.
Rule of thumb #2: try explaining what you’ve learned to an imaginary curious child. They're not in IT either, and they’ll only understand it if you break it down to the “building blocks” level.
This approach worked wonders for me back in university exam prep days — I’d walk around explaining concepts out loud to some invisible audience like a madman. It not only strengthens your technical foundation but also improves two other essential skills: (1) quickly and effectively learning new domains, and (2) communicating complex ideas clearly. And of course, good old notes, plans, and mind maps are always helpful.

2. Supplement the book with these online courses:
You will earn a mental medal and +100 confidence points, putting you ahead of 90% of other candidates.

3. A piece of advice I’ve always followed myself:
Whenever possible, do IT-related things with your own hands. Books don’t replace real experience — and the bumps you get along the way are worth it. Yes, they’ll sting at first, but soon you’ll toughen up and learn faster. Some examples:
  • Your OS is glitching or won’t boot? Fix it yourself — even if that means reinstalling it. You might think it’s rocket science, but it’s basic stuff for an IT person. Dig into the registry, flash a bootable OS image to a USB drive. If you constantly run to your team lead crying about “viruses” or “the mouse isn’t moving,” don’t be surprised if your colleagues quietly laugh behind your back. You don’t need to learn how to change your CPU’s thermal paste — just master the software side of things.
  • Something in your workflow is repetitive? Automate it. Write scripts to automate startup tasks, or create VBA macros for office apps. You’ll not only make your life easier, but you’ll also get a huge confidence boost — like you’ve become a real developer. A business analyst who manually repeats boring tasks without thinking of optimization is a strange creature.
  • App not working? Diagnose it, reinstall it, replace it. Learn to troubleshoot software problems on your own. Some painful real-life examples: a BA-to-be who can’t fix a muted mic or handle other Google Meet issues. Trust me — nearly 100% of such issues are solvable with a bit of tinkering, searching, or (as a last resort) asking for help. If software still feels like “magic” to you — or like something dangerous that might explode if clicked the wrong way — you’re likely in the wrong field.
  • Learn how to use the web and Google properly. Most of the above can be solved with just these two tools. Remember: one of the key BA skills is problem-solving. And Google, plus analytical thinking (you are an analyst, right?), is the foundation of that skill. With these two, you can write code, deploy systems, and troubleshoot your PC without destroying it.

4. Advanced practice: build something with your own hands. This one is advanced, but once you’re ready — do it. Try stepping into developer’s shoes and build something that works. A simple example I often suggest: create a basic web app — a homepage or a product list with photos, descriptions, and the ability to add/edit/delete items. Use whatever tools you find — e.g., HTML + CSS + JavaScript + MySQL. Build all the components, test them thoroughly, and deploy it online. Google is enough to guide you through this if you’ve completed the theory from earlier steps. If you have a mentor to guide you through it step by step — even better. You don’t need to memorize what you did — you just need to learn how to do it and get your hands dirty. Your understanding of what “developer in the next room” actually does — and why he sometimes swears — will grow dramatically.

That’s pretty much it. A BA who's an IT guy is an asset. This impacts how “true” tech folks see the BA role, the speed at which a BA can grow, and the effectiveness of teams and their solutions.

Ideally, companies would understand this and stop chasing only short-term hiring goals. But realistically, we may see the opposite. Either way, if you’re looking for something to dive into — whether you're just getting started with business analysis or already writing user stories and smiling on daily standups — this is it. Go for it.
]]> IT Business Analysis Is… Analysis https://itmine.by/enarticles/tpost/tyflu069t1-it-business-analysis-is-analysis https://itmine.by/enarticles/tpost/tyflu069t1-it-business-analysis-is-analysis?amp=true Wed, 18 Jun 2025 09:12:00 +0300 Business analysis How I understand the essence of an analyst: an analyst is someone who’s insanely good at working with information. They can sift through mountains of data, extract the essence, spot connections, and produce something genuinely useful as a result.

IT Business Analysis Is… Analysis

In my previous post, I started reflecting on some of the key underrated factors in IT business analysis — namely, the technical foundation (an IT background). But there’s a second, no less critical factor for an IT business analyst that people tend to overlook just as often: analysis itself — or more precisely, the inclination toward and ability to perform it.

For me (and, I believe, for many others even more so), analysis has always felt like something vague. You think you understand what it is, but when you try to explain it clearly to someone else, you hit a wall and end up relying on buzzwords like “systems thinking,” “analytical thinking,” “logical thinking,” and so on. And trying to properly evaluate analytical skills in an interview? That borders on fortune-telling. I’m interested in exploring this topic in a free-form, reflective way— so this post will be more about thoughts than any actionable advice. I won’t be referencing any hefty sources or diving deeply into theory — because I don’t claim to have that level of expertise. As mentioned, I’ll be working from the understanding I’ve developed through years of practice.

Let’s start with the obvious: what is analysis, anyway? Without overcomplicating things, here’s a snippet: analysis (“breaking down, separating, disassembling”) is a method of investigation characterized by identifying and studying individual parts of a subject. We’ve all heard of financial analysts and other types, so we label ourselves business analysts — while often conveniently ignoring the very core: analysis itself.

Here’s how I understand the essence of an analyst, without tying it to any specific field: an analyst is someone who is exceptionally good at working with information. They can sift through mountains of data and produce something meaningful and useful from it.

As an illustrative example, I love the idea of Sherlock Holmes as the archetype of an analyst. More specifically, the modern Sherlock played by Benedict "what’s-his-name". Remember those scenes where Sherlock looks at something and observations flash across the screen? Each of those is a nugget of information he picks up through keen observation. Then, in mere seconds (unlike our long, painful thought processes), he begins forming causal and other types of relationships between these bits, filters out noise, identifies trends, and draws conclusions. Incidentally, if you ever played any of the Sherlock-themed video games, they visualize this beautifully: you have to draw connections between facts and assumptions yourself to ultimately arrive at a conclusion. In short, Sherlock is the ideal analyst — unattainable, of course, but still aspirational.

Another example is less vivid but stuck with me nonetheless. In Dan Brown’s once-popular novel Digital Fortress, one of the main characters is a woman who works as an analyst for the NSA. I don’t remember every detail, but the general idea was that her job — or that of one of her colleagues — involved processing massive amounts of raw data from various sources (like a human supercomputer), filtering out what was relevant to her superiors, and regularly delivering concise, actionable summaries. At the time, this was a kind of revelation for me: that’s basically what analysts do. The result could take many forms — conveying the processed data to others in a goal-oriented format, identifying patterns, formulating and justifying conclusions, etc. So, an analyst is essentially a specialist in working with information.

If I were to design a knowledge framework for business analysis from scratch, I think I’d put business analysis information at the very center (that's what it's called in the BABOK Guide). Maybe I didn’t study BABOK closely enough and it already does, but I’d definitely emphasize information more strongly in the context of BA tasks. Not goals, because we already know the goal is to bring value or “happiness” to organizations in one form or another — but rather tasks, meaning the steps we take to deliver that value. As described above, the essence of any analyst lies in how they work with information — and business analysts are no exception. Every area and phase of BA work revolves around interacting with information: diving into new domains, collecting countless volumes of data from stakeholders, documents, and other sources; analyzing that data; drawing conclusions (needs, solutions, requirements, etc.); clearly and thoughtfully communicating insights to others — and so on. Everything else — communications, planning, management, and all those smart-sounding, useful words — exists to support this work with information. So really, aren’t we all just Sherlock Holmes? With the exception of the lack of emotionally intelligent communication skills.
So, an analyst is someone who knows how to work with information — really work with it. They know how to gather or extract it well, analyze it properly (surprise), classify it meaningfully, and operate with both facts and assumptions at any stage. They spot patterns, detect trends, link chunks of information together, generate relevant conclusions based on the context — and finally, communicate it all to whoever needs to know (and, you guessed it, do so effectively). Sounds about right? Now let’s pause and ask ourselves: how often do we actually check, evaluate, or even train these skills?

Let me outline what I see as the typical modern BA interview flow:

  1. What books on business analysis have you read? What are “requirements” and what types are there? What does INVEST stand for? Are business rules requirements?
  2. What’s Scrum? What are the roles? How many pages in the latest guide? And why is it now uncool to say "grooming"?
  3. Show us your specs examples.
  4. And if it’s a joint interview, then: “Where do you see yourself in five years?” and other psychomagic from HR.
I’m not saying this checklist is flawed. But when followed mechanically (without attempting to evaluate other, less obvious, yet equally important qualities), I’m convinced it won’t help you spot a truly high-potential analyst. So yes, you get some knowledge check and a side of HR mysticism. Here’s what I’d suggest adding — and what I’ve been doing myself (with varying success, naturally):

  • IT background — either directly or indirectly, noticing what terms the person uses, whether they understand what they’re talking about, and how consciously they apply those terms.
  • Soft skills — especially analysis and everything related to it: structured/analytical thinking and information handling. Plus all the things that enable this: attention to detail, ability to learn, intelligence, communication skills, etc.

If we rebuild the interview flow with this in mind, the initial theoretical parts can be trimmed way down. Because if we’re not assessing hands-on experience but rather knowledge of theory (e.g., with juniors), then a person with strong information-handling skills:

  1. Will pick up what they need pretty quickly — they can digest vast amounts of material in a new domain and start analyzing and structuring it. P.S. By “vast” I mean books. Remember those? And if your memory cells are calibrated for tweets, and your idea of learning is Instagram posts with emojis or 15-minute YouTube explainers — you’re probably not in the right place (dead serious).
  2. Will have a black belt in Googling (which is information work) and won’t break a sweat over something like “how many events are in Scrum” (honestly, do you really need to store that in your brain forever?).
  3. Will carry the day thanks to solid problem-solving skills — which, guess what, are deeply intertwined with analytical thinking.

Now, I’m not going to pretend I’ve got a scoring system ready to measure all this. This isn’t a step-by-step self-help guide or a hiring checklist. What I can do is share a few thoughts on the traits that cluster around analysis.

Systems thinking. This is the ability to look at anything — a thing, a process, a phenomenon — and see it as a system, with components and interconnections. An engine is a system of valves and other parts. A car is a system of systems — one of which is the engine. A highway is a system of infrastructure, vehicles, and pedestrians. So, basically, systems thinking is our ability to mentally break things down into parts, spot relationships, and derive the properties of the whole from those of its components.

Analytical thinking. Closely tied to the above. This is how well we perform both analysis and synthesis: the ability to dive into detail and zoom back out, to shift abstraction levels, to move between a bird’s-eye view and deep-dive mode with ease.

There’s even a theory that analytical thinking is a cognitive style — and that it competes with intuitive thinking. You’ll see this reflected in the MBTI framework in two of the four scales:
  • Sensing vs. Intuition: Do you prefer tangible facts, or gut-feel and patterns?
  • Thinking vs. Feeling: Do you make decisions based on logic, or on emotion?
Now imagine that you, organically, sit on the “wrong” side of both scales. That leaves just 4 out of 16 MBTI types who are naturally wired for solid analytical work. If we assume even distribution, we’re down to 25% of the population. Yes, I know — real people aren’t that one-dimensional, and no one is 100% type A or type B. But still, the best analysts will usually have a strong tilt toward these specific preferences. Of course, this is an oversimplification. But it does illustrate how important these traits are when we evaluate people for analytical roles. And how much more useful they are than knowing the textbook difference between verification and validation. By the way, I do think these traits can be developed over time — through conscious effort and consistent practice. It’s a habit: thinking clearly, logically, and systematically. It’s about choosing to make decisions based on logic and facts — not vibes or mental tarot cards (which, ironically, is a kind of subconscious analysis). It helps to do logic puzzles. Or play well-designed quest games. Or build systems for managing your life (like GTD). There’s a whole internet full of tools — I just want to highlight that this matters.

Problem-solving skills. This is the ability to not just face unusual situations, but handle them effectively. It ties into systems thinking because a solid systems approach is often half the solution. People fall somewhere on a scale — from “total shutdown in the face of the unexpected” to “I’ve got 20 action plans ready before the first sign of trouble even finishes loading.” If you can look at a messy, ambiguous situation, analyze it, generate options based on current constraints, assess their viability, and create a plan — you're getting close to that ideal.

Here’s the kicker: practically every BA technique is a tool designed to facilitate analysis. Which means they’re useful not just for work, but for life in general — and practicing them reinforces the core skills we’re talking about. SWOT. Ishikawa diagrams. Brainstorming. SMART. Mind mapping. Each one teaches you to approach chaos systematically. It’s a virtuous loop: practice strengthens the muscle; the stronger the muscle, the better your outcomes.

In my previous post, I shared signs that a BA lacks IT knowledge. Now let me give you some common red flags I’ve seen related to weak analytical skills — mainly from my training experience, but they show up in real projects too:
  • Struggling with new theory. Even if BA concepts are presented clearly, often, people can’t connect the dots, retain details, or form a cohesive picture. If someone can’t absorb and structure new information effectively, they’ll flounder with the information firehose that is real-world analysis work.
  • Sloppy attention to detail. You’ve run ten discovery sessions, gathered tons of input. Ideal outcome: every word is accounted for or marked for follow-up. What happens instead? People forget, ignore, overlook. That’s a recipe for catastrophic quality issues.
  • Inability to see the system. Let’s say you need to decompose a solution scope. This requires splitting it into coherent, logical chunks. Many struggle with this — producing uneven coverage, mismatched abstraction levels, or mixing user actions with system features.
  • Contradictory requirements. For example, writing a spec where sections live in isolation: data definitions go one way, UI goes another, quality attributes live their own lives. To spot the connections (like how a quality requirement implies a new feature), you need to zoom out and see the whole picture — from multiple angles and heights.

I could list more. These gaps hurt. And they trace back to one root cause: lack of applied analytical thinking. Yes, we’re also facilitators, translators, and bridge-builders. But first and foremost — we are analysts. Let’s not lose the very essence of the role. Because if you remove both the “IT” and the “analysis” from IT Business Analysis… All that’s left is someone who looks nice and talks well in front of a client. Sometimes that’s enough. But I hope, for your sake and your team’s, that you’re aiming for more.
]]> BA Techniques Explained: Use Cases (Part 1) https://itmine.by/enarticles/tpost/ds3340mxt1-ba-techniques-explained-use-cases-part-1 https://itmine.by/enarticles/tpost/ds3340mxt1-ba-techniques-explained-use-cases-part-1?amp=true Wed, 18 Jun 2025 10:38:00 +0300 Business analysis Hi there! In this post, I’ll outline the key things an IT analyst needs to know to use the business analysis technique called use cases (UCs).

BA Techniques Explained: Use Cases (Part 1)

Hey there!

In this post, I’ll outline the key things an IT analyst needs to know in order to apply the BA technique known as use cases (UCs). It won’t be ultra-brief (that’s not realistic), but it’ll be much better than slogging through academic tomes on the subject — like this one, often considered foundational. You only need to grasp the core principles to start using the technique effectively.

One important note upfront: there are many views on use cases, and they often contradict each other. I’ll share the approach I personally find most useful after years of studying the topic, applying it in real projects, and teaching others to do the same. Let’s dive in.
What are use cases anyway? Use cases are a BA technique. That is, they’re a tool or method an analyst can use to accomplish specific tasks. To be clear: a UC isn’t a task in itself. Don’t set “describe a set of use cases for the system” as an end goal. It’s a tool to help you achieve a well-defined objective — one that you should clearly understand and articulate in the context of your project and business analysis activities.
Now, focus on the words: “use case”. A use case is literally a way something is used. In BA terms, it’s how your system (i.e., the one you’re gathering requirements for) — or, more broadly, your solution, as per BABOK terminology — might be used by external entities (called actors). These actors could be people (end-users), or other systems (software/hardware), specifically in IT solutions.
Use cases answer the question: “What meaningful actions can X perform using our system?”
Spell check a document (MS Word).
Add a resource to bookmarks (web browser).
Create a new user (CRM).
Order a pizza (food delivery site).
So, a set of UCs (just a list) is basically the collection of all discrete, valuable interactions that actors can perform with the system.
Two simple rules for formulating use cases:
1. A use case is a single, complete interaction with the system. Came – did something – left. “Spell check a document,” for instance. From a user scenario perspective, this might look like: open Word → Open a document → Launch spell check → Get results → Close the document.
Bad examples (don’t write UCs like this): “Spelling,” “Spell-checking,” “User management,” “Company info”. None of these tells me what exact action a user can perform as a distinct operation.
Yes, there are exceptions — we’ll get to them later — but for now, treat this rule as a strict one.
2. A use case must deliver value to the actor. Let’s extend the above model: Approach the system → Perform UC → Gain satisfaction/value → Leave.
“Spell check” clearly provides value. I can imagine it as a complete scenario where something meaningful is achieved. But something like “Select spellcheck language” doesn’t stand on its own as valuable. Open doc → Select language → Close doc. So what? No value delivered. That’s just a step within a larger UC like “Spell check a document.”
A Non-IT Example: The ATM. Classic interview favorite. You approach a standard ATM. What can you, the actor, do (keeping value and single-action rule in mind)? Withdraw cash. Check balance. Make a payment. Each is a standalone, valuable interaction — you walk away feeling satisfied. Now imagine the actor is not you, but a technician servicing the ATM. Their use cases might include: “Refill cash trays,” and whatever else those folks do (honestly, no idea).
What’s not a UC, but just a step in one? Enter PIN. Select language. Print receipt. Enter amount. These steps are individually meaningless but essential within a proper UC. Yes, sometimes we’ll promote such steps to full-blown UCs — but not at the stage where you’re simply trying to understand what value users get from your system.
Now that we know what UCs are — what are they for? What goals does a business analyst achieve by identifying use cases for the system they’re working on? Quick note: if you already use user stories heavily, chances are many of the purposes below are already covered in your process. Yes, UCs and user stories are different techniques — though they often overlap in practice. Comparing the two is beyond this post. So, what are the use cases of use cases?

1. Shift the perspective to the user’s side. Identifying UCs helps analysts (and stakeholders) view the solution from the user’s perspective: what value will they actually get from using it? This is absolutely critical when defining what the solution should include. Many analysts instinctively design systems based on features: “Dear client, what should our CRM include?” “Ticket management, stats, user access control, etc.” This is the feature perspective. It comes naturally, but it’s dangerous if used alone — it often lacks empathy for user needs. UCs force you to approach things differently: from the actor’s goal → to the system content.

Takeaway: If your projects lack this user-focused lens and you’re always asking “what should the system have?”, try building a UC list. You’ll likely uncover tons of missing, misdesigned, or even unnecessary functionality.

2. Define and manage scope clearly. Use cases are a great way to define and communicate the scope of your solution — and manage it later.

  • As an analyst, you can plan your work UC by UC. Identify UCs → Prioritize with stakeholders → Work on them iteratively. This ensures each step adds something valuable to the user’s experience. And for non-technical stakeholders, discussing use cases is usually way more intuitive than abstract features or fragmented requirements. Compare: “Let’s talk about ordering pizza” vs. “Let’s discuss the contents of the Cart page.”
  • Your PM and devs can also plan releases around use cases: Release 1 — UC X. Release 2 — UC Y and Z. Each release delivers not just partial functionality, but a complete, user-centric interaction.
  • Your testers will love you. UCs are a perfect base for test scenarios and cases. Testers execute an action → observe the result → compare it to expected behavior. And as you’ll see later, detailed UCs naturally support this step-by-step, scenario-based testing.

Caveat: Sometimes UCs aren't the best scoping unit. You may have a system with 10 features but only 2 UCs. That’s not always a good reflection of system content — especially for stakeholder communication. That’s why newer methods like Use Case 2.0 try to bridge the gap — but it hasn’t gained widespread traction. If this is a concern, consider switching to or supplementing with features or user stories.

Takeaway: If you don’t yet have a reliable scope-decomposition technique, try UCs. See how well they work across all roles on your project.

3. Link stakeholder goals to solution requirements. UCs are a solid way to tie stakeholder goals to the requirements of the solution (functional and non-functional). As we’ll see when we talk UC detailing, each UC can include a variety of requirements — meaning a UC is effectively a specification unit:
  • It shows what actors can achieve using the system.
  • It outlines what functionality is needed to support those outcomes.

Takeaway: If you lack a structured approach to documenting requirements, start with a UC list + use case briefs + UC diagram (more on that below). This can serve as a base framework that you either stick with or build upon as needed.

So, how to start working on use cases?

Here’s a quick-start algorithm:

1. Identify all external agents (actors). A context diagram is a great place to start. Actors are those who directly interact with your solution (not indirect beneficiaries — those aren’t relevant for UCs). For now, focus only on actors who gain value from their interaction with the system.

2. Study actor needs. What value do they seek? What must they be able to do with the system to get that value?

3. Turn those into UCs using the rules above.

Sounds basic, right? But in practice, it’s more than just “sit and brainstorm.” If done properly, this bleeds into full-on requirements elicitation and analysis — a much broader discipline with its own techniques and deep rabbit holes.

What can supplement this algorithm?

Use cases can be mapped visually using UML Use Case Diagrams. On the one hand, these are just visual representations of your UC list — and visual aids can be incredibly effective. On the other, they let you show relationships between UCs and actors, adding valuable structure and clarity.

Here’s what a UC diagram for a super-simplified news portal might look like:
The diagram is deliberately complicated to show as many UML features as possible, so don’t judge it as a tool for simplifying communication.

Let’s analyze the diagram:

  1. It’s easy to guess that the ovals are use cases, and the stick figures are actors (remember that actors can represent not only human users but also external interfaces to the IT solution — software or hardware systems).
  2. The arrows are relationships showing which actors can perform which use cases, who is a secondary participant, plus how some use cases or actors are connected to each other.
  3. You can also show system boundaries using a rectangle (the boundary element in UML), but in most cases, this is redundant.

Now in more detail:

The key actor of the portal is User. This means any user of the system. They can be either authenticated (logged in with a username/password) or not. This is represented by a generalization/inheritance relationship — a link between two elements that shows the child is a more specific version of the parent. In other words, the child is the same as the parent but with specifics. An Authenticated User is a User, but with the added detail that this person has logged in. Similarly, an Authenticated User can have Admin rights (or not, being a regular user), shown by another inheritance.

User can perform the use case “View news in a category”, shown by an association between the actor and the use case. Since in inheritance the child inherits all properties of the parent (and usually adds something of its own), all User descendants (Authenticated User, Non-authenticated User, Admin) can perform this use case as well. This makes sense because everyone can view news, regardless of their system status. Why did we add inheritance between actors? For example, a) to associate common use cases with the parent actor to avoid duplicating associations and cluttering the diagram, b) to show a hierarchical structure of actors if we want that on the diagram.

It’s rarer, but still used, to have inheritance between use cases. If two use cases are connected by generalization, it means the child is essentially the same as the parent but with specifics. For example, “Log in to the system” can represent two different useful actions: logging in via Facebook or Google accounts. “Log in to the system” is italicized because it is abstract (or, simply put, it should not be executed on its own) — only its children are performed; there is no actual execution of the abstract login itself, only via one of the two options.

Now let’s look at the use case “Log in to the system”. A curious analyst might protest: how can this be a useful use case on its own? What’s the point of going into the system just to log in? Yes, that violates one of the key rules. But a bad specialist blindly follows rules just for the sake of rules — sometimes it’s worth breaking them for a good purpose. What did we achieve by doing this here? First, we made the scope fuller and clearer (without login, nobody would know that the system has login functionality). Second, we showed that login can be done in two ways by highlighting this “incorrect” use case. Third, we showed that an unauthenticated user also has specific actions — they are not just there for decoration on the diagram.
Now about why some associations have directions (arrows) and some do not. Actors in use cases can be primary or secondary. A primary actor is the one who gains key benefits from the use case (and usually initiates it, but not always); the primary actor must be shown for each use case. A secondary actor participates in the use case in another way and may not always exist. For example, for an ATM system’s use cases like “Withdraw Cash” or “View Card Balance,” the primary actor is the ATM User. The secondary actor could be a processing center — an external entity involved at a certain step of the use case: the ATM sends a request to the processing center to adjust the user’s account balance or to retrieve the balance amount (the ATM itself can’t know how much money is on the account). In our news portal, for the login use case via different options, the secondary actors are the external software systems (APIs) that authenticate the user.

Visually, if your diagram has no secondary actors, associations can be undirected (no arrowheads). If there are secondary actors, to understand who is primary and who is secondary in relation to each use case, arrows must be drawn. Arrows don’t show data flow directions or anything like that — simply, the link goes from the primary actor to the use case, and from the use case to the secondary actor.

Finally, let me explain two types of relationships that show additional connections between use cases — extend and include. These relationships are similar and share properties. First, both tend to complicate diagrams by adding extra meaning, so many recommend avoiding them to keep diagrams simple. Second, different people interpret these links differently. The notation’s creators themselves admit these relationships are ambiguous and advise using them cautiously (ambiguous elements may cause readers to misunderstand the model, defeating the purpose). Third, when using these links, the included or extending elements don’t have to be independently useful use cases. We will see examples soon.

What is include? It’s a relationship between use cases showing that from the perspective of scenarios and other parameters, one use case fully includes another. For example, if as an Admin I add news to the site, I must enter the text of the news. The arrow goes in the direction reading the relationship name. Include lets you model a process and its subprocesses. The included use case (“Add text to the record”) may not be useful on its own — not every use case can be broken down into smaller independently useful ones (ones that can be executed outside the parent).

What is extend? Extend is a relationship showing that one use case can extend another by adding behavior — that is, it may (not must, like with include) act as an addition to the extended use case. The arrow also reads in the direction of the label, but unlike include, if B extends A, it means that during A (“View specific news details”), under certain conditions or by choice, the actor may also perform B (“Comment on news”). B may not be useful on its own — it’s only an optional extension to A. You can’t comment on news without viewing it first. Notice that the emphasis in use cases is on system operations (opening and displaying the news), not just user actions that we can’t control (like just “looking” at news).

In summary, both relationships are useful to show that “during use case X the actor must perform subprocess Y” or “during X the actor may optionally perform Y.” But don’t overuse them — we’ve already mentioned their pitfalls. Still, highlighting key moments like these can be valuable.
In the end, by identifying a set of use cases for the system and visualizing them in a diagram, we’ve solved the first two business analyst tasks mentioned at the start: stepping into the user’s shoes to think about what useful things they can do with the solution, and decomposing the solution’s scope into manageable pieces. Now let’s talk about solving the third task — elaborating and linking system requirements in the context of use cases — stay tuned.
]]> BA Techniques Explained: Use Cases (Part 2) https://itmine.by/enarticles/tpost/c2ohz57ar1-ba-techniques-explained-use-cases-part-2 https://itmine.by/enarticles/tpost/c2ohz57ar1-ba-techniques-explained-use-cases-part-2?amp=true Wed, 18 Jun 2025 11:24:00 +0300 Business analysis Continuation of the article on use cases: detailing use cases.

BA Techniques Explained: Use Cases (Part 2)

How to detail a use case?

To fully describe a use case (UC), you can use the following set of parameters:

  • ID + Name
  • Brief Description
  • Actors
  • Triggers
  • Preconditions
  • Postconditions
  • Scenarios: basic, alternative, and exceptions
  • Other additional points

Let’s break it down step-by-step, with examples.
ID + Name

The identifier should be self-explanatory. Key requirements (such as individual solution scope items) must be uniquely identified for consistent referencing — this is foundational in requirements documentation. What you choose as the ID format is up to you. For example: UC-01.

As for naming, it's best to stay consistent in your approach. I recommend using an infinitive verb: what to do? Usually, some clarification follows the verb — at the very least, it will reference the object of the action.

So, for an ATM: UC-01 Withdraw Cash

For a news portal: UC-03 View News
Brief Description

This section should outline the essence of the use case and the value it brings to the primary actor. It’s optional, but I strongly recommend including it — it saves the reader from needing to study the scenario to grasp what the UC is about. Focus on conveying the value to the actor, rather than simply duplicating the name — that would be pointless.

Examples:
  • The actor withdraws a specific amount of cash from their account using a bank card in order to obtain cash.
  • The actor views the content of a specific news item on the portal to gain detailed information.
Actors

List all primary and secondary actors involved in the use case. Clearly label who is who. To ensure maintainability (one of the hallmarks of high-quality requirements), avoid duplicating actor names throughout the UC. Instead, simply refer to "Actor" (with a note if they are primary or secondary when needed). Don’t use “User” or “Administrator” in every section — keep it abstracted.
Triggers

An optional section. Triggers are what cause the use case to begin. In most cases, this will be the actor’s desire (a motivational impulse to start the UC). But sometimes it's something else, like: "It’s 4:00 PM in time zone X." — in such cases, when it’s not obvious (e.g., "Actor wants to view news"), the trigger should be stated explicitly here.
Preconditions

These are the conditions that must be met for the UC scenario to even begin (not to complete it successfully). They serve as constraints for starting the UC. Essentially, preconditions depend on where your UC scenario begins. To define preconditions, ask yourself (or the stakeholders, if needed):
  1. What marks the start of the UC? What’s the first step and who performs it?
  2. What must the system check to allow that first step to happen?

Your answers to the second question will be the preconditions.

Example: UC-01 Withdraw Cash
Q1: First step — "Actor inserts bank card into ATM"
Q2: "ATM card slot is empty" (what if someone left their card or jammed something inside?)

Example: UC-03 View News
Q1: First step — "Actor opens news item from the feed". Note that here, unlike the previous example, the actor already sees the news feed at the start.
Q2: "News feed is displayed with at least one news item listed". You may also trace this to a successful result of another UC, e.g.: "News feed is displayed with at least one news item listed (see UC-02 View News in a Category)."
Postconditions

These are the conditions/facts/states that are true when the UC is successfully completed. You can optionally include postconditions for exception scenarios too, though this is less common. Postconditions may be visible results for the actor or internal system changes. At a minimum, include the successful result. Anything else is up to your discretion.

Examples:
  • The cash dispensing slot contains the amount withdrawn.
  • The corresponding amount has been deducted from the actor’s linked bank account.
  • A receipt is available in the receipt slot showing transaction details.
  • The screen shows the details of the selected news item.
Scenarios

A scenario is a sequence of steps performed by the actor(s) and the system to fulfill the UC. This is where most functional requirements lie — it’s the system logic triggered by user actions.

Often, scenarios are written like a “ping-pong”: Actor action → System response → Actor action → System response, etc.

There are two main approaches to scenario description:
  • Interface-agnostic: No mention of UI specifics, e.g., “Actor saves Order.”
  • UI-based: Includes interface terms, e.g., “Actor clicks the 'Save' button to save Order.”

Most theories advocate for the first, but both are valid. Use what fits your context. If UI isn’t your concern or is handled elsewhere, use interface-agnostic. If UI components are central to the requirements and not documented elsewhere, it makes sense to include them.

Basic Scenario – UC-01 Withdraw Cash

  1. Actor inserts bank card into ATM.
  2. System prompts for PIN.
  3. Actor enters PIN and confirms.
  4. System verifies the PIN.
  5. System displays available operations.
  6. Actor selects "Withdraw Cash."
  7. System asks for withdrawal amount.
  8. Actor chooses amount from displayed options.
  9. System checks if requested amount is available in the cash reserve.
  10. System sends request to secondary actor to deduct funds from account.
  11. System receives confirmation from secondary actor.
  12. System dispenses requested cash.
  13. System prints a receipt with transaction details.

Basic Scenario – UC-03 View News

  1. Actor opens desired news item from the news feed.
  2. System displays the news content. Can be extended by UC-04 Comment on News.

In the final step, note the extension point — where the actor may initiate a related UC. The UC-04 scenario would begin with a step like: “Actor enters comment text and submits.” To reflect inclusion, simply embed the included UC as a step: e.g., step 3: "See UC-05..." Inheritance between UCs is a more advanced topic and is beyond the scope of this post.

Alternative Scenarios

Alternative scenarios are those that also lead to a successful outcome but differ in some steps. They may:
  • Start differently and later converge
  • Start the same and diverge mid-way
  • Have a combination of both
  • Be fully parallel
Alternatives are chosen based on usage frequency — the most typical path is the basic scenario; others are alternatives.

Alternative Scenario A – Actor Enters Amount Manually
8.1a. Actor selects manual input.
8.2a. System prompts for amount.
8.3a. Actor enters amount and confirms.

Explanation:
  1. Only step 8 of the basic scenario is replaced here.
  2. The "a" suffix identifies the scenario and its steps as unique.
This is just one formatting method — choose what your audience understands.

Exceptions

These do not lead to a successful outcome. They include errors (actor-related or not), cancellations, and other exceptions. They’re vital — you must consider and define them, or developers won’t implement handling.

Examples:

Exception B – Invalid PIN

5b. System shows incorrect PIN message. Return to step 3.

Exception C – Insufficient Funds in ATM

10c. System shows message about unavailable funds. Return to step 7.
(Note: Poor UX — the actor is guessing viable amounts)

Exception D – Secondary Actor Unavailable

11d. System displays message: operation not available at this time.
(Bad UX — actor is stopped near the end of the flow)

Exception E – Printer Out of Ink/Paper

13e. System shows message: receipt cannot be printed.
(Bad UX — actor may want to cancel if receipt is critical)

Exception F – Actor Cancels Operation

2f–8f. Actor cancels operation.
9f. System ejects card.
Additional Points

Use this section for anything else you'd like to document. Typical examples:
  • References to related UCs
  • Links or mockups for UI mentioned in this UC
  • Any supporting requirements, such as: non-functional (performance, usability, etc.), interfaces with secondary actors (data mappings, request/response formats), data requirements (entities, attributes), UI constraints (component visibility, validation, etc.)
And that’s it. Once you combine all the above sections, you’ll have a full UC specification. Describe all UCs similarly and add a UC diagram — and you’re nearly done with your system requirements spec.

Of course, use cases aren’t the only tool in a BA’s toolbox, but for the goals outlined at the start, they’re extremely effective. Go ahead and use them — everything in this post should cover the vast majority of your needs.
]]> BA Techniques Explained: Business Domain Model and Logical Data Model https://itmine.by/enarticles/tpost/tlf8tf9h61-ba-techniques-explained-business-domain https://itmine.by/enarticles/tpost/tlf8tf9h61-ba-techniques-explained-business-domain?amp=true Wed, 18 Jun 2025 11:46:00 +0300 Business analysis In this essay, I’ll share my perspective on two closely related models in business analysis — the domain model (aka business domain model) and the logical data model.

BA Techniques Explained: Business Domain Model and Logical Data Model

In this essay, I’ll share my perspective on two closely related models in business analysis — the domain model (aka business domain model) and the logical data model. The first one can eventually give rise to the second, and both are essential structural visual models that any self-respecting analyst would be wise to keep in their toolkit.
Let me clarify right away: I’m a strong advocate for distinguishing between the terms “model” and “diagram” in most contexts. A model is something that is a result of a BA’s work; it’s what we deliberately construct to provide insight or value. A diagram, on the other hand, is a tool we use to represent that model. You could call them differently, but here’s an example: take the popular UML modeling notation, where you have things like “Use Case Diagram,” “Activity Diagram,” etc. With the Use Case Diagram, its purpose is fairly clear — it’s hard to misapply it, even if some approaches distinguish between business and system use cases. But when it comes to drawing, say, an Activity or Class Diagram, the results vary wildly depending on the BA’s level of knowledge and imagination. Some overly enthusiastic analysts even start sketching out software class structures.
What’s truly helpful to understand is that diagrams like the UML Class Diagram are just hammers — it’s all about using them to hit the right nails. And in this context, the right nails are those two models I mentioned earlier. A UML Class Diagram isn’t the only suitable hammer — there are ERDs (in various notations), IDEF0 diagrams, and several lesser-known ones. But for our purposes, we’ll focus on these models through the lens of UML Class Diagrams, which I’m especially fond of. Let’s dive in.
Exposition. You've just kicked off a new project and are relentlessly questioning the client, trying to decipher their latest scheme for world domination. Gasping for clarity, you’re teasing out fragments of their vision and requirements, navigating through a jungle of unknown business terms, rules, policies, and more.

Let’s bring this to life. Imagine your client wants to create a website guide for the enchanting world of The Witcher by Andrzej Sapkowski, aiming to monetize it via premium subscriptions (we’ll skip modeling the monetization bit to keep things simple). Suppose you’ve understood the target audience and the general idea, and now you want to deeply immerse yourself in the world — not just to churn out content, but to really grasp what the client wants to include and how to advise them strategically.

This means, at some point, you'll need to study the domain (also known as the business domain). According to our beloved BABOK, a domain is a sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.. Well… they tried. In my own words: it’s a field of knowledge directly tied to a Change (remember the BABOK’s Core Concepts), defined by its shared information, terminology, and common characteristics.

In our example, the domain is The Witcher universe. In your project, it might be insurance in China, healthcare in Zimbabwe, or food delivery — anything that represents the business side of your project (i.e., the client’s or users’ activities).
Immersion in the domain:

You’ve decided to dive into the domain — to understand the world Mr. Sapkowski crafted so you can meaningfully participate in ideation with the client. What do you need to do? Naturally, study all available sources, starting with the originals. Sure, you could ask your client to tell you a bedtime story, but that’s hardly professional. If I were the client, I’d politely (or not) ask why you can’t study the materials first before asking questions.

So, you dive into the books, then the games, and even suffer through the Netflix show in the evenings, groaning at how poorly they adapted the material. Your main challenge here is to document the knowledge you gain. You need to structure and organize it — filter out the fluff and tie everything together into a coherent picture. Trust me, you’ll end up with a mountain of information. If your approach is to just “absorb and recall” whatever sticks, it’s time we talked about your qualifications. You need some form of structured distillate from all the materials (we’ll call this a “summary” for simplicity).

Let’s abstract away from our example. Suppose you've used your full arsenal of information-gathering techniques: interviews, document reviews, web research, observation, etc. Now you have a final set of domain knowledge. What form is it in? A chaotic mess of notes? Good luck finding answers later. You'll have to re-analyze everything. It's clearly better to organize it for usability. Beyond just presenting it in structured text form, I’m a fan of two approaches in such situations:

1. Mind Maps

A simple yet incredibly powerful way to present information as a tree structure. As you study the material, you note down key points hierarchically — each level of branches representing a deeper level of detail. You continuously reconcile new info with previous notes, refining them as needed. It’s intuitive and, with some practice, becomes a go-to method for structured knowledge capture:
2. Domain Model

What is it? A visual model (diagram) that uses boxes and arrows to represent key concepts in the domain (its entities, terms, actors, etc.) and how they relate. It reveals the structure of the domain.
How to build it?

As you study your information set, identify the key nouns (concepts, objects, actors — we’ll call them domain entities) and place them as elements (classes, if we’re using UML Class Diagrams). Then pick out the verbs — actions, processes, events, or relationships — and connect the entities using them (we’ll call these relationships).

At its simplest, that’s all there is to it.

Let’s go back to our earlier Witcher example. Say you started by reading general articles online. Here’s a summary excerpt:

The series’ main character is Geralt of Rivia, a witcher — a monster slayer protecting humans. As a child, he was taken to Kaer Morhen, a keep where witchers undergo mutations enhancing their speed, stamina, and poison resistance. He is known by nicknames like the White Wolf (Gwynbleidd), the White-Haired Witcher, and the Butcher of Blaviken. His main job is slaying monsters for coin. His life changes when he becomes guardian to a girl named Ciri, who is hunted by both Northern Kingdoms and the Nilfgaardian Empire. Geralt seeks to protect her and navigates his complex relationship with the sorceress Yennefer.

This is already a condensed version, but let’s turn it into a model using the approach above. I won’t detail every step of the transformation, but I invite you to compare the text with how it maps onto the diagram.
You’ll notice I also added comments — some of the questions that might naturally arise when reading this for the first time without prior knowledge of the domain. And that leads us to the first and arguably most important benefit of this modeling approach: it helps a BA analyze information. Just reading the text, I doubt I would’ve immediately thought of those crucial follow-up questions. You’ll soon see even more advanced modeling aspects that support deeper analysis.
Аdvanced modeling:

1) More sophisticated relationships, beyond the basic arrow (which, by the way, is called an association in UML). UML provides three types of relationships that are particularly useful to analysts and have more specific meanings than the universally applicable association:

Generalization or inheritance. This is a relationship between two elements indicating that the descendant is a further specification of the parent — that is, the element it inherits from. In other words, the child is essentially the same as the parent, but with its own specifics. It is represented by a solid line with an empty triangle at the end. For example, suppose we have a class Student of Learning Center X. A Student of Learning Center X is a Student, but we’ve added a new qualifying parameter — the learning center. Between Student and Student of Learning Center X, we can draw a generalization relationship. And we can continue the chain: Student of Learning Center X → Student of BA Courses at Learning Center X. So, as we move deeper, the classes become more and more specific and less abstract. By the way, inheritance implies that the child class adopts all properties (attributes) of the parent class, but typically adds something of its own.

Aggregation and composition. Both these relationships represent the “whole-part” relationship. In simple terms, they describe one element being included in another. If aggregation or composition goes from A to B, this means that A is a constituent part of the whole B. What’s the difference between these two types of relationships? Aggregation is shown as a solid line with an unfilled diamond at the end; composition, with a filled diamond. But that’s not all. Aggregation is considered a weak relationship, while composition is strong. If the conceptual destruction of the parent object leads to the destruction — literal or figurative — of its children (this could be physical destruction, marking as removed, archiving — anything that signifies destruction in the domain), then it’s a strong relationship. If the child objects continue to exist, the relationship is weak.

Let’s look at some examples. What is aggregation? Example: Student – Group. Suppose a student in a learning center attends both a Business Analysis course and a Database course. Now ask: if the BA course group is disbanded, do all its students lose their meaning as entities — are they destroyed as objects? No. A person still remains a student of the learning center and might be in another group or none at all — just recorded in the system as a past or future student. Therefore, this is a weak relationship.

Now, what is composition? Composition is when the components of a system are inseparable from it and have no meaning outside of it. For instance: Course of Learning Center X → Learning Center X. If the learning center is dissolved, the concept of its courses ceases to exist too. All courses are conceptually destroyed as well. This is a strong relationship.

2) Multiplicities on relationships that clarify their nature. Multiplicity on a relationship shows how many objects, or class instances, may exist at each end of the relationship.

Let’s take the Student – Group example again, where there is aggregation between them. Let’s define multiplicity at both ends of that aggregation. What questions should we ask to determine this? For multiplicity near the Student class, we ask: how many Students can (insert the name of the relationship — say, “belong to”) one Group? The answer (let’s say) is 10 to 16.

Now for the multiplicity near the Group class, the question is similar but reversed: how many Groups can one Student belong to? We've reversed the relationship direction. The answer: zero (and yes, they’re still a Student — perhaps they enrolled in a program that doesn’t require group participation, which is exactly why we used aggregation, not composition), or an infinite number (with no known upper limit), which is denoted by an asterisk (*).
3) Grouping elements by thematic areas or spreading them across different diagrams to reduce clutter and improve readability. I suppose this is self-explanatory.

Let’s try to apply these extra features to the previous model. I’ll remove the earlier questions (assuming we’ve answered them or at least noted them — no need to clutter the diagram now) and add some new ones prompted by the added modeling aspects, as well as additional info obtained.
As you can see, the models:
a) became more readable (some might disagree though),
b) became more informative (assuming one can read specific relationships and multiplicities),
c) raised a number of additional questions.

A few practical tips:
  • Name associations according to the direction of the arrow (for associations only — the other types of relationships are generally self-evident and don’t usually need labels).
  • Use multiplicities on relationships (except generalizations) wherever they might add even a bit of value. This is additional information that, when properly analyzed, can provide tons of insight and serve as a source for useful business rules (e.g., “An order cannot be empty when submitted to the company”).

Now I can take these models and either:
  • bring them to a stakeholder meeting, presenting and explaining them to confirm my understanding of the domain or to get useful feedback, or
  • present them to the team to convey my understanding of the domain, clarifying any ambiguous points during the presentation.

This is the second major goal of models like this — and all visual models, really: to simplify communication with stakeholders. Not in the sense that I’ll send the diagram with a “figure it out yourself” message and expect instant mutual understanding, but in the sense that showing this visually will make discussions around the areas I’m interested in — or confirming my understanding — much more effective than if I were to just explain everything I’d read on my own.

And going forward, I can either discard these models once they’ve served their purpose (though that feels a bit wasteful), or I can continue to maintain them as I study more books, games, or the TV show, expanding and updating them as needed. Naturally, with deeper exploration, the models will grow many times over. The key, as with all such techniques, is to learn to spend just the right amount of time on these artifacts — so the value they generate justifies the effort. You can only find this balance through trial and experience. And of course, learning the tools to work fast and confidently is always helpful.
After countless sleepless nights and completed phases of business analysis, you move on to developing solution requirements. As many know, solution requirements come in two flavors: functional and non-functional. But what fewer people are aware of — and even fewer apply in practice — is the fact that functional requirements can lie in two dimensions (or, to put it another way, it’s helpful to view them from two perspectives): the system's behavior (functionality) and the data that this behavior operates on.
Remember that the IT analyst’s focus is on information systems? The term “information” isn’t there by chance — it’s the cornerstone of software solutions. These systems operate on information, on data. So, a rather obvious but important conclusion follows: when dealing with requirements, it's helpful both for yourself and others to see what kind of data or information your solution will handle.

Let’s set aside the debate over whether you should be dealing with this layer of requirements at all — it depends on your business analysis approach combined with the project methodology, your view on what constitutes complete requirements, the position of the planets in the sky etc. What truly matters is that it should be a conscious decision — not one forced by ignorance or lack of knowledge.

But let’s say you do decide to dive into this part. So, what can help you here?

A solid foundation is a model called the logical data model.

Since the analyst’s view ideally shouldn’t be clouded by implementation details, this model is called logical, meaning it’s not tied to physical implementation. The analyst doesn’t know in advance whether the information will be stored in a database (and if so, will it be a relational one or not), or just dumped into text files. Or maybe the data won’t be stored at all, but rather hard-coded directly into the system.

The good news is that a logical data model:
a) often evolves naturally from your domain model — many of the same entities and attributes might appear here too (which makes sense, since the solution automates the domain),
b) is built using the same diagrams (for instance, UML Class Diagrams are perfect here, which we’ll explore further),
c) uses the same modeling techniques we’ve already studied.

And what’s more — it’s usually very well received by the development team, who’ll shower you with gratitude for including such an artifact in your requirements.

The bad news? You need to approach this model far more carefully and rigorously than the domain model. If the domain model is your creative interpretation of the domain (and it’s entirely normal to have radically different but equally valid models for the same domain), then the logical data model shouldn't have that kind of variability. If it does, it likely signals a flaw in your requirements — one that will come back to bite you.

Let’s move on to our example. Imagine that, after several iterations involving pliers and blowtorches applied to the client, you’ve determined that the website should be a catalog of articles describing the Witcher universe, with authenticated users able to leave comments on them. Articles are organized by category. Any user (verified or anonymous) can view articles, but only admins can create, edit, and otherwise mess with them. A simple example, but let’s complicate it a bit: comments must go through pre-moderation by an admin after posting, with the comment author notified of the result.

This is, howerver, the kind of case where the contents of the data model will hardly overlap with the domain model. The Witcher universe, with all its inner workings, gets transformed into different concepts within the context of the software system. Into what exactly? Let’s revisit the system description and think about the kinds of information the solution will manage. There will be articles, and those articles will have categories. You could argue that category is just another atomic attribute of an article, like its title. But let’s add some context: the client wants admins to manage categories (CRUD), including the order they appear in the site menu. Now that atomic attribute becomes a more complex component and, therefore, a separate entity in the model. Articles can have comments. The system will have users — after all, you need to handle registration, authentication, and authorization, which means storing a certain amount of information per user. And if we assume comment feedback is delivered via an internal notification system, then notifications are also a part of the system.

Let’s translate all that text into a model and use some of our familiar modeling tricks. It might look something like this:
A few notes on the model:

1) Attributes now have data types, unlike in the domain model. In fact, the domain model often didn’t even have attributes in classes unless necessary for clarity. The data types here are logical — described in plain language from the analyst’s point of view (you can choose the terminology that works best for you and your team). Later, in the physical data model, these will be converted into whatever implementation-specific types your team needs — char, string, int64, and so on. But as we said earlier, let's stay above the implementation for now.

That said, detailing attributes and their data types is a useful and important part of data requirements. Just keep in mind that if you're also maintaining a data dictionary, repeating attribute details in the model might be redundant.

Two interesting types you can use in this model (or replace with others depending on your team’s preference):
  • Enumeration – a predefined, finite set of values. Unlike plain text, where the value can be anything, enumerations are fixed. For example, a Comment’s Status might always be one of: “Approved”, “Rejected”, or “Pending”. You’d list these specific values in your data dictionary or supplementary documentation.
  • Data types matching entity names – for example, the Author attribute of a Comment has a data type of User. What’s this about? Well, think about it: when we say a Comment has an Author, what do we mean? A text value? A login? You could show the relationship using just an atomic attribute (e.g., a login that links comments to users), but I personally prefer this approach: showing that the Author of a Comment is an instance of the User entity, with all its internal structure. Thus, the attribute has a composite type — namely, the entity User.

2). Some comments on relationships:
  • Comment–Article: This is a composition, because a Comment doesn’t make sense without its parent Article. If an Article is deleted/archived/etc., its comments are purged too. A Comment only exists under one article. An Article, however, can have no Comments or many.
  • Article–Category: A bit more nuanced and reflects a subjective take on requirements (which, in a real project, should be clarified with the client). This is an aggregation, because deleting a Category might just move the Article to an “uncategorized” group or prompt a Category change — not delete the Article. Thus, Articles can exist in or outside Categories. Unassigned ones might not appear to regular users until categorized.

3). Admin and Reader are modeled as separate entities to show that only a specific kind of User interacts with comments and notifications. Otherwise, this distinction wouldn’t be necessary — they’re just users with different role values.

So what can I do with this model? The goals are the same as for the domain model: to facilitate your own analysis and improve communication. More specifically:

  • Doing this kind of modeling will raise many helpful questions: Can an article exist without a category? If so, how should the system handle it? What content types are allowed in articles? What happens to comments when an article is deleted? What comment statuses are there? What information must users provide for entity X? And so on. Each new perspective on requirements reveals insights you wouldn’t catch otherwise. Here, we’re looking at requirements through the lens of data. Think about system behavior, security, implementation constraints, etc., and new knowledge (and new questions) will emerge.

  • It’s also a requirements artifact — something you hand over to those implementing the solution and later verifying it. Include it in your specs, upload to Confluence, reference it in your stories — these are additional requirements that increase the likelihood of delivering value through business analysis. It also helps with requirements traceability, reducing the risk of incomplete or poor-quality requirements. For instance, if you start with the data and build behavior around it, you’re less likely to forget something important — or build something unnecessary. Example: you decide articles need a Date and Name. Later, you design the CRUDL functionality for articles. If admins can edit articles, this model will remind you whether editing includes changing the name or just the content. It may even lead you to question: why do we need a publication date? If it never shows up in behavior, maybe drop it? Or maybe it should be displayed on the UI?

  • And let’s not forget how useful this model can be when coordinating with external stakeholders. Sure, it’s not beginner-friendly (and to the untrained eye, nearly incomprehensible), and you might have to guide their focus. Still — though it’s not an essential part of every project — there are times when discussing requirements over a beer, using this lens, reveals key nuances. In fact, I once had a project fail precisely because such a model wasn’t created and key details — like class multiplicities — weren’t clarified. So yeah, it matters.

These are just two powerful mini-techniques. Of course, we’ve left out many practical nuances about when and how to use each model — but it’s best to just try it out in the field.
]]> BA Techniques Explained: CRUDL https://itmine.by/enarticles/tpost/s0fm1g8sj1-ba-techniques-explained-crudl https://itmine.by/enarticles/tpost/s0fm1g8sj1-ba-techniques-explained-crudl?amp=true Wed, 18 Jun 2025 13:21:00 +0300 Business analysis Let’s talk about a simple yet extremely powerful and useful business analysis technique — CRUDL.

BA Techniques Explained: CRUDL

Hey-hey!

Let’s talk about a simple, yet extremely powerful and useful business analysis technique — CRUDL.

To begin with: CRUDL is a requirements analysis technique. Sounds fancy, but in reality, it just means it’s a method that helps a business analyst make sense of the information they’ve received. We all know (or at least suspect) that completeness is one of the key quality criteria for requirements. In this case, we’ll be talking about completeness in relation to a set of requirements, not just individual ones. So, we know that completeness is a big deal, and that gaps in requirements lead to all kinds of negative consequences. One way to analyze the completeness of your requirement set (and thereby help you achieve greater completeness) is by using CRUDL.
Can this technique ensure the completeness of any kind of requirement? Unfortunately, no. For example, when analyzing the completeness of quality attributes, CRUDL won’t help you at all. So let’s define the boundaries of applicability while also explaining the essence of the technique.

CRUDL is a checklist of typical operations performed on "things" within an IT solution:

  • Create — creating an object
  • Read — viewing information about the object
  • Update — editing/changing information about the object
  • Delete — deleting the object
  • List — viewing a list of objects (this is a secondary operation compared to the previous ones: whenever there are many objects, in order to view or modify a particular one, you usually need to first browse the list and pick the one you're interested in)

Checklists in general are extremely useful when analyzing completeness. Say you’re packing for a vacation — how do you make sure you don’t forget anything important? Use a checklist! By going through a list of typical things you take on trips, you ensure the completeness of your packing process. If you’re a super-organized person, you probably have checklists for anything you do more than once — it’s obvious that human memory just doesn’t cut it in these situations.

The applicability spectrum of CRUDL lies in operations on objects within a system. This typically helps in analyzing the completeness of system scope: any significant operation on an object in the system usually represents a large chunk of functionality or an important user action, and thus — due to its size and significance — it becomes part of the system scope, a vital element of the solution’s makeup.

So, what are these objects we should be applying CRUDL to? They are data entities — part of your data requirements for the solution. In one of my articles, I discussed a useful concept called a logical data model. So, you should apply CRUDL to the big components of that data picture — in other words, entities, not their attributes.

Let’s walk through the algorithm of using CRUDL, using an example.
1. You need to learn to identify data requirements within the bulk of information you’re working with.

What are data? Data are the information handled by the solution. Alongside processes (algorithms) that manipulate this information, data make up the functional requirements of the solution. Let’s not forget that as IT analysts, we work in the realm of information technology solutions. Every IT system handles data — it receives it as input, transforms it, sends it back to users or other systems — one way or another, information will be involved in your system. So, the ability to recognize and systematically represent that information in your requirements is a crucial skill.

Example:
A client comes to you with a fiery startup idea: to create an online portal for booking at-home fitness services. Let’s say part of their initial description goes like this:

I'm a fitness trainer myself, and I also have lots of friends who’ll be listed as trainers on the site. I want the site to be a reliable place that allows clients and trainers to interact. People should be able to quickly and easily find the trainer they want, check out reviews, and book and pay for the service.

Let’s do a basic text analysis and identify the data the system will work with. We’re deliberately skipping discovery phase and business analysis activities like needs analysis or business requirements elaboration — they’re important, but not relevant here. So let’s assume you and the client have already agreed on what and why you’ll be building.

From the given text, the obvious candidates for our future data model are the following words. Trainers, clients — these are clearly Users of the system. Add to that Services — something Trainer-users offer to Client-users. Reviews will be associated with Trainers. For now, that’s enough to proceed. A seasoned analyst might think further — about payment mechanisms, admin panels, and other implicit pieces — but we’re just starting out and learning how to identify such elements. Basic analysis tells us that in the system, the following data will be stored (or at least operated on):
  • Users (of two types: Trainers and Clients)
  • Services (linked to Trainers)
  • Reviews (linked to Trainers and left by Clients)

That’s our initial data analysis — done.
2. Apply CRUDL to each data object you've identified at this stage.

In our example, it’s still early: we don’t know much about the system yet beyond a few sentences from the client. But CRUDL can be used at any stage of a project — whether you’re just starting out and exploring the system scope, or processing change requests during maintenance of a working system. Whenever a new request emerges that includes some data, you can apply CRUDL to check if at least the basic operations have been considered.

How to apply the technique?

There are tons of variations online — mostly different table formats for structuring your CRUDL analysis. But in my opinion, the table format is secondary; you can run this analysis entirely in your head without documenting every step.

Let’s try one of the simplest versions:

Check which parts of the CRUDL mnemonic were explicitly or implicitly touched on in the source text. Not necessarily literally — think about how each base operation might be present in context.
You’ll probably find that only a few cells are filled, leaving many blanks. And that’s great! Because this is exactly where CRUDL shines — it helps identify missing pieces.
3. Do something useful with the results of your analysis.

Sounds vague, but really, what you do with the results (i.e., the obvious gaps in requirements) is up to you. Usually, the next step is to formulate a bunch of questions for the client or other stakeholders (especially end users) and go clarify them.

Here are some of the helpful questions our CRUDL analysis + basic skills helped generate:

a) What user categories will the system support? Is it correct to assume there will be Clients and Trainers, each with different functionality available?
b) Will there be user account management (creation, editing, deletion)? If so, will it be handled by some kind of admin — which would imply a third user category? If not, how do users get into the system? Will there be self-registration for either user category?
c) Should Trainers or Clients be able to view their interaction history (their trainers/clients)?
d) How will trainers manage their offered services (create, update, delete)?
e) Can a client cancel, modify, or view the history of booked services?
f) Who is allowed to leave reviews? Can a review be edited or deleted?

You'll get answers — likely revealing new data elements, to which you’ll apply CRUDL again. And so on.

Now imagine how much richer and clearer your system design will be after this process. Also imagine what would happen if your team just dove into development based on the initial idea without spotting these gaps — that often hits projects hard (not in every project, but still). And all it took was knowing five magic letters and using your brain just a little to apply them.
Later on, you can customize CRUDL however you like. You can add depth to the technique — for example, documenting not just whether an operation is needed, but also who has access to it based on roles. Or you can expand it horizontally, adding more letters to your operation checklist — popular additions include:

  • S — sort
  • S — search
  • F — filter
  • M/C — move/copy

And just like that, CRUDL becomes even more powerful for you personally.
To sum up, the CRUDL technique is a tool in the analyst’s arsenal that belongs to that elite group of 20% of techniques that deliver 80% of the value. In other words, it’s quick to use, easy to apply, and helps you avoid missing huge, critical chunks of your requirements. And those are the kinds of things we love and treasure.
]]> Functional Requirements Through UI Description https://itmine.by/enarticles/tpost/j11k9bbpn1-functional-requirements-through-ui-descr https://itmine.by/enarticles/tpost/j11k9bbpn1-functional-requirements-through-ui-descr?amp=true Wed, 18 Jun 2025 13:38:00 +0300 Business analysis The goal of this article is to demonstrate how a business analyst can effectively communicate functional requirements for a software solution to the development team using the user interface (UI) as the starting point.

Functional Requirements Through UI Description

The goal of the article is to demonstrate how a business analyst can convey functional requirements for a software solution to the development team — with maximum detail, while using the user interface (UI) as the starting point.

Disclaimer: This is a beginner-friendly article — which means it will contain its fair share of philosophically debatable ideas that seasoned BA-jedis love to grumble about over a beer. Still, many things will be deliberately simplified in order to provide practical tools and recommendations. That said, some level of theoretical understanding of business analysis will definitely be required.
Let’s first set the context. What is the ultimate task of a business analyst in our reality? To communicate requirements to the development team. What kind of requirements? Solution requirements — so that the team can build a solution that aligns with the expectations of the client and future users. And what are solution requirements, exactly? They’re the final level in the hierarchy of requirements (for example, the BABOK hierarchy), consisting of functional and non-functional requirements. Let’s put aside non-functional requirements — they are out of scope for this article. Most part (and the most important part) of solution requirements is functional requirements — those that define what capabilities (functions) the system must offer, and the content of those functions. If we break down functional requirements further, one commonly used (though not BABOK-official) perspective suggests they consist of two main components: behavioral/functionality requirements (the core part) and data requirements (secondary, describing the data this behavior operates on). We'll also set aside data requirements for now — they are their own area with separate techniques and approaches.

So, the refined question becomes: what are the possible approaches for documenting the core functional requirements expected from a business analyst?

There are many. If you’re an analyst actively working with requirements, you’ve probably heard of or worked with several of these:

  • User Stories with acceptance criteria (commonly used in agile/adaptive BA approaches)
  • Use Cases with detailed steps
  • UI prototypes with textual annotations
  • Plain-language descriptions (frequently seen in environments with no mature BA processes)
  • ...and so on.

But what if, based on your chosen BA approach, you need to document these requirements as thoroughly as possible? What are your options then? Obviously, this level of detail isn’t always required — but it’s easier to simplify a task you know how to do deeply than to go deep when you only know how to skim the surface, right?

It’s generally accepted that artifacts containing the most detailed requirements are associated with predictive approaches:

  • Software Requirements Specification (SRS)
  • Functional Specification, and other synonymous terms that essentially describe one thing: a document that outlines detailed solution requirements.

However, the way functional requirements are expressed within such documents can vary greatly, influenced by standards, preferences, and practices. For example, maestro Karl (Mr. Wiegers, that is) suggests writing functional requirements in the SRS like this:
Now, I wouldn’t say this is the most detailed possible approach — but here we bump into a key question every analyst must consider: Who is responsible for UI/UX in your project team?

The user interface and user experience are sometimes part of solution requirements, and sometimes not — depending on the project context. Why is this important? A classic analyst focuses on requirements. They typically avoid diving into implementation details (like database structures, system architecture, etc.). Classic analysts aim to keep requirements at the "what" level, not the "how" — for example, the N in INVEST for user stories insists that stories should capture what is needed, not prescribe how it must be built.

So then — what do we make of UI, with all its forms, fields, dropdowns, and buttons?

The answer depends entirely on the norms in your company/team/project. Typically, if there's a dedicated person who handles UI/UX — and can do it better than you — then UI is not part of the requirements. Instead, it's part of the solution design, and the analyst’s job is to stay UI-free.

The example from Karl Wiegers above shows how to describe requirements without referencing UI. User Stories with a properly maintained "N" follow the same principle. Classic Use Cases do the same — remaining interface-agnostic and implementation-neutral.

But is this always the case in practice? Not really. Often, analysts are responsible for UI design simply because no one on the team is better suited for it. In such situations, integrating UI into the requirements and treating it as part of the requirements specification is totally valid. And this is where I want to share a basic approach that allows you to describe system behavior in almost maximum detail — using the UI as the foundation.
Everything I describe below is primarily aimed at highly detailed artifacts like SRS etc. However, that doesn’t mean this approach is limited to such documents. If you’re a flexible analyst who doesn’t believe in rigid dogma, you can just as well inject this type of content into your User Stories or Jira tickets if it serves your documentation goals.

Let’s take a simple example that involves both viewing and entering information into the system. Say we have a basic product catalog with the ability to add a new product — a simple web page for an e-commerce system. From a UI standpoint, our system consists of one page and a pop-up window for adding a new product.
Let’s get back to the methods of documenting behavioral requirements mentioned earlier and briefly recall how you might convey such requirements to the team:

  • Create a set of User Stories (e.g., “Browse Products” and “Add Product”) in Confluence and fill them out with acceptance criteria (in GWT format or any other).
  • Do the same using Use Cases instead (e.g., “Browse Products” and “Add a New Product”) with full detail (preconditions, scenarios, and other parameters), and place them wherever you like (like that same Confluence, why not).
  • Create a wireframe (as above) and annotate it with textual notes. This is a perfectly valid option for such a “super-complex” system — why overcomplicate things? 😊 Simply attach it to the task in Jira as requirements.
  • Compose an SRS following the example from Karl Wiegers’ book above, with all the bells and whistles like a title page, revision history, and other formalities.

Of course, these aren't the only ways to present requirements — the combinations of techniques, artifacts (i.e., containers), and storage systems are nearly endless. But the ones listed here are the frequently used ones.

My goal here is to demonstrate how requirements can be presented in the context of the last approach on that list — the SRS — and with a focus on UI. So, let’s do that.

If you're writing an SRS, most templates will include a section named similar to Functional Requirements, which is exactly where your behavioral requirements should go — describing how the system is supposed to act. In terms of document structure, it might look like this:
In this section, it's helpful to group the requirements based on the elements of the solution's scope. These could be features, use cases, or even user stories.

Within each subsection in section 2 (in our example above), there’s a subsection called User Interface Overview — which is where we’ll spend most of our time in this article. Naturally, if you have requirements unrelated to the UI (e.g., email notifications sent by the system), you’d simply rename this section to something else, since the UI would be irrelevant there.

So, what exactly should go into the User Interface Overview section?

First, identify the key structural elements of your UI (pages, screens, pop-ups, etc.). These will be the backbone for structuring requirements within each feature. Then, map each UI element to its corresponding feature. For example, in our case it might look like this:
Once that’s done, all that’s left is to fill in the content for each subsection. Sounds simple, right? 😊

Start with a brief description of what the UI element is and what it’s for. Here, you can also show (or link to) a wireframe to help readers visualize the set of controls it contains and how they're laid out.
Next comes the real work: you’ll need to describe the requirements for the UI blocks (if any) and the individual controls in a table. Every type of control has its own nuances that need to be accounted for, so early on, I suggest keeping a checklist or even embedding one in your SRS template that reminds you of what aspects to consider, clarify, and describe for each control type. As you gain experience, you’ll naturally start adjusting the level of detail — sometimes skipping some aspects or emphasizing others — and for rare or custom controls, you’ll develop a sense of what’s worth specifying to ensure the team has all the necessary input for implementation.
Below, I’ll provide a sample table filled out for the controls in our example, and I’ll also briefly explain what aspects to keep in mind for commonly used control types not covered in the example.
Here’s what your table should include:

1) Control Name — I recommend using the exact label that will appear next to or inside the control (if there is one). That way, you won’t need to document the labels separately.

Important: If you're specifying data requirements (the second key part of functional requirements, complementing behavioral ones), and I definitely recommend it, the element name can also serve as a link to the associated data attribute described in the Data Requirements section. Most controls are either displaying or collecting data. For instance, when you look at the Item textbox in the Add Item pop-up, it’s meant to input the name of the item into the system. Likewise, the first column in the Items list table displays the same name. This implies there's an Item data entity somewhere in the system that includes an attribute called Name, among others. Different UI elements either display or allow input of this data.

2) Type — Identify what kind of control it is. It’s assumed you’re familiar with the basics of UI design and prototyping, so we won’t go over the full range here.

3) Description — Briefly describe the purpose of the control from the user’s perspective. If it’s obvious, feel free to skip it.

4) Visibility and Availability — Depending on user roles or system states, certain controls (or entire blocks) might be visible or hidden, enabled or disabled. This applies mainly to interactive controls. For example, you might disable a field until the user fills in a previous one. Capture such specifics here.

5) Format, Validation, Behavior, and Other Key Aspects — This is where most of the functional requirements related to UI controls go. You can split this into multiple columns if you prefer. Here’s what to consider:

  • Exact labels' texts
  • Validation rules — Specify validations for input controls (text fields, dropdowns, checkboxes, etc.), like mandatory input or format checks. For example, Item, Category, and Price should be validated as required fields, and Price also should be validated for numerical format.
  • Controls behavior — Describe what happens when users interact with the control — e.g., clicking a button, selecting a value, losing focus, typing, etc.
  • Display/input format — Example: a price entered as a decimal number (e.g., 1000.00) but displayed in the table with a currency symbol or as “N/A” if missing. This level of formatting detail should be captured.
For other controls and other specifics not shown in the example, here’s what to consider:

  • Menus: List and order of values, default state
  • Links: Target location, open in new window/tab?
  • Radio buttons, checkboxes, dropdowns: list of values, default selection, sorting of values in the list
  • Text inputs: Input masks, placeholders, default values
  • Icons/buttons: Tooltip texts

Again, build your own checklist as you go. If developers ask you for clarification (or worse — if a bug shows up because something was unclear), that’s a sign it should probably go into future requirements.
6) Additional Notes. For example, if it’s unclear what exactly to display in a table, spell it out here (and link to the relevant data entity in the Data Dictionary). Let's fix that for our table in the above example:
A couple of final points:

  • Controls can be reused across the UI, and as we all know, duplication is bad for maintainability. So document such shared elements once and just link to them.
  • Same goes for any other reusable information.
The result? A complete set of functional behavioral requirements based on the UI, leaving minimal room for misinterpretation — which is exactly what a BA often needs when communicating requirements to a dev team.

Of course, as we noted earlier, there are contexts where this approach could be overkill. In mature Agile teams, this kind of rigidity can backfire — remember the Negotiable part of INVEST for user stories? Teams may prefer to co-develop requirements collaboratively, and roles like UX designers or frontend developers may not appreciate strict prescriptive specs. Plus, detailed specs can stifle creativity — some developers prefer a bit of freedom rather than following a step-by-step manual.

But that’s part of broader BA planning and choosing the right documentation strategy.

What we’ve focused on here is how to write detailed behavioral functional requirements tied to UI elements — in case that’s the right tool for the job in your situation.
]]> Agile vs. Waterfall: Specifics of a Business Analyst’s Role https://itmine.by/enarticles/tpost/7runvmaib1-agile-vs-waterfall-specifics-of-a-busine https://itmine.by/enarticles/tpost/7runvmaib1-agile-vs-waterfall-specifics-of-a-busine?amp=true Fri, 20 Jun 2025 11:51:00 +0300 Business analysis Your first thought upon reading the title might well be, “Oh, for f—… not this topic again.” And honestly — I totally get it. I'd have the same reaction myself... but, hold on.

Agile vs. Waterfall: Specifics of a Business Analyst’s Role

Your first thought upon seeing the title was probably something like, “Oh for f… sake — another teardown of this topic?”

I get it, truly. I’d react the same way — if not for one small thing: I fundamentally disagree with most of the takes I’ve seen on the matter.

So maybe hold back the outrage for now — this content might surprise you. And if you’re an analyst whose work experience is equal to or less than the time Agile has been a thing, I especially recommend you read on.

Let’s dive in.
So what’s the current dominant view on software development process models?
You’ve got Waterfall: linear, rigid, ancient — mammoth dung — clearly outdated and ripe for retirement.

And then there’s Agile: bright, righteous, modern — iterative at its core and therefore obviously superior.

So, naturally, most discussions frame it as a binary: good vs. evil. Let’s unpack that a bit.

What is Waterfall, really? Let’s not overthink it — straight from Wikipedia: The waterfall model is a breakdown of developmental activities into linear sequential phases, meaning that each phase is passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.

I’m not going to dissect the model itself — we can all read, and the internet is full of comparison articles. Yes, it seems that for the vast majority of projects, Waterfall is wildly inefficient. And Agile often feels like the prescription we’ve all been waiting for. However the same Wikipedia states the following: Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.

That’s your first clue: the world isn’t made of just Agile and Waterfall.

Let’s move on to something more solid: the PMBOK Guide, 7th Edition. Surely a bit more rigorous than Wikipedia:

A development approach is the means used to create and evolve the product, service, or result during the project life cycle. There are different development approaches, and different industries may use different terms to refer to development approaches. Three commonly used approaches are predictive, hybrid, and adaptive.

1. A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. This may also be referred to as a waterfall approach.

2. Hybrid approaches often use an iterative or incremental development approach.

3. Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive.

Still not convinced? Let’s remember our beloved Karl Wiegers, who captures all this beautifully — in a single diagram:
Now let’s bring in some logic:

Before the Agile Manifesto dropped in 2001 — and long before its principles made their way into Eastern Europe — people still managed to get software built. If you think it was all pure Waterfall — teams sobbing while grinding away at an absurdly rigid, linear process — think . Iterative development approaches have been mainstream for quite a while now. None of the projects I or my colleagues worked on pre-Agile ever used the term “Waterfall” or followed its principles religiously. People simply worked iteratively — but without putting Agile values and principles front and center.

So, what’s the takeaway? When people compare Waterfall to Agile and inevitably conclude that Agile wins, they’re comparing a horse to a jet plane — and then smugly pointing out how much faster and better the plane is. But they conveniently ignore the fact that cars came in between, and for a long time completely dominated the transportation scene. Likewise, most teams who don’t follow Agile today aren’t doing Waterfall either. Even worse: if your team waves the Agile flag but lacks any real grasp of the mindset and values behind it (which is not uncommon), you’re basically working the same way as those so-called “dinosaurs.” Just because you renamed iterations to “sprints” and chopped up specs into “user stories” doesn’t mean you’re Agile. Don’t kid yourself. And no, I’m not talking about edge cases where the horse actually is better. I’m talking about the statistical majority of projects.

What does all this mean for a business analyst?

First of all, I’ve often seen people contrast a “monolithic spec created predictively at the start” with “just-in-time user stories.” Agile evangelists love this narrative — it showcases the “power and flexibility” of Agile. But again, it’s horse vs. jet, good vs. evil. In all my years working as an analyst before Agile went mainstream, I can count on one hand the number of times I had to write a complete spec before development began. Requirements were developed iteratively — even if we didn’t call them “user stories,” they weren’t fundamentally different in nature. Classic artifacts like specs and technical documentation can be developed iteratively. They can also be broken into chunks not unlike user stories. This caricature of pre-Agile analysis as rigid and inflexible is both misleading and limiting. It narrows your toolkit and forces you into artificial constraints.

Next comes a section for relative newcomers — focused more directly on business analysis. We’ll discuss planning the business analysis approach within the context of development models, based on the BABOK framework — but with my personal spin.
There’s a wonderful knowledge area in the BABOK called Business Analysis Planning and Monitoring. It focuses on organizing business analysis activities within a project, managing their execution, and adjusting plans through ongoing monitoring.

The very first task in this area is to Plan Business Analysis Approach. This involves defining — in broad strokes — how business analysis will be conducted, whether by an individual or a team. This decision significantly influences the structure of work, the techniques to be used, and the artifacts to be produced.

BABOK categorizes approaches into two major types:
  • Predictive (favoring upfront planning)
  • Adaptive (favoring flexibility and responsiveness over early planning)

Sound familiar? These are similar to the software development approaches described in PMBOK. There's no mention of a hybrid approach, but of course, it exists — just imagine these two types as endpoints on a spectrum, with a wide range of practical, real-world variations lying in between.
The predictive approach aligns with traditional development models like Waterfall or more rigid iterative methods — where phases are clearly defined and deliverables are planned in advance. Requirements in this context are usually gathered early — either for the entire project or for individual iterations.

The adaptive approach, by contrast, is built on flexibility — a “respond as we go” mindset. Unsurprisingly, it fits neatly with Agile and other less formal iterative models, where the team may take a “we’ll figure it out when we get there” attitude toward requirements. This naturally comes with higher risks — something critical might surface late and require costly rework — so adaptive methods are more suitable for flexible contracts or projects where mistakes are less costly.

Key Differences Between Predictive and Adaptive Approaches:
1. Requirements Development & Documentation
Traditional business analysis tends to favor thorough documentation. Agile (which we’ll use here as shorthand for Adaptive) leans toward lightweight documentation and stronger collaboration. If an Agile analyst can walk over and have a quick chat instead of writing a long requirements doc — they will.

Yes, it’s faster and often more efficient. But lighter documentation comes with trade-offs and risks — a topic for another article. For now, let’s focus on artifacts.

Two key attributes define BA artifacts: formality and level of detail.
  • Formality refers to the lack of freedom in document templates.
  • Detail means both the depth (how thoroughly requirements are specified) and the breadth (how comprehensively they cover the system).

Highly detailed artifacts capture everything — down to the smallest algorithmic nuance — and often include multiple “views”: user-oriented (Use Cases), system-level (Functional Specs), data-oriented (Data Models), and so on. Formal, detailed artifacts are typically structured according to strict templates (like full-scale SRSs, or comprehensive Vision & Scope documents) — the kind that Agile analysts tend to avoid.

On the other end, Agile artifacts (User Stories with acceptance criteria, wiki pages with UI mockups and annotations) are often informal and incomplete by design. Traditional analysts may scoff at them as “rough drafts,” but these formats allow more creativity from developers.

There’s a deeper philosophical divide too:
  • Traditional techniques aim to build a knowledge base of evolving, up-to-date requirements.
  • Agile techniques focus on task definition — “Build this specific thing.”
An SRS reflects the system’s snapshot of requirements and evolves as the product evolves. A User Story? It’s a one-time task that becomes obsolete after the release.

As you’ve probably guessed, predictive approaches gravitate toward formal, detailed artifacts. Adaptive approaches embrace lightweight, flexible ones.

2. Techniques for Eliciting & Managing Requirements
Traditional BA favors deep-diving techniques — Use Cases, SWOT, Risk Analysis, Financial Analysis — all aimed at capturing both the current state (AS IS) and the future state (TO BE) with precision and care.

Agile analysts, on the other hand, often use lightweight tools like Lean Canvas, Impact Mapping, or Personas to move faster, even if a bit less thoroughly.

3. User-Centric Thinking
Agile puts the user front and center. Not that traditional approaches ignore users — they don't — but they evolved in a time when systems were more backend-heavy and user experience wasn't prioritized.

Agile’s rise brought new techniques rooted in empathy: Personas, User Stories, Customer Journey Maps — many of which blur the line between BA and UX. These techniques are now standard in Agile and help prioritize real user needs over rigid system specifications.

4. Distribution of Workload Over Time
In traditional approaches, analysts do most of the heavy lifting early on — during the project’s initiation or planning phases. They may later step back, only providing occasional support or updates.

In Agile, work is more evenly spread out. Requirements are developed iteratively, often in two-week cycles, with the analyst actively involved in every sprint. There's also continuous interaction with the team and stakeholders — because documentation is lighter, conversations are critical.

Agile also encourages progressive elaboration of requirements. Where traditional analysts strive to finalize and polish everything before passing it to developers, Agile analysts intentionally start with rough ideas and refine them as development progresses.

5. Change Management
In traditional models, change handling depends heavily on the contract. If the client tries to alter the scope mid-project, the analyst may respond: “Sorry, that’ll cost extra.” Or they may embrace it, especially under a time & materials agreement.

Agile is more consistent: change is expected and welcomed. The focus is on short-term plans. Sure, there’s long-term planning, but in Agile, you assume everything could shift — and it often does. New sprint, new priorities. Agile analysts smile and adapt.

6. Roles and Responsibilities
Traditional teams are role-based. The analyst “owns” the requirements and works with stakeholders, but the responsibility rests primarily on them.

Agile promotes cross-functional collaboration. Requirements are everyone’s concern. The analyst facilitates early discussions and involves technical experts right away. Together, the team shapes and refines those rough requirements over time. This shared process distributes ownership and increases team alignment.

Choosing the Right Business Analysis Approach:
To wrap up, here are some practical factors to consider when planning your BA approach:
  1. The development model and methodology in use. As you’ve seen, certain approaches are better suited to certain frameworks.
  2. Risk and complexity of the solution. The more critical or complex the system (e.g., medical software, military applications, nuclear systems), the more formal your approach should be.
  3. Contractual model and client preferences. Strict contracts (e.g., fixed price) usually call for a more predictive, structured approach.
  4. Stakeholder distribution. If key stakeholders are geographically dispersed or in different time zones, predictive methods are often more effective due to communication constraints.
  5. Team experience and stability. A seasoned team can handle ambiguity better and fill in the blanks creatively. The less stable the team, the more valuable formal, persistent artifacts become — especially for onboarding and continuity.
  6. Longevity of requirements. Will requirements need to be preserved long-term (for maintenance, support, regulatory compliance)? Predictive artifacts serve better as lasting knowledge bases.
Final thoughts. Ultimately, the most sustainable approach is one you tailor to your project. That’s why it’s crucial to understand the spectrum of BA approaches and their nuances. Expand your toolkit of techniques, artifacts, and strategies, so you can build a solid, flexible foundation — whether for yourself or your team.

What doesn’t help is treating Agile as gospel and User Stories as the one true BA technique. If you can only operate within the Agile playbook, you’re not truly an adaptable analyst — and that will limit your ability to succeed across different contexts.
]]> Stereotypes in Business Analysis https://itmine.by/enarticles/tpost/2y300ok231-stereotypes-in-business-analysis https://itmine.by/enarticles/tpost/2y300ok231-stereotypes-in-business-analysis?amp=true Fri, 20 Jun 2025 12:19:00 +0300 Business analysis Common misconceptions to challenge if you want to enter and grow in IT BA.

Stereotypes in Business Analysis

Let’s talk stereotypes. A stereotype is a preconception based on an image that’s formed for one reason or another. And no, they don’t come out of nowhere — they stick around because, once upon a time, they made sense. Like how IT folk used to paddle along quietly, not daring to question their PM masters. Or because someone loud enough shaped the narrative — “it is written in Father Karl’s holy book, and that’s gospel now.” Or simply because it’s profitable — “Come study with us and become a superhuman in three months.”
I’ve worn many hats in the business analysis world: hands-on practitioner, process builder, recruiter, trainer, mentor, consultant, stakeholder, developer on the receiving end, and PM assessing project efficiency. The stereotypes I’m about to dive into are ones I regularly hear — but that contradict my experience and understanding of the profession. So, here’s a take — a personal one — on what’s damaging to treat as gospel if you’re looking to get into and grow in IT business analysis. At times, it might sound a bit more blunt than necessary, but hey — who gives a ****.
1. Analysts doesn't really need to be IT-smart.

Let’s define “IT” here as everything from “wow, what’s this box with wires under my desk?” to “I’m a full-stack dev, thank you very much.”

Here’s the backdrop, relevant to most points in this article. For a long while, tech folks were cruising on smoothies and hype, enjoying themselves. But then — boom — crisis hit. Globally, locally. And when belts tighten, companies start asking tougher questions. Suddenly, the analyst who stares at code like it’s alien tech is no longer that necessary.

Theoreticians — especially Western ones — love describing analysts as the client’s advocate, part of their team. In reality, at least in my experience, the analyst belongs to our side — the dev team — and their main function is to set tasks clearly so we don’t burn brain cells deciphering vague demands. Nobody needs an analyst who shows up saying, “I have no clue what you’re doing here, but look how well I transcribe people’s words.”

I’ve written more about how such analysts are perceived by teammates. Business analysis may be where non-tech meets tech, but my strong recommendation is: prep yourself for a serious grind into IT knowledge. If you don’t, chances are you’ll later be lamenting the job market or wondering why your team treats you like dead weight.

There’s been a lot of whining lately about how IT is “crazy now” and expects everyone to be a Swiss army knife. But honestly, IT is just returning to how it was meant to be: specialists who are sharp and versatile. Sure, it’ll relax again someday — but guess who’s first in line to be cut when things go south?

2. Being an analyst is all about communication.

Nope. It’s about analysis and working with information. And yes, communication helps you gather that information — but it’s a means, not the core. A level-12 bard might win you over with charisma, but the analyst’s value lies in what info reaches the team, how it’s structured, and how well it guides the project. I've said a few words about it here.

Love talking to people? Great — business analysis will feel natural within the IT role spectrum. But sales and PMs also love talking. The real question is: do you also enjoy digging into complex problems? Are logic, structure, gap analysis, synthesis, and fixing inconsistencies your thing?

There’s no real global standard for BAs. Companies plug gaps with what they’ve got. Sometimes, the gap is just a buffer between the dev team and the outer world. At first, it all seems perfect — stakeholders are smiling, developers don’t have to stumble through English on Zoom calls. But soon enough, mammoth-era issues start creeping in: messy, incomplete requirements, scope creep, bloated systems, outdated knowledge bases. How did that happen? Well, because we reduced BA work to “good vibes and smiling at meetings.”

Don’t get me wrong — communication is a critical BA skill. But equating business analysis with communication? Come on.

3. Modeling notations are pointless now.

The point of modeling isn’t just about the shape of the arrows. Sure, the era of diagramming UML for UML’s sake is mostly over. But when you study UML, BPMN, IDEF, DFD or BDSM, what are you really learning?

You’re learning:

  • Multiple ways of looking at a problem. UML gives you use cases, architecture, states, data structures. BPMN adds process views. IDEF adds functional breakdowns. DFD — data flows. These aren’t just diagrams — they teach you mental models that you wouldn’t come up with on your own.
  • Diagramming as a skill. How to visualize things clearly, completely, efficiently. Notation forces you to be precise — not because it’s rigid, but because smart people spent years shaping those rules.

Even if you end up drawing things your own way, an analyst familiar with proper notations will produce models that are more focused, clear, and effective. Their toolbox is just bigger.

4. Traning courses are a waste — self-study is everything we need.

Why pay for a course? Everything’s online already, right?

I hear this one a lot — and it really gets under my skin, since I design training programs and put a lot of effort into making them useful. And let me be clear: I am talking about quality education here — not scammy info-products.

Learning has always been a go-to way to build skills. You could ask, “Why go to school when there’s a library and the internet?” And sure, in theory, you could self-teach. But in practice:

  • You need direction. Instead of wading through 50 blog posts, videos, and Instagram carousels, you get curated, structured, and relevant material — ideally backed by real experience. Honestly, 70% of BA content online is junk. Your “quality filter” might differ from mine, but the noise-to-signal ratio is real.
  • You lack context. BA in the US ≠ BA in Eastern Europe. Agile ≠ Waterfall. The author's background matters — otherwise you’re blindly applying tactics that might not even fit your situation.
  • You can’t tell motives. Flashy posts promising double salaries and +115% efficiency? Often clickbait to sell you something. Can you always tell the difference between useful advice and influencer fluff?

Also, people undervalue what learning with a offers:
  • Feedback. Good courses tell you what you’re doing wrong and how to fix it — your errors, not generic ones.
  • In-the-moment insights. The gold is often in tips like “hey, here’s a better way to handle that situation.” You won’t find that in a blog post.

Even if you're a self-study wizard, advice from someone who's lived through real cases beats generic Reddit threads or ChatGPT prompts. Yes, finding a great course isn’t easy. But that doesn’t mean learning through structured education is inherently bad. Honestly, I can usually spot the difference between a self-taught BA and someone who had proper guidance — it shows in the way they think, speak, and connect ideas.

5. Theory is BS — just practice matters.

Let’s clarify: smart words might be for interviews. But understanding theory is how you shape your practice.

I’ve seen two takes:
  • “There’s nothing to learn, really. Writing user stories isn’t rocket science.”
  • “I learn best by doing — give me work, skip the theory.”

Here’s the issue: if your experience comes solely from practice, it’s likely narrow, specific, and limited. Without broader context, you’re stuck with “what’s worked for me so far,” even if it’s suboptimal. I’ve talked about this a lot — the less you know about alternatives, the fewer tools you bring to the table. And guess who gets shown the door when projects get tough?

BA isn’t rocket science — but it is complex enough to benefit from a solid theoretical base. That foundation helps you avoid reinventing the wheel or making dumb mistakes just because “you didn’t know better.”

6. Agile is life. Nothing exists beyond it.

Agile simplified a lot of things for analysts — which is great. But also risky. If your experience begins and ends with product owners, backlogs, and user stories, you might be seriously underprepared for anything outside that narrow scope.

I’ve met analysts who only know Agile — and frankly, they often lack depth. The assumption is: BA is simple, agile is standard, everything else is outdated. But here’s the thing:

  • Tons of companies aren’t Agile — either by context or by choice.
  • Some are hybrids or still transitioning.
  • Others actively reject Agile — and laugh at story points and Trello boards.

Agile made things easier. But it also removed a lot of the deeper, “messier” aspects of analysis. What are requirements? Just user stories? Take a look at an SRS or BRD template sometime. Think all that’s obsolete? Think again.

Yes, Agile focuses on what matters most — but it also discards a lot of things that still matter, just less visibly. If you only know Agile, you might completely miss those parts of a project where domain modeling, non-functional requirements, gap analysis, or goal setting are key.

As part of the training, when asked “Why do we start with specs and predictiveness in the 21st century?”, here’s how I explain it: this job is 80% about being a smart, skilled analyst. Once you’ve learned how to handle the hard stuff, switching to the simple stuff (like agile) isn’t a big deal. That remaining 20%? We’ll tackle it together — quickly and painlessly. Honestly, a strong analyst could pick up agile on their own, because they’ve already got the foundational thinking in place. But the reverse doesn’t work: if all you know and do is “simple,” stepping up to more complex work — when it’s suddenly needed — can become a wall you just can’t climb. And sometimes you will need to climb it. And if you fail when the work moves beyond your familiar sandbox — guess who they'll point at first when the White Frost comes knocking? :)

Some other points, briefly:

  • An analyst’s level is defined by their knowledge. About 50% of that knowledge can be gained through training — assuming it’s quality training and approached seriously. The rest comes with time, as you grow deeper into the same core concepts. But what really separates a junior from a mid or senior analyst is experience. Real, hands-on, in-production experience. That’s what determines how you work: under guidance (junior), independently but with occasional help (mid), or like a boss (senior).

I recently saw an ad for a revolutionary course: BA from zero to mid in a couple months. Miracles never cease.

  • Business analysis is easy. Speaking as someone who’s spent years as a developer: nope. BA isn’t easier. Reaching the point where you can solve real-world problems with code takes time — the learning curve is steep. BAs need fewer hard skills to get started, sure, and they can probably start contributing to projects faster. But let’s not forget about soft skills — which are far harder to build — or the nature of the work itself. Easy to learn, hard to master. Yeah, I’m simplifying, but as a developer, you’re given a clearly defined task (if the BA has done their job), and then you put on your headphones and do what you do best. A BA, meanwhile, faces tasks like “dig up the unknown, turn it into knowledge — somehow, with someone — and you’ve got two weeks.” The stress levels can be higher too: presentations, workshops, entertaining clients.

  • A BA is about the soluton only. Digging into a client’s motivations and internal processes is useless and even harmful. But have you actually tried? Tried doing it well? Have you seen what happens when the client and the team share a clear understanding of why something is needed and how it’s going to be used? Have you seen the client’s reaction when that happens? Mindless requirement scribes are, in my opinion, slowly becoming extinct. There are many shades of doing IT thoughtfully — with a focus on value for both the client and the users — and even shaping that value through supporting processes. Often, this needs to be done gently, subtly, with care. But if you think digging into SMART business goals is a waste of time, that doesn’t necessarily mean your role starts only at user stories' level.

  • Hiring is pretty much the same everywhere and it’s driven by efficiency. First off, there’s still no clear, universal definition of what a BA even is — no industry-wide agreement on what analysts should or shouldn’t do. Companies don’t have a consistent view either (remember: they’re often plugging holes), and when that’s filtered through a recruiter’s lens, it becomes even murkier. Most BA job descriptions are just copy-pasted from other postings or built from buzzwords in books. In this kind of environment, breadth of knowledge and experience is your advantage. I often get asked: “Can you guarantee that what I learn from you will be enough to land a job?” No — and no one can. Unless the training is built for one specific company’s needs, all we can do is help you become what the market sees as an “average BA,” and maximize your chances of hitting that target. The scope of BA responsibilities is huge — so huge that BABOK is basically a high-level abstraction. The real-world variations are endless. Keep that in mind if you’re aiming for this field.

  • We spend most of our time talking. That’s the shiny image that attracts people who are “bored of writing code.” But based on everything above, understand this: in about half the roles out there, that’s just not true. If you want to be a BA in IT, ask yourself: will you be okay typing? A lot? BAs type constantly — carefully, clearly, and with structure. Sometimes that’s 90% of the job: documents, emails, guides, specifications. And that’s where I’ve seen people get disappointed — in training and in the role itself. They expected fun conversations and client meetings. What they got was writing a 100-page spec — not exactly a creative joyride. So, to avoid that disappointment, ask yourself a different question: do you enjoy working with information: extracting it (from multiple sources — especially people), analyzing it (spotting gaps, contradictions, dependencies), documenting it carefully and clearly. In short: do you enjoy turning chaos into clarity? Does that resonate with you?
]]> Requirements vs. Non-Requirements: Where the Analyst Ends https://itmine.by/enarticles/tpost/2tgrvzz6y1-requirements-vs-non-requirements-where-t https://itmine.by/enarticles/tpost/2tgrvzz6y1-requirements-vs-non-requirements-where-t?amp=true Fri, 20 Jun 2025 12:47:00 +0300 Business analysis Understanding the boundary between requirements and adjacent information: why it matters and how to approach it.

Requirements vs. Non-Requirements: Where the Analyst Ends

Let’s talk about requirements — what they are, why it’s worth understanding them, and why we should separate them from the rest of the project’s information. At first glance, this might sound like philosophical hair-splitting, but I’ll try to show that it actually has practical value — especially in cases where the role of an IT analyst is misunderstood (which happens more often than you’d think). And to explain that properly, we’ll need to start from a broader perspective.

The global understanding of what an IT business analyst is supposed to do on a project is vague. A quick scroll through job postings from different regions is enough to see it. And then there are related titles that sound like synonyms but aren’t quite: systems analyst, product owner, requirements analyst — and so on.

The IIBA (International Institute of Business Analysis), which attempts to standardize the profession, lumps all of these under the “business analyst” umbrella and defines the role in the most abstract terms possible: analyzing organizational needs and developing solutions. According to that view, a BA could be someone writing user stories all day — or a business architect working on strategic-level decisions.

I personally don’t find the “business + systems analyst” hybrid (popular in Russia and some other regions) to be the most effective model — I’ll touch on that later. So I tend to lean toward the IIBA’s broader approach, especially since it’s more widely adopted globally. Under that model, a business analyst is someone who, as mentioned above, helps define solutions to business needs. If those solutions fall within the IT domain (one of the perspectives described in BABOK), then we’re talking about an IT business analyst — someone whose job is to support the development of an IT solution in response to an organization’s needs.

That definition is still broad and open to interpretation, even with IT as the defined scope. But traditionally, the role of an IT BA is centered around requirements analysis — figuring out and shaping the requirements for a chosen solution. When I say “traditionally,” I mean this is the most common expectation — but you should still read job descriptions carefully. Even if the role is explicitly labeled “IT BA,” the actual focus may fall anywhere on the spectrum from high-level organizational analysis to hands-on writing of system requirements. And yes — that spectrum is wide.

Most often, the emphasis is indeed on requirements. But to get to those, you’ll often have to dig deep into the organization and its stakeholders. That’s why understanding what is and what isn’t a requirement (not always obvious, especially for junior analysts) can help in several ways:
1) You’ll gain clarity on what’s likely to be your main focus in most roles labeled “IT Business Analyst.” Let me clarify a couple of caveats:

  • That’s assuming this doesn’t directly contradict the expectations at your specific workplace. But the truth is, employers often don’t really know what to expect from a BA. Understanding where a BA’s responsibilities end and someone else’s begin requires mature and well-defined processes — and those aren’t always in place. Sometimes, you’ll be hired and told to “just do your magic,” and then it’s up to you to shape the process. That’s exactly where the ideas in this article might come in handy.
  • I’m not arguing that project roles must have rigidly defined boundaries. Collaboration between roles is great, and I’m all for the idea that you can (and should) agree on who does what. But those agreements should be situational — not the default way of working. You still need a starting point and a clear understanding of your own scope and responsibilities.

2) For recruiters and process designers: you’ll get a clearer picture — and perhaps gain more realistic expectations — of what an IT BA should be responsible for (and what they shouldn’t). Like any role, business analysis is a specialized discipline — a way of assigning certain types of work to someone whose skillset fits that domain, freeing others to focus on their own areas of expertise. So if your BA ends up designing databases (which is something your developers, DBAs, or solution architects are trained for), you have to ask: why are you assigning that responsibility to someone whose core competencies lie elsewhere?

So far, we’ve established a few things:
a) Business analysts suffer from inconsistent expectations across different regions and employers.
b) In most cases, the core responsibility of an IT BA is working with requirements for IT solutions.
c) Understanding what constitutes a “requirement” — and what doesn’t — helps analysts, recruiters, and managers determine which tasks belong to the BA and which should be handled by someone else.
Let’s begin with a simple question: What is a requirement? We’ll take a look at several definitions and try to unpack them.

BABOK v3 (IIBA):

A usable representation of a need

In other words, someone (or something) has a need, and a requirement is how that need is expressed in a way that can actually be used. A bit vague — but it’ll do for a starting point.

CPRE Glossary of Requirements Engineering Terminology (International Requirements Engineering Board) v. 1.0.0:

  • A need perceived by a stakeholder
  • A capability or property that a system shall have
  • A documented representation of a need, capability, or property

Let’s also throw in a very similar set of definitions from the IEEE:

IEEE Standard Glossary of Software Engineering Terminology (Institute of Electrical and Electronics Engineers):

  • A condition or capability needed by a user to solve a problem or achieve an objective
  • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, or specification
  • A documented representation of a condition or capability as in 1 or 2

Now, let’s highlight a few meaningful differences. The IEEE uses “user,” while IREB prefers “stakeholder” — which is better, since not all stakeholders are end-users. That makes the definition broader and more inclusive. The first two points from both sources provide a solid foundation for understanding what a requirement is. To fine-tune this further, let’s consult Karl Wiegers — not a formal standard, but widely respected in the field:

Karl Wiegers & Joy Beatty, Software Requirements, 3rd Edition:

A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.

This aligns well with the previous definitions, so let’s explore all of them together.

As you probably know, there are different types of requirements. I won’t go into the full taxonomy, but here’s a simplified structure based on BABOK, Mr. Wiegers, and some of my own tweaks — focused specifically on software/IT solutions:
From the first group of definitions — “a need perceived by a stakeholder” — we’re clearly talking about business needs. Personally, I recommend making a distinction between “needs” and “requirements”, but even if you treat requirements as expressions of stakeholder needs, it’s a good starting point.

This aligns with business requirements — what the organization (or its representative, usually the sponsor) wants to achieve with the upcoming change. For example:
“Reduce document handling costs by 20% within a month.”

That also leads us directly into the next layer — stakeholder requirements: what stakeholders need in order to reach those business goals. For instance:
Mary, the secretary, needs to be able to create documents in electronic format, and the document creation process needs to be fast.

The second group of definitions points to another kind of requirement — the third layer in the hierarchy:
A capability or property that a system shall have.

This is where we’re already talking about a solution — meaning we’ve gone through the process of analyzing possible options (in our case, IT-based, since we’re talking about IT BAs), selected the optimal one, and are now describing its functional expectations. So if the solution is a custom-built web system for document management, then we’re looking at solution requirements — what the system must be able to do, or how well it must behave.
What else useful about requirements can we draw from BABOK?

One concept I really like there is Business analysis information. The key point behind this term is that a BA doesn’t work with requirements alone, which is obvious. A BA deals with layers of information, and the part that’s valuable for their tasks is business analysis information — the information that supports business analysis on the project.

Business analysis information refers to the broad and diverse sets of data that business analysts analyze, transform, and report.
Examples include elicitation results, requirements, designs, solution options, solution scope, and change strategy.

Here’s what to take away:

a) Besides requirements, a BA handles a sea of other information (for example, describing the AS IS state — current process descriptions, domain actors, or current system flaws “requirements” doesn’t really fit; requirements are aimed at the TO BE state).

b) Requirements are part of this information.

c) Requirements are the most valuable subset of business analysis information since, as we described earlier, refining requirements is the BA’s main focus.

At the same time, considering that besides business analysis information there is other information in the project, all these “informations” can be roughly illustrated like this:
Key points from the picture:

a) The concepts of Business analysis information and Requirements, plus how they relate.
b) The fact that there is other “information”:
  • Project information — this is the domain of the project manager or whoever actually fulfills that role. The BA’s focus is on the target solution, not the project of developing it. The BA is responsible for a clear understanding of what the target solution should be in terms of its functional and non-functional content. The project manager handles the activities of implementing that solution — timelines, budgets, team, resources, processes, etc.
  • Designs — the “engineering” aspects of the solution. How the development of the solution per the BA’s requirements will proceed. This includes development decisions like technology stack, architecture, coding standards, database structure, and so on. Basically, the technical details of how the solution will be realized.
  • Other stuff — for example, testers also obviously have their own information base and decision area.

c) The relationship between Requirements and related information (project and technical). As you can see, the boundaries aren’t clear — these areas overlap. This is the difficulty in separating requirements from non-requirements, with all the consequences discussed at the start of this article. We’ll try to unpack this further.
Let’s begin by imagining an ideal, crystal-clear project process, where all typical project roles exist, each with clearly defined boundaries of work and responsibility, and those don’t overlap. This isn’t about efficiency — development trends toward tighter collaboration and teamwork, which is great. Still, as I mentioned at the start, such clarity is needed at the beginning — after that, mature professionals will figure out how and where to collaborate or even substitute for each other.

In this perfectly spherical vacuum process:

  • The BA = requirements and the path leading to their elaboration.
  • The project manager = overall control of everyone on the project to develop the solution based on BA requirements.
  • Developers and their variations (architect, front-end, back-end, DBA, build engineers, etc.) = designs (technical solution aspects).
  • Testers = quality control of the solution.

If we take the picture above as a base, everything looks neat. But there are two problems:

1) Not all employers believe this is the “correct” role division. For example, in setups where there are business and system analysts (popular in Russia and some neighboring regions), the business analyst covers part of the IT BA work described earlier — roughly everything up to the solution requirements (the first two levels). The system analyst handles solution requirements and, interestingly, part of the designs — partially doing developer work, usually architectural issues. It seems system analysts struggle to separate themselves from developers without “on-the-fly” agreements.

2) Not everyone knows or can clearly tell whether something is a requirement, project info, or a design. This often causes questions like “Why am I responsible for this if it’s someone else’s job?” or “Why did you do my work and think for me?”

If we base ourselves on the idea that the BA is responsible for requirements and it is their default boundary, then we need to precisely understand where requirements start and end. It’s easy to see they ideally start at business requirements level, but where to stop to avoid slipping into project or technical details (designs)? The tricky part is that the definition “A capability or property that a system shall have” doesn’t give a black-and-white answer. For example, isn't the database structure a system property and therefore a requirement? Is a piece of code a system property?

Here, I suggest adding to the definition the well-known classification of requirements and understanding that solution requirements (which fit that definition) can be functional and non-functional, plus transition requirements by their side. Knowing these types and what they include makes it easier to see where to stop to avoid non-requirements. Functional requirements describe system functions and behavior within those. Non-functional requirements characterize functional requirements, mainly as quality attributes (reliability, security, performance, usability, etc.). In other words, solution requirements are mostly useful characteristics from the stakeholders’ perspective, describing behavior, information, and qualities in a working, value-delivering solution. Database structure is not a useful/valuable characteristic for stakeholders — it’s a building block seen only by development-side stakeholders during development. That’s the boundary between the BA’s focus and the developers’.

Separating requirements from project information is generally easy: requirements characterize the target solution, project information characterizes the project to develop it. Examples with comments:
Example
Comments
Choice of process methodology and setting roles
Project issues (not a BA job unless roles are combined or unclear)
Solution scope (features or epics/stories in backlog)
Requirements (BA is responsible for these)
Composition and format of internal project meetings
Project issues
Business reasons for developing the solution
Requirements (business requirements)
Developer John keeps making bugs
Project issues
Timelines, budget, roadmap
At first glance, project issues, but with nuances (overlaps per the diagram above). Timelines and budgets relate directly to the project but influence business requirements and the timing/effectiveness of the solution. Roadmap and iteration plans link to scope priorities, so discussing these separately with the client may be suboptimal. Coordination is needed here.
Stakeholders and communication specifics
Clearly not requirements; who owns this? Unclear because solution and project stakeholders overlap. Usually a shared concern of PM and BA. Collaborative effort advised.
Separating requirements from technical details (designs) can be harder, but let’s explore. Beyond the “useful solution aspects VS development aspects” or “what VS how” concept, another useful question is: Is there a project role more competent and focused on this domain? If yes, probably these are implementation details and the role is the implementer. If not, cooperation is needed.

Examples with comments:
Example
Comments
System behavior algorithm when pressing a UI button (without mentioning architecture or tech details)
Requirements — this is directly what the solution must include to deliver stakeholder value.
Interaction between architecture components (e.g., “service A sends data B to service C and gets data D”)
Technical details not relevant to BA. How it works under the hood is developer work.
Logical data structure for the solution
Requirements, if “logical.” This means the information system operates on during its behavior. BA doesn’t care where it’s stored (DB, text file, cache).
Physical data structure of the solution
Technical details irrelevant to BA. Deciding DB type/organization is developer territory. Often considered technical constraints, which BA should record and hand over.
System UI
A debated area. Could be requirements or implementation details. Often falls on the BA because: a) BAs use UI mockups to discuss requirements with stakeholders, b) many teams lack a dedicated UI specialist. So the BA often takes it on or is forced to.
Quality attributes
Obviously requirements, but depends on level of detail. For example, “System must use HTTPS” — is this a pure requirement? Probably not, because the real value is preventing data leaks during transmission. Should the BA decide on the final solution here, or rely on development specialists? The “how” is creeping in, so caution is needed. It’s fine if such requirements exist in specs, but the BA shouldn’t decide alone if a competent dev team is present.
That’s the picture overall. I welcome comments (for example, in my channel — https://t.me/itmineba), since I understand that role specifics can differ.
]]> Impact Map and User Story Map: How to Tackle the Scope Fast and Hard (Part 1) https://itmine.by/enarticles/tpost/m77p1kae81-impact-map-and-user-story-map-how-to-tac https://itmine.by/enarticles/tpost/m77p1kae81-impact-map-and-user-story-map-how-to-tac?amp=true Fri, 20 Jun 2025 13:38:00 +0300 Business analysis A powerful combo of two proven Agile techniques for defining a solution's scope. Part one dives into Impact Mapping with a practical example and tips on how to use it effectively.

Impact Map and User Story Map: How to Tackle the Scope Fast and Hard (Part 1)

Let’s talk about two awesome techniques for scoping solutions — Impact Mapping and User Story Mapping. We’ll look at how they can be used together, though in practice, they’re often applied independently depending on the task at hand.

Both Impact Mapping and User Story Mapping are typically presented as agile techniques. Like most agile tools, they have a distinct trait: they help you achieve something in a fast and lean way — essentially following the Pareto principle (20/80). That means focusing on quickly delivering the core result, while ignoring bells and whistles. So keep in mind that these techniques are a) simple, b) relatively shallow, and c) fast to apply. In other words, I wouldn’t recommend using them to plan a nuclear reactor, but they’re perfect for designing an MVP for a startup.
Let’s start with Impact Mapping — a technique for visually planning how to achieve a specific goal. In a business analysis context, it helps you work with stakeholders to explore how a solution can address defined business goals.

We’ll walk through the technique using a project example from Karl Wiegers’ book Software Requirements (3rd Edition), since many people are familiar with the scenario, along with its V&S and SRS content.
Project context (only the relevant part):

Most Process Impact employees currently spend around 65 minutes a day choosing, paying for, and eating lunch in the cafeteria. About 20 minutes of that is walking to and from the cafeteria, choosing food, and paying by cash or card. In total, employees are away from their desks for about 90 minutes. Some try calling ahead to place their orders, but often end up with the wrong meal because certain dishes run out.

The book doesn’t make it very clear who the actual beneficiary of the solution is — for some reason, we seem to be solving problems for both the cafeteria and the company whose employees use it. So let’s simplify the original three business goals from the book down to one that’s most relevant to Process Impact:

BO-3: Increase the average productive working time of each employee by 15 minutes per day, within 6 months of the system’s initial release.

Let’s not get into how this specific metric was decided — after all, Impact Mapping isn’t about defining business goals. You go into it already having your goals — whether they’re SMART or more abstract doesn’t matter, as long as they’ve been agreed with stakeholders. And just as importantly, this isn’t a method for selecting the final solution. Somehow (by magic, perhaps), we’ve arrived at the following idea:

Cafeteria Ordering System — a web application (originally also mentioned as a mobile app, but let’s stick with web for simplicity) that allows employees to place lunch orders, pay for them, and initiate delivery to a specified point within the Process Impact office.

That’s roughly the starting point for our Impact Map. An Impact Map is a type of mind map, built using a specific template. Like most agile techniques, it’s not something you sit down and create in isolation. It works best as a collaborative process with relevant stakeholders — the client, key business figures, user reps, you, your UXer, lead dev, and so on. We’ll briefly touch on what that process might look like later.

The map has four levels. Each should be worked through in sequence — don’t move on until the current level is solid.
Level 1: Goals

These are the business goals you're trying to achieve.
Level 2: Actors

Actors are people or groups who can help or hinder the achievement of the goal.
Some guiding questions:
  • Who directly affects whether the goal is met?
  • Who indirectly affects the goal and is involved in relevant processes?
  • Who might, under some conditions, help or block achievement of the goal?
Given our context, here are the key actors:
  • Employees (they’re the ones we’re trying to “upgrade”)
  • Cafeteria management (they’ll be delivering food in the new setup)
  • Process Impact leadership (optional — they're funding this, but we’re already focusing on their goal)
  • Cafeteria delivery staff
  • Cafeteria cooks
Actors we’re skipping for simplicity but could explore:
  • Hosting
  • Government regulators (if there are compliance requirements)
  • Finance/accounting team (handling food expense records)
  • Payment provider
At this point, you’ve probably noticed this is a light version of stakeholder identification. It’s not a complete overlap with stakeholder analysis, so there might be gaps — but remember, agile techniques prioritize speed and simplicity over completeness.
Level 3: Impacts

This is about how we want the actors to change their behavior in order to help meet the goal. Think:

  • What should the actor start doing?
  • What should they stop doing?
  • What should they do differently (more, less, faster, slower)?

Let’s sketch out some ideas, keeping in mind that our goal is to increase the effective working time of employees by automating food ordering and removing the need to walk to the cafeteria.

Employees:
  • Stop physically walking to the cafeteria
  • Start placing orders via the web app from the office

Cafeteria management:
  • Set up new roles and responsibilities (e.g., delivery staff, support)
  • Organize efficient order processing workflows

Process Impact leadership:
  • Nothing specific — just fund the whole thing (already happening)

Delivery staff:
  • Deliver food quickly to the office

Cooks:
  • Prepare meals promptly based on orders

It’s worth noting: we might have a few gaps here, but that’s expected — this example was drafted solo. If we had the client, a cafeteria rep, a hungry employee, and our internal team (like a lead UX designer and a tech lead) all in the same room, the results would be a lot more complete and reliable.
Level 4: Deliverables

This final level of the Impact Map outlines solutions in response to each impact — in other words, what we can or must deliver to ensure the desired behavioral changes happen. These solutions will mostly fall within the scope of the target IT product (i.e. its functional capabilities), but not exclusively. We might also identify important non-functional requirements or supporting elements outside the product itself — things that need to happen around the product for change to truly occur. In terms of requirements, these would be classified as transitional requirements or external dependencies; in simpler terms: a product alone doesn’t drive change.
Employees

Stop physically walking to the cafeteria
We’ll cover this in the next point.

Start placing orders via the web app from the office
  • Login with a personal account (so orders are linked to individual users) + logout.
  • We may also add password recovery, changing password, session timeout, etc.
  • View menu.
  • Someone from the cafeteria will need to upload the menu to the system — so we should also include menu management: add/edit/delete menu items.
  • Place/edit/cancel orders.
  • Pay for orders (e.g. by card).

Cafeteria management

Set up new roles and responsibilities, if delivery services aren't already in place (e.g. new responsibilities for cooks, delivery staff, support team)
  • We don’t need to implement this ourselves — but we do need to ensure the cafeteria sets it up and that it works. Most likely, the client (the one requesting the solution) will be responsible for this, but it’s still worth covering this point during discussions with all key stakeholders.

Organize efficient order processing workflows
  • Same as above. We might help by training cafeteria staff on how to use the system.

Delivery Staff

Deliver food quickly to the office
  • If no delivery process exists yet at the cafeteria, one will need to be introduced. Again, probably outside our core responsibility — but worth flagging and discussing, since we’re all working toward the same goal.

Cooks

Prepare meals promptly based on orders
  • Ability to view placed orders.

Additional deliverables for previously identified actors
These aren’t tied to a specific impact, we skipped this part.
  • Hosting setup (External hosting).
  • Analysis and compliance with national regulations regarding web apps and food delivery services; Data privacy policy; Registering the service for online commerce; Any other relevant regulations the cafeteria must follow to legally offer delivery (Government regulators):
  • Export of individual order expenses (Finance/accounting team).
  • Integration with a payment provider (Payment provider).
So, what have we done? We’ve essentially generated a solution scope — along with supporting context — by progressively working on how to achieve the business goal. Everything we’ve identified here are candidates for epics, user stories, features, non-functional requirements, external dependencies, project tasks, etc. Of course, from a requirements perspective, this all still needs refining:
  • Some items will go into the scope of the IT solution (functional and non-functional bits).
  • Others are complementary actions that will need to be taken outside the system (by the client, third parties, or other stakeholders).
Together, this forms a plan that guides the client toward achieving their original business goal. Yes, it’s rough and high-level — but that’s exactly what you want at this discovery stage.
How to facilitate an Impact Map workshop:
There are many ways to run this process — whatever facilitation tools and collaboration formats you like. But here’s a typical example:
  1. Input: You already have the business goal defined and a general understanding of what the target solution should look like (e.g. from a prior session using Lean Canvas or something similar).
  2. Organize a workshop with relevant and available stakeholders — either in person or remote. For example: the client, a cafeteria representative, a hungry employee, you, and your internal team (UX specialist, tech lead, project manager, QA lead, etc.).
  3. Before and during the session, as with any workshop, make sure everyone understands the goal, expected outcomes, and is ready to contribute actively. Communicate this in the agenda and reiterate it at the beginning.
  4. Introduce key terms: explain what an Impact Map is, how you’ll move through the levels, and what’s expected from each participant:
  • You’ll work through one level at a time.
  • For each level, explain what it means and suggest prompts to help generate ideas.
  • Participants add sticky notes (or mind map branches in Miro) during a 5-minute brainstorming round.
  • Then, you review each one together: the author explains, others comment, you clean up duplicates and prioritize.
How does the User Story Map fit in? The User Story Map comes into play once the Impact Map is ready. It takes the part of the plan related to the IT solution and helps shape a well-structured, prioritized product backlog. In other words, it transforms the rough ideas into a clear breakdown of epics and user stories. But more on that in the next article.
Visual example of the map discussed in this article:
]]> Impact Map and User Story Map: How to Tackle the Scope Fast and Hard (Part 2) https://itmine.by/enarticles/tpost/9xji97zj91-impact-map-and-user-story-map-how-to-tac https://itmine.by/enarticles/tpost/9xji97zj91-impact-map-and-user-story-map-how-to-tac?amp=true Fri, 20 Jun 2025 17:48:00 +0300 Business analysis Part two of a two-part article on Agile techniques for shaping solution scope. This part focuses on the User Story Map.

Impact Map and User Story Map: How to Tackle the Scope Fast and Hard (Part 2)

In the previous article, we explored Impact Mapping — a quick, effective technique to draft the scope for a solution and the surrounding context based on initial business goals. Today, we’ll look at the User Story Map as a tool for deeper exploration and visualization of that scope — whether as a follow-up to the Impact Map or as a standalone, battle-ready technique for building the scope from scratch.
So what is a User Story Map? The name says it all: a map of user stories. In other words, it’s a visual model that organizes user stories — basic scope units in agile development — in a specific structure. A User Story Map lays stories out across two dimensions:
  • Horizontally by their place in the user’s journey through the system
  • Vertically by their priority or value to the user
How do we build this kind of map?
1) Identify and structure your users. First, we need to define who our users are and categorize them. In enterprise systems, the most common way to categorize users is by roles. Quick disclaimer: this method isn’t limited to enterprise solutions — roles can be used in many different IT systems. In some cases, these roles manifest through permissions or other authorization mechanisms. But for simplicity’s sake, let’s stick to “roles” as our unit for separating user types here. Roles are defined by the tasks users need to perform in the system.

In consumer-facing products, roles are often not distinguishable. Take the Windows Calculator — every user interacts with it the same way. In such cases, we can rely on personas instead — a UX technique for segmenting the target audience based on human attributes (age, gender, lifestyle, etc.), depending on which attributes drive different usage scenarios. Personas and roles aren’t mutually exclusive. You can use both, but in practice, personas are typically used when access-based roles are irrelevant.

Referring back to the example from the previous article: if we review the actors (second level of the Impact Map) and whether they will interact with the system (fourth level), the following roles emerge:
  • Employee
  • Cook
  • Accountant (we’ll simplify the expense tracking department into this role)

With a bit of analysis, we can also assume that someone will need to administer the system (e.g., manage accounts for the above roles), so we add:
  • Administrator

2) The top level of the User Story Map: User Goals (a.k.a. User Activities).

For each role identified in step 1, we need to articulate their high-level goals within the system and arrange them left to right in the logical order of usage.

Let’s outline them and lay them out visually, using the draft scope we developed through Impact Mapping (and filling in some gaps along the way). I used Miro and its ready-made User Story Map template, which is easy to find online — but there are plenty of alternatives.
3) Define the user journeys. Next, for each goal, break it down into a sequence of key steps that the user needs (or is likely) to take to achieve it. These become the second level of the map — again, arranged left to right, following the logical sequence.
Don’t worry too much about perfect granularity at this point. You’ll refine things later.

4) Break each step into user stories. Now, we describe what exactly the user needs to do in the system to complete each step. This is the third level of the map, where we break steps down into smaller, actionable user stories. You can apply best practices here (like INVEST) and your own decomposition strategies. We won’t go into detail on that here. Once you’ve listed out user stories for a step, order them vertically by priority — most valuable to the user at the top, less valuable lower down.
5) Time to clean up the map. Now let’s refine it into something that feeds directly into the product backlog. That means clearly defined Epics, User stories and their prioritization.

Do the following:
  • Remove duplicates and regroup where necessary for easier backlog formation
  • Rename for clarity: make titles unambiguous, clear, and ideally unique
  • Adjust the story breakdown if helpful — epics are just structural containers; don’t force hierarchy where it’s not adding value
  • Ensure your stories follow INVEST and have practical qualities like independence, value, and manageable size (you’ll still refine them during future planning activities, so this is just a solid starting point)
6) Mark MVP or release slices. Finally, you can sketch out your release plan directly on the map — or at the very least, highlight the MVP (Minimum Viable Product).

Here’s what our finished map looks like (the divider separates the MVP from backlog items planned for later):
A few additional thoughts:

  1. You can create one big map or separate maps for each user category.
  2. As with the Impact Map, I built the example solo — but let me repeat the golden rule from the previous article: agile techniques work best when you run them collaboratively with your key stakeholders. When the client, knowledgeable users, and your team (UX, dev leads, PMs) all contribute to shaping the map, you drastically increase your chances of covering real user needs and prioritizing correctly.
  3. You can build each part of the map with varying levels of depth. “Thinking” individually or as a team during a workshop is a good lightweight start. But if you want to go deeper, nothing stops you from investing more time: personas can be developed with some real empathy work, user goals and stories can come from actual research — surveys, interviews, etc. The more care your team puts into gathering accurate input, the more reliable your scope will be.

To wrap things up — how to quickly and effectively shape your solution scope using both techniques:
  1. Run an Impact Mapping workshop with the client, user reps (if available), and key team members. Ideally, come in with a clear understanding of the project goals, but if not — use the workshop to define them. Impact Mapping helps turn goals into a draft solution scope and identify any organizational/process-side changes stakeholders will need to make to support it.
  2. Follow up with a User Story Mapping workshop using the same group — this time, focused specifically on fleshing out the IT solution scope (most likely your team’s main area of responsibility). The User Story Map gives you a structured backlog of epics and user stories, their initial prioritization and a clear idea of where to start with the first release.
]]> Strategy Analysis, Discovery, and Vision and Scope — Demystified https://itmine.by/enarticles/tpost/96tbtk7301-strategy-analysis-discovery-and-vision-a https://itmine.by/enarticles/tpost/96tbtk7301-strategy-analysis-discovery-and-vision-a?amp=true Fri, 20 Jun 2025 18:42:00 +0300 Business analysis A breakdown of simple examples to help understand where and why business analysis begins.

Strategy Analysis, Discovery, and Vision and Scope — Demystified

Let me clarify right away: this article will intentionally gloss over some of the nuance and precision that a hardcore purist might expect. Yes, I know that BABOK refers to knowledge areas, not activity domains. I understand that the origins of certain terms may differ if you dig through them with the zeal of a historian-archeologist. And sure, some concepts might shift meaning when viewed under the light of a waxing moon on the third Friday of the month. With those caveats out of the way — let’s dive in.

Strategy analysis is a domain of activities focused on identifying the needs of the organization or client and developing a high-level action plan. In other words, before diving into details and bombarding the development team with tomes of specs, the analyst and the client need to understand what big-picture problem they’re trying to solve, what the target solution is, and what its broad components are.
In our training materials, we usually represent the conceptual flow like this:
The fifth point, by the way, can sometimes logically slide between the second and third. Often, to understand the range of potential solutions, you first need to grasp what the content of any of those solutions would likely include.

In practice, people frequently skip one or more of these steps. In some settings, IT analysts don’t even try to uncover the actual reasons behind the client’s request. Elsewhere, teams bypass the solution exploration step entirely and simply take the client's original request at face value. If that’s the working context — and it’s not happening out of ignorance or laziness — then that’s fine. But if an analyst is running the full cycle of this activity, the strategy analysis should yield three key outputs:

  • Business Requirements (1): Clear goals that serve as direct indicators of whether the client’s or organization’s business needs are being met.
  • Solution Vision (2): After evaluating solution options and choosing the most appropriate one, we need to articulate what our target solution is, who it’s intended for, and which of their needs it addresses.
  • Solution Scope (3): A high-level overview of what the solution will consist of — essential to understanding the scale of the challenge ahead.

Let’s talk about a trendy term that’s often thrown around these days: discovery. It originally came from either product development or Agile practices — hard to say which exactly — but it’s now commonly used even in client-driven software development. In terms of purpose and content, it’s essentially the same thing as strategy analysis: defining the vision for the solution, its users, goals, and scope. Within this framing, teams often talk about two project phases: discovery and delivery. First, figure out what you're building — then go and build it.
Strategy analysis or Discovery in action. Let’s walk through an example:

1) A client approaches us to purchase ITMINE’s business analysis course — this is the solution they believe they need.

2) If I’m playing the role of the analyst (which I try to do in such cases), my task is to understand — or help the client uncover — the need behind this solution. Through discussion, we might arrive at something like “I see an opportunity to switch to a more lucrative profession.”

3) What we don’t usually do in a course sales context — but what you should definitely do when working on a real project — is translate that need into a formal business requirement (1). For example, we might define the goal as: “Secure a job as an IT business analyst within six months, earning no less than $1000/month.”

4) Together with the client, we then evaluate whether the original solution is actually the best fit. We try not to anchor ourselves to it without considering alternatives. Here’s a possible set of options (which I help the client brainstorm using either domain expertise or, when that’s lacking, some logical reasoning and lightweight research):
  • Self-study
  • Working with a personal mentor
  • Taking a course
Each option will have its pros and cons, cost, and other relevant parameters. We analyze and discuss them, then settle on a direction. Let’s say the final choice is a BA course from ITMINE (good call!)

5) Next, we articulate a solution vision (2) that all parties can clearly understand: “The solution is a group-based online course from ITMINE that will equip the client with the knowledge and skills necessary to secure employment as an IT business analyst.”
Of course, we could expand this vision with more informative components, but we’ll stop here for brevity.

6) Solution scope (3): Since the BA course from ITMINE is already a packaged, off-the-shelf solution, there’s no need for custom development or post-sale customization. So in this particular case, defining scope isn’t necessary. Still, for completeness, here’s a high-level breakdown of what the course includes:
  • Live training sessions
  • Slidecasts covering theory
  • Quizzes
  • Supplementary reading
  • Home practice
  • A final mock interview

And that’s the whole discovery phase. Now both the client and we have a clear understanding of why, what, and how much we’re doing. Of course, for IT projects, the process is more complex and requires eliciting each piece of information through more robust techniques — but again, the goal here is to grasp the core concepts, not conduct a full-blown analysis.
Let’s now take a look at Vision and Scope, a key artifact that encapsulates the outputs of strategy analysis. By “artifact,” I don’t necessarily mean a formal document, so no need for Agile purists to tense up — it’s simply a collection of information, which can be captured in a doc, a note-taking tool, or any other format that works for your team.

As you’ve probably gathered, Vision and Scope includes all of the key components discussed above — but not just those. There are a number of additional sections that help clarify and enrich the information. I recommend the following structure, which is based on a popular template originally proposed by Karl Wiegers:
1. Business Requirements

1.1. Background and Business Needs
1.2. Business Goals and Success Metrics

2. Solution Vision

2.1. Solution Options
2.2. Vision Statement
2.3. Business Risks
2.4. Business Assumptions and Dependencies

3. Solution Scope and Limitations

3.1. Major Features and Characteristics
3.2. Scope of Initial Release
3.3. Scope of Subsequent Releases
3.4. Limitations and Exclusions

4. Business Context

4.1. Stakeholder Profiles
4.2. Deployment Considerations
We’ll briefly discuss each section next, which will also help deepen your understanding of strategy analysis and the kind of information that’s most useful at this stage.
1. Business Requirements — the section whose ultimate goal is to formulate business requirements — the first key piece of information that matters at the end of strategy analysis. Here, we answer the question: “Why?”

1.1. Background and Business Needs
In this part, we describe the organization’s business needs and the context that gave rise to them — what’s going wrong, where the roots of the problem or opportunity lie, how key related processes function. Our goal by the end of this step is to clearly articulate the problems or opportunities the organization or client is facing.

1.2. Business Goals and Success Metrics
Here, we formulate business requirements based on the identified needs. Typically, these are expressed in the form of business goals. It’s important to understand that we’re not talking about the organization's global business objectives, but rather the goals connected to the change (as defined in BABOK) that the solution is meant to support.
What are Success Metrics? Very often, there’s a gulf between the business goals and the solution intended to achieve them:
In other words, we can't always create a simple cause-and-effect chain like: “If we implement the solution, the goal will be achieved.” There are plenty of other factors influencing whether or not the goal is reached. For example, as a course creator, I can't guarantee that completing an ITMINE course = landing an IT BA job within six months with a salary of at least $1000. We’ll talk more about these factors later. For now, it’s helpful to define success criteria for the solution — indicators that, over time, can show whether the solution is helping the organization progress toward its business goals. How do we, as solution providers, know that we’ve done everything right within our zone of responsibility? One example of a success metric I might use: “Complete the course with a final score of at least 70%.” For me, that’s a sign that the solution is contributing effectively toward the business goal. If the metric isn’t met, the course might not actually help the user — in which case, we need to rethink either the solution itself or how it's being used.

Are success metrics mandatory? No — if there’s no significant gap between the goal and the solution (i.e., no major external context or risk factors that could interfere), then you don’t need to force metrics for the sake of it.
2. Solution Vision — what solution options exist, and which one we’re choosing. Here, we answer: “What?”

2.1. Solution Options
If relevant to the project, this is where we describe and compare the solution options that were discussed.

2.2. Vision Statement
Here, we define the vision for the selected solution.

2.3. Business Risks
Business risks are one of those “question marks” shown earlier in the article, and it’s worth thinking them through together with the client. These are the things that might go wrong even if we have a fully developed and functional solution — in other words, risks on the organization’s side. As we said, implementing a solution is rarely the only factor that determines success. So, what else could affect the outcome, and how?
What does the client gain from this step?
  • A clear understanding that the solution alone won’t cut it.
  • Identification of other factors that could impact goal achievement.
  • Evaluation of the significance of those factors (likelihood + impact).
  • Recommendations for how to mitigate those risks — ideally discussed together, since we as analysts might not be domain experts, but we can flag the importance of this step and help guide the discussion.

2.4. Business Assumptions and Dependencies
This section closely relates to business risks, since it's also about external “question marks”.

Let’s start with dependencies:
What external factors does our solution depend on in order to contribute to the business goals?
Risks and dependencies often get lumped together — and that's fine. But here’s a practical distinction to help keep things clear:
  • Business risks: Potential negative factors on the client side. What could still go wrong in reaching the goal, even if the solution is implemented correctly? Example: There’s a business analysis course — but beyond the course, what might still prevent the learner from landing a job?
  • Dependencies: Factors the solution itself depends on to work successfully. What must be in place for the solution to contribute effectively to the goal? Ideally, we’d eliminate all risks and dependencies. Realistically, we can only minimize them.
Now, what are business assumptions? These are assumptions we base other conclusions on during the strategy analysis phase — things we believe to be true but haven’t confirmed as facts.
Why might we need assumptions? Examples:
  • Lack of communication (e.g., a key stakeholder has left the company).
  • Inability to turn a hypothesis into a verifiable fact (e.g., assuming 15,000 people will install an app).
  • Lack of time or willingness to dig deeper (e.g., conducting market research is costly and time-consuming, so we hypothesize that users want our product).
Assumptions are situational. They’re not like risks or dependencies, which objectively exist. You may or may not have assumptions — it depends on how much info you’ve confirmed as fact. We write them down so we can revisit them later. Over time, they may either be confirmed (and thus removed) or disproven (in which case we’ll need to adjust the goal, solution, or scope).
  • “We assume the business goal is valid, assuming that…”
  • “We believe the solution is optimal, based on the assumption that…”
  • “This scope element is deemed necessary, assuming that…”

If I were in a 30-minute conversation with a potential client about a future solution, I don't have time to clarify every detail, so I accompany my Vision and Scope document with a clearly highlighted list of assumptions. Why?
  • So the client definitely notices and understands these assumptions.
  • So I can refer back to them regularly, checking whether new facts have confirmed or disproved them.
So, what unites business risks, dependencies, and assumptions? All three are essentially question marks that could negatively impact solution's ability to meet the business requirements. Also, all three are outside our control. In other words, this is where our jurisdiction ends. Here's the general principle:

We’re responsible for the quality of the solution and the units of scope we commit to. But let’s also work together — and we’ll help facilitate this — to think through:
  • What business risks exist on the client’s side? If one of them materializes, will it prevent us from reaching the goal?
  • What external dependencies affect the solution? If a dependency breaks, it will likely break something in the solution too. Let’s make sure we understand how to mitigate that (if possible).
  • What assumptions have we made during strategy analysis? These assumptions underpin our goal, success criteria, solution, scope, and more. Let’s either validate them and turn them into facts (gain confidence), or be aware that if any of them prove false, everything built on them may crumble.

This way, we cover our bases and offer the client a more thoughtful analysis — not just the classic "we're just the devs, we only write the code" routine.

A side note: sometimes it's genuinely hard to tell whether something is a risk, a dependency, or an assumption. It all depends on how you phrase it and which angle you approach the information from. But at the very least, the logic above gives you a useful checklist. And if you feel like you're drifting into philosophical debates while trying to classify something — stop. Just write it down somewhere.
3. Solution Scope and Limitations — what's in the box? This section defines the content of the solution.

3.1. Major Features and Characteristics
This is the scope of the solution itself.

3.2–3.3. Scope of Initial Release / Scope of Subsequent Releases
This applies when the solution will be delivered iteratively. If there's already some clarity on how that might happen, it goes here. Not relevant for a solution like “Business Analysis Course by ITMINE,” since it's a packaged product delivered all at once in a fixed and complete form.

3.4. Limitations and Exclusions
Clarifications that help narrow the interpretation of the scope. These reduce the risk of the client misunderstanding or assuming something we never promised.
Examples:
  • ITMINE does not guarantee job placement. We’re happy to help if we can, but there are no promises.
  • During self-paced practice, the trainer reviews artifacts once. Additional reviews might happen, but that’s up to the trainer.
4. Business Context
Since we've now defined the three key pieces of information, this section provides additional context to help interpret the discovery outcomes.

4.1. Stakeholder Profiles
Stakeholder analysis during discovery is crucial. This is where we record its results:
  • Who the stakeholders are.
  • How to categorize them.
  • Their influence on business goals and the solution.
  • Considerations for working with them.

This analysis informs:
  • Who the target users are.
  • Who might impact the business goal, success criteria, or other key parameters (and thus be sources of business risks or dependencies).
  • What content the solution needs (based on stakeholder needs).

There's no need to elaborate much here — this isn’t a guide on how to conduct stakeholder analysis or write a Vision and Scope document. There are no complex concepts in this section.
4.2. Deployment Considerations

What else needs to happen to make the solution actually work in the target environment and bring that much-awaited business joy? Note: This is not about project tasks or deploying the solution into production. That’s a project manager’s headache, not the analyst’s. Instead, this section refers (or at least should be interpreted as referring) to so-called transition requirements — temporary needs that ensure the solution can be properly integrated and used.

Examples include:
  • Migrating current data into the new system.
  • Training users.
  • Creating admin accounts.
  • Setting up a Google Play page.

In the case of the course, here’s how I’d approach this. The ITMINE course has a fixed scope — detailed earlier and described in Section 3. There were project tasks related to developing the course — those are already done and don’t matter to me as an analyst. My focus is the solution itself. However, when a new group starts the course, you can’t just “drop” the course onto them. You have to:
  • Collect Google accounts to grant access to YouTube videos.
  • Enroll students in the LMS.
  • Send a welcome email with instructions, etc.
These are the transition requirements that we should document in this section — acknowledging that, as we refine the solution, more of these may surface or change in scope.
And that’s about it. I hope this helped shed light on what strategy analysis aka discovery really is and how an analyst documents it — making “Vision and Scope” seem far less mysterious or intimidating.
As always, I’d love to hear your feedback in the ITMINE channel (https://t.me/itmineba). And don’t neglect strategy analysis in your work — after all, it’s where business analysis begins conceptually.
]]> UML and the IT Analyst https://itmine.by/enarticles/tpost/9fvno0z8z1-uml-and-the-it-analyst https://itmine.by/enarticles/tpost/9fvno0z8z1-uml-and-the-it-analyst?amp=true Fri, 20 Jun 2025 19:40:00 +0300 Business analysis About diagrams in general and UML diagrams in particular. This is the first article in a series: popular modeling “languages,” UML as one of them, and why any of this matters at all.

UML and the IT Analyst

In this series (5–6 posts), we’ll talk about diagrams — and UML diagrams in particular. The goal is to keep it simple, engaging, and fluff-free.

We’ll start with a general overview: the popular modeling “languages,” where UML fits in, and why we even bother with this stuff. Then, we’ll dive into the UML diagrams that analysts tend to use, with a focus on how they apply specifically to us. For graduates of our business analysis course, much of this will be familiar. Still, I’ll try to sprinkle in new and interesting insights so there’s something valuable for everyone.
So, most analysts draw diagrams (“build models”). There are different modeling notations. A notation is a language — created at some point by someone, with rules like: “use a rectangle/diamond/elephant to represent this,” “elephants can only be connected with dashed arrows, which mean such-and-such,” or “don’t draw this kind of arrow, or you'll break the sacred laws.” Many analysts ignore formal notations and draw ad hoc — freestyling on the spot, adapting to the task at hand. That’s totally valid. But I’ll try to make a case for why it’s worth investing in at least the most common notations:

  • Notation increases the chances you’ll be understood — by your team, your stakeholders, other analysts. Sure, for that to work, you need a rare combo: recipients who know the notation and you drawing it properly. But those cases do happen.
  • Notation often saves you from reinventing the wheel. If smart people have already created, tested, and refined tools that do the job — why not use them? You can always adapt as needed. So, before freestyling, I suggest this: “First, I’ll check whether a suitable existing tool or format exists. If I find it unreadable or too limited, then I’ll customize.”
  • Notation builds your visual literacy. If you study even a few of the notations below, you’ll a) draw more confidently (knowing how and when different diagrams help), and b) model requirements more accurately — without overloading your audience, making fewer mistakes, and leaving fewer gaps. For example, you won’t end up doing things like this:
  • Understanding notation can earn you serious credibility. In a world of “lean” techniques, clients from more structured industries will respect your grasp of professional tools. Not to mention, many job listings reference these notations — and interviewers often love to test for this kind of knowledge.
The notations you’re most likely to encounter, along with my general advice (aside from situations where your specific job dictates otherwise):

  • UML (Unified Modeling Language) — the most widely used graphical modeling language for IT systems. Multiple diagram types for different use cases. Useful to know because of its popularity and broad applicability — which is why this series exists.
  • BPMN (Business Process Model and Notation) — a common choice for modeling business processes. Unlike UML, which focuses on IT systems, BPMN is about workflows within organizations. Worth learning if you’re working closely with business processes. It’s narrower in scope than UML — effectively offering just one type of diagram (technically four, but only one really matters). Yes, UML has diagrams you can use for process modeling, and you can use BPMN in place of some UML diagrams. But using the right tool for the job always looks more professional. And at a basic “let’s draw and discuss” level, it’s not that complicated.
  • IDEF (Integration DEFinition) — like UML, it’s a set of diagrams for various scenarios. But it's niche, outdated, and not something you need.

There are also more specialized diagram types or “not-quite-notations” for specific needs: Flowcharts, Crow’s Foot (for ERDs), DFDs (Data Flow Diagrams), etc. Among these, I’d single out DFDs, since there’s no real equivalent in popular notations — read a few articles and see if it resonates.
Now let’s get closer to the point: the most popular modeling language in the IT world — UML (Unified Modeling Language). Here’s what’s useful to know:

  • UML has been evolving (though that might be a generous word) since 1994–1995. The current version at the time of writing is 2.5.1.
  • It’s positioned as a graphical modeling language for object-oriented software systems. So a) the focus is on IT and software systems in particular, b) it’s meant for systems built using an object-oriented approach (if you’re not familiar with that, don’t worry — most modern development is object-oriented, and it won’t really affect your ability to use UML diagrams effectively).
  • Both UML and BPMN (mentioned together since they’re maintained by the same organization — Object Management Group) are described in large, complex, dry-as-dust specifications. The only time you really need to crack open those specs is if a) diagram correctness is critical in your workflow (e.g., your team feeds diagrams into tools that generate code or database structures), or b) you’re planning to teach this stuff professionally. Otherwise, use more human-friendly guides and tutorials (like this series, ahem), even if they may gloss over minor technicalities.
  • UML wasn’t made for analysts. It’s a tool for the whole dev team, with much of it geared toward developers. That means a) many diagrams are irrelevant to analysts (we don’t touch those aspects of development), and b) some diagrams may be hard to understand without dev knowledge. This means when you go looking for guidance, most online sources talk to you like you’re a full-stack developer with 15 years’ experience. That’s why this series looks at UML through an analyst’s lens (you can find plenty of dev-focused guides online if you need them).
To understand the full UML “toolbox,” let’s briefly list its diagrams. UML diagrams fall into two categories:
  • Structural — show static structures
  • Behavioral — show dynamic behavior over time
A few words about each one, so you know what they are and whether you need them (with some subjective judgment and generalization):
Class Diagram — Originally meant to depict software code and database structure. In reality, it can be used to represent the structure of pretty much anything. It’s genuinely useful for analysts, as it allows you to build multiple valuable models. A versatile workhorse diagram.

Object Diagram — Shows the structure of objects as instances of classes at a specific point in time. To really get it, you need a solid grasp of object-oriented programming. Or maybe not — because odds are, you won’t need this diagram anyway. You can skip it.

Package Diagram — Groups elements into packages and shows how those packages relate. For example, you might group related use cases into thematic clusters and give a high-level overview. That might sound exciting in theory — but in practice, it’s not. Not useful for analysts. Pass.

Component Diagram — Highlights major software components and how they’re connected. Outside of hardcore system analysis (which borders on development), this isn’t something you’ll use. Generally irrelevant. Leave it to developers.

Composite Structure Diagram — Displays the internal structure of classes. That’s all. No value for analysts. Skip.

Deployment Diagram — Shows the physical placement of components across servers, devices, or other software environments. Analysts might use it occasionally to help others visualize the setup — though strictly speaking, that’s not really our job. Still, if you like being helpful… Marginally useful, but only in special cases.

Profile Diagram — Visualizes profiles and stereotypes across your model set. Sounds like alien tech already, right? Easiest thing is to forget it exists. Nope. Don’t bother.


Use Case Diagram — Visualizes your set of use cases and adds connections between them and their actors. If you’re applying the use case technique, then this diagram is a must. Core tool. Use it.

Activity Diagram — The main behavioral diagram. It shows process essentials: steps, participants, branches. It’s very handy — and not just for software-related workflows. In fact, it’s a strong alternative to BPMN or flowcharts. Super useful. One of the key diagrams.

State Machine Diagram — Illustrates how an object’s state changes over its lifecycle. Quite cool and genuinely useful in a range of scenarios. Not always needed, but when you need it, it shines.

Now, onto a group of diagrams under the “Interaction Diagrams” subcategory — these focus on how objects interact.
Sequence Diagram — Shows more or less the same process logic as an Activity Diagram but with a strong focus on interactions between participants. Sometimes gives a useful new perspective. Generally useful. Keep it in your toolkit.

Communication Diagram — Displays how objects communicate overall, without the step-by-step detail you get from a sequence diagram. Low value. You can skip it.

Timing Diagram — Focuses on the timing of interactions between objects. Very niche. Don’t worry about it.

Interaction Overview Diagram — A hybrid of Activity and Sequence diagrams: process steps + participant messaging. Neat on paper, but… Sounds more exciting than it is. You won’t need it.
Now, a word on the building blocks of UML. Since UML is a language, it has an “alphabet” shared across all diagram types (with some symbols specific to certain diagrams).

  • Elements — The core building blocks of any diagram. For example, the UML diagram we looked at earlier that depicted the UML Diagrams' structure (already broke your brain, haven't I?) — that was a Class Diagram, and each item on it was a Class. You’ll soon learn why some of those classes were in italics.
  • Relationships — Connect elements to show how they relate. Also, we’ll later dig into why so many connections on the diagram above end in a hollow triangle — and why some merge and others don’t.
  • Stereotypes — Not mandatory knowledge, but knowing about them makes you sound very sharp. Stereotypes are a way to extend UML — letting you add your own custom elements and relationships. It’s not recommended, since UML’s whole point is shared understanding. When you start injecting your own semantics, you drift away from standard meaning. But if you must, this is how. A stereotype is a label in double angle brackets next to an element or relationship, giving it a custom meaning.
What’s next?

In the following articles, we’ll look at the UML diagrams actually useful to analysts (spoiler: they’re the yellow-highlighted ones in the diagram and text above). For each of those, I’ll break down:

  • When it’s convenient/useful to use the diagram
  • Key elements (both common ones and advanced stuff for power users)
  • Typical relationships (again, both frequent and rare)
  • How to build the diagram — with examples
  • Practical tips from experience
  • Common mistakes and how to avoid them
]]> UML: Use Case Diagram https://itmine.by/enarticles/tpost/406crafae1-uml-use-case-diagram https://itmine.by/enarticles/tpost/406crafae1-uml-use-case-diagram?amp=true Fri, 20 Jun 2025 20:03:00 +0300 Use Case Diagram: why it’s worth using, how to apply it, and mistakes to avoid.

UML: Use Case Diagram

Having gotten a feel for what UML is and the different types of diagrams it includes, let’s move on to the practical side. And from a business analyst’s perspective, the first thing that usually comes to mind is the Use Case Diagram.

Legend for this article:

  • Blue — things not dictated by UML, but borrowed as helpful practices from other theories or hands-on experience (for example, from classic use case theory).
  • Italic — examples.
When used as intended, a Use Case Diagram describes what can be done with the system, framed in terms of actors and the use cases (i.e., interactions) they perform.
When to Use It:

Nothing out of this world — its applicability stems straight from its description: use it when you, as an analyst, need to visually communicate scope in terms of use cases (valuable actions a user can take with the system):

  • To align on scope with the client or end users
  • To convey scope to the development team
  • To organize and make sense of scope for yourself or fellow analysts

Even if use case modeling itself doesn’t feel like your thing, looking at the system from the user’s perspective is always valuable. User stories alone don’t quite cut it — not every story answers the question “What meaningful thing can I do with the system?” Often they’re smaller in scale, sometimes describing edge cases or one-off paths within a broader use case.
Elements:

Actor — these are the participants in your use cases. Represented by stick figures. An actor is a person, organization, role, or even non-human entity (like software or hardware) that interacts with the system and derives value from the use case. In most cases, this means they perform the use case. Technically speaking, UML allows for use cases to be triggered by something other than an actor, but the actor still benefits from the outcome — and that’s what matters.

  • Actors should be external to the system you're modeling. Here’s a structure to remember: there’s a target system — the thing we’re describing. There are use cases — things that can be done with that system. And there are actors who do those things. Logically, they must exist outside the system. That said — if you really want to, you can show internal use cases performed by the system itself (technically, this breaks UML orthodoxy). For example, the system wakes up every morning and triggers a data import from a third-party service. Purists will scoff, but you’re doing your job.

  • You can divide actors into primary and secondary. Primary actors are the ones we just described — those who initiate and benefit from the use case. Secondary actors are involved in the execution somehow, but don’t initiate it or get primary value from it. This is a helpful distinction. Visually, you can’t tell them apart just by the actor icons, but you can show the difference using directional associations, which we’ll talk about in a moment.
Use Case — a valuable operation a primary actor can perform with the system. Represented as an oval. A proper use case should be:

  • Valuable — You come in, do something, and leave with a result. That means something like “Log in” doesn’t count as a full use case. We’ll talk about exceptions later.
  • Atomic — One-time, meaningful operations like “Create user”, not vague abstractions like “User Management”.
  • Verb-based — Ideally phrased as an action (with an object if needed). E.g., Create user, not just User.
Relationships:

Association — a link between an actor and a use case they perform or participate in. Just a line — can be directional (open arrow) or not.

Usage:
  • If a use case has no secondary actors, use a non-directional association.
  • If there are secondary actors: direction goes from primary actor to the use case and from the use case to secondary actor. Arrow direction does not represent data flow — it’s purely a semantic marker of whether the actor is primary or secondary.
At this point, many people stop. They build a “daisy” diagram: actors, use cases, and lines between them — and call it a day. But honestly, what’s the point? How is that more informative than just listing the use cases next to each actor in text form? So, let’s not stop here. Let’s go deeper and explore what other meaningful relationships we can show in a Use Case Diagram.
Include. This relationship shows that one use case fully and necessarily includes another. Represented by a dashed arrow with the <<include>> stereotype. Direction goes from the main use case to the one it includes.

Usage:
  • To highlight that process A always contains subprocess B.
  • If use case B can sometimes be a standalone operation and other times is part of use case A.
  • If use case B is reused across multiple other use cases.

In scenarios 2 and 3, include helps avoid repeating steps — especially useful if you're writing a specification alongside the diagram.
Extend. This relationship shows that one use case optionally extends another — meaning it adds optional behavior. Also a dashed arrow with the <<extend>> stereotype. The direction is often counterintuitive — the arrow goes from the extending use case to the base use case.

Usage:
  • To show that under certain conditions or by actor choice, process A might include process B.
  • If the extending use case B can sometimes be performed on its own, and other times adds behavior to A.
  • If B extends multiple other use cases.

Again, extend helps avoid duplication in specs and diagrams.
Useful to know:
  • The association from the primary actor to included and extending use cases may be visually omitted so as not to clutter the diagrams.
  • From the applications described above for both types of relationships, it follows that the included and extending use cases may not be independently useful (i.e., they can simply be steps or subprocesses that you decided to highlight).
Let’s cook up a simple IT example.

Suppose we have a video hosting system — a somewhat battered and occasionally inconvenient analogue of YouTube. Here’s what it has:
  • Registration and login/logout
  • Watching videos (via the feed on the homepage) and uploading videos
  • Commenting and moderating comments
  • Adding videos to a “Watch Later” playlist

Here’s how this can be reflected in a diagram:
What guided our decisions in some cases:
  • You can watch a video only during the process of browsing the feed on the homepage (i.e., from the feed itself).
  • While watching a video, you can add it to “Watch Later” or leave a comment.
  • “Log in to the system” is highlighted as a separate use case (even though it is not an independently valuable use case), deliberately (understanding that this breaks the “classics’” rules) in order to a) avoid duplicating login steps in every use case in the future, b) ensure completeness of the scope (so that important functional parts aren’t hidden from readers).
  • “Log out” is made a use case for the same reason (b).
  • “Set access rights” is highlighted as an included use case to explicitly inform readers that it will be a mandatory part of video creation.
What’s described above is enough to draw decent diagrams without fuss. For those who want to know/handle more, here are some advanced practices:
Subject (sometimes called Boundary). This is an element that groups use cases by some criterion (in UML, the applicability of this element is somewhat narrower, but for an analyst, it makes sense to generalize it to “any criterion”). It’s shown as a rectangle.

Usage:

Follows from the description: use it if you want to group use cases by functional module, logical area, or any other way.
Generalization (sometimes called Inheritance). This is a relationship between actors or between use cases, showing what object-oriented approach calls inheritance. It is represented by a solid line with a hollow triangle at the end (this relationship is also actively used in other UML diagrams), going from the child to the parent.

Generalization indicates that the child element B (actor or use case) is a further specification of the parent element (actor or use case), i.e., the child clarifies and adds details to the parent. In other words, the descendant is the same as the parent, but with additional details/specifics.
Examples of generalization chains from parent to child:

  • Vehicle → Car → Passenger Car → Sedan
  • Hardware Device → Computing Device → Laptop → Gaming Laptop

To check if you’re using this relationship correctly in terms of meaning, formulate it like this: Child B is parent A with an additional specification (clarification) X.

What’s useful about this: the child inherits all properties of the parent (e.g., the common use cases they perform) but can add new, unique ones (e.g., some unique use cases).

Usage:

  • For actors: most often used to show the structure of roles or access rights. See the example below. With well-organized chains, this can reduce the duplication of many associations (common use cases for descendants are associated with a highlighted parent).
  • For use cases: used less often, but you can show that a use case is a concrete instance of a more abstract one. For example, use cases “Have Lunch” and “Have Dinner” can be generalized into a more abstract use case “Eat a Meal”. In terms of visualization, this is purely to show readers what they have in common. For further specification, this can be used to avoid duplicating sections of use cases by moving common parts to the parent — if use cases share something, some parameters will likely be common too: preconditions, postconditions, scenario steps or even entire scenarios, triggers, or other parameters.

Let’s extend our IT example by adding a) different user types as described in point 1 above, and b) variations of video creation to demonstrate point 2.
What point (a) gave us: We introduced the Unknown user, which emphasizes that Registration and Login are for unauthenticated anonymous users; Watching videos is available to everyone; but to add a video to a playlist, comment, create/delete one’s own video, or log out — the user must be known to the system. Moderator is a subtype of an authenticated user with slightly elevated rights (but importantly, with the ability to do everything the regular user can — which the previous diagram version did not reflect).

What point (b) gave us: We added two subtypes of video creation — manual upload and import from YouTube (involving YouTube, obviously).

Business and system use cases — highlighting such categories may not be hugely useful but can be helpful for awareness and understanding/reading the diagram. Everything described above can be called system use cases since we talked about an IT system. You can also build diagrams describing business/organizational use cases — how one interacts with the organization. Referring back to the earlier exception to the rules — that an actor need not be external to the modeled subject — you can also show who does what useful operations inside the organization.

Strictly speaking, this is not part of the UML standard but seems likely to become so, as it gains popularity. For modeling this, simply add slashes to actors and use cases.
Abstract Use Cases. Like in the previous case, this is mostly useful for correctly interpreting diagrams. All use case examples above were non-abstract (or “concrete,” if you prefer). Abstract use cases (and this applies to most UML elements across diagrams) are shown in italics. This means the abstract element is not “real” and exists only for some auxiliary purpose. For use cases, this means an abstract use case cannot be performed by any actor. The natural question arises: why have it at all? Typical usage of abstract use cases is in combination with generalization among use cases.

Another use of abstract use cases and generalization (technically similar to the previous but with slightly different meaning) is grouping use cases into higher-level containers, e.g.:
Note. Not exactly advanced level, but it’s useful to know that any explanations you add are best indicated according to UML rules:
Common Mistakes:

Let’s make them all on a single diagram right away (though you can actually try to spot each one and think it through before the spoilers hit):
  • “Useless” use cases, meaning those that represent nothing more than steps of a more meaningful operation, mistakenly shown as full use cases.

I recommend interpreting use cases in line with the earlier note: the actor comes into the system → performs a use case → leaves the system happy, having accomplished something useful. If this paradigm doesn’t fit your use case, consider whether it’s really a use case or just a step within another. Sure, every rule has exceptions — but it's only a working exception when you're knowingly breaking the rules for a justifiable reason (not by accident).

  • Misusing direction in associations, interpreting it as “who contacts whom” or “where data flows” instead of showing primary/secondary actor relationships.

Here’s how to properly use association directions when you have multiple types of actors: from a primary actor → to the use case; from the use case → to the secondary actor.

  • Using extend to show temporal sequence rather than optional behavior that may happen during the base use case.

On the diagram above, Logout cannot extend Login. If you do that, you’re effectively saying: "As an analyst, I suggest that every time a user logs in, the system should logically offer them the option to log out during the login process." That’s clearly not the case. From the moment the login page opens to the post-condition "Actor is authenticated and on the homepage", the system won’t be offering a logout option — that's a completely separate operation. What’s actually being illustrated is that login is a precondition for being able to log out. Preconditions aren’t shown on the diagram — they go into the use case description (but if you must show it, add a new connector with a stereotype, e.g., <<precede>>).

  • Incorrect direction of generalization: from parent to child.

Generalization must be drawn from the child to the parent, and should be understood/read as: “generalizes to” or “abstracts to.” (Pro tip: it’s always easier to grasp or describe relationships when you align with their direction of reading.)

  • Incorrect understanding of what generalization actually means.

So what’s wrong with this example? The logic seems sound: a user with the CommonUser role can do more than an unauthenticated user, and an Admin can do even more than a CommonUser. But let’s revisit the key question for validating generalization: “Is child B essentially parent A with additional specificity X?” So: is a CommonUser just an unauthenticated user with extra details? Is an Admin just a CommonUser with extras? On closer inspection, not really. A user with any role is already authenticated. And assuming roles are mutually exclusive (i.e. a user can only have one of them), an Admin is not a type of CommonUser.
The correct approach would be to introduce more actors to build a proper generalization chain: a User (as an abstraction for both authenticated and unauthenticated actors); an Authenticated User (as an abstraction for users with roles like CommonUser and Admin.
]]> UML: Class Diagram https://itmine.by/enarticles/tpost/4067s3mrf1-uml-class-diagram https://itmine.by/enarticles/tpost/4067s3mrf1-uml-class-diagram?amp=true Fri, 20 Jun 2025 21:35:00 +0300 Business analysis Class diagram: what it's for, what it contains, usage tips, and common pitfalls to avoid.

UML: Class Diagram

After reviewing the use case diagram, let’s move on — next up is the class diagram. It’s a pretty handy thing (or rather, the models you can whip up with it).

As before, here’s the notation system:
  • Blue text — tips or rules not dictated by UML, but borrowed from other useful theories or practical experience.
  • Italics — examples.
UML Class Diagram is a structural UML diagram that shows the structure of something in terms of classes and the relationships between them. Its original purpose in UML is to represent the structure of classes in a software system built using an object-oriented approach (which makes sense, since UML is built around that paradigm). In other words, it literally shows the classes in the program code — a popular way to structure software in OOP, and you’ll soon see that the diagram’s features are tailored for exactly that use.

However, a) business analysts don’t really need that, and b) it’s way too narrow of a use for such a great diagram. So analysts decided to twist the original meaning a bit and repurpose the diagram for tasks more useful to them.
When to use it:

There are two typical business analyst tasks (though your imagination doesn’t have to stop there):

1) Business Domain Model (BDM):

A model that shows the client’s business domain — its structure: subjects, objects, terms, and concepts of the domain, and how they are all connected. This is usually built during the AS IS analysis phase (to understand and systematize the domain to be automated). But it can also be used to represent the TO BE state — to show what the target domain will look like after your system is implemented.

2) Data Model:

Most commonly it’s the Logical Data Model (LDM). Some analysts go deep and distinguish three or more levels of data modeling, but I don’t see much point — I recommend focusing on just the logical and physical levels.

The Logical Data Model (LDM) shows what information the system will operate with and how it is logically connected. It’s implementation-agnostic (i.e., it doesn’t care how developers will build it later), which makes it a perfect tool for analysts who work with requirements, not their implementation. Put simply, with this kind of model, the analyst defines that the system will include Products, Catalogs, Users, and shows how they are logically related (e.g., products belong to catalogs, and a catalog may contain no more than 10 products). Whether that information ends up in a database, a text file, a cache, or even hardcoded — that’s not the analyst’s concern. That decision lies with the architect or system analyst (but, as I mentioned earlier, we’re not covering that variation — we’re talking about IT business analysts who work with requirements).

The Business Domain Model is a more niche tool — not everyone uses or loves it — and I already covered it in the first part of this article (yes, the one with the Witcher example 😉). Here, we’ll use the class diagram to build a Logical Data Model, which I recommend having any time your solution involves data or information. And if you supplement it with a data dictionary — you’re basically a level 100 archmage of requirements management. Let me emphasize: among the things analysts tend to overlook (due to lack of knowledge, skill, or desire), working with data requirements — and this model in particular — is one of the most useful in terms of improving requirement quality.
Elements:

There’s just one really useful element for a business analyst: the class.

A class is the building block of the diagram. Since the diagram shows the structure of something, the class is one of those structural elements. It’s represented as a rectangle. In the context of the Logical Data Model, classes represent data entities — blocks of data composed of smaller pieces.

If you don’t want to go into detail about what the block contains, just draw a rectangle with the name:
Now, a quick note: in object-oriented modeling, there’s a distinction between a class and an object (that’s why UML has both class and object diagrams). This will help us understand what we’re modeling and how to read class diagrams.

A class is a template or abstraction. An object is a concrete instance of that class. So in the diagram above — and in any class-diagram-based model — we’re saying that our system will deal with Products and Catalogs as general concepts — these are classes. When users actually start using the system, the database will fill up with objects of those classes — dozens of specific products and catalogs, each corresponding to the class description defined in the model. Keep that distinction in mind as we encounter those terms later in the article.
In a more advanced version of the diagram, a class can include attributes — atomic pieces of data that characterize the class/entity. For each object of that class, attributes will have specific values (e.g., for a product, the Name might be “Apple iPhone X 64GB”).
Recommendations:

  • LDM: When dividing your data into classes and attributes, treat non-atomic pieces as data classes, and atomic (indivisible) ones as attributes.
  • LDM: Always show class attributes if you don’t have a data dictionary; otherwise, put them in the dictionary to avoid duplication and reduce maintenance effort.
  • BDM: Structure entities and show attributes as you see fit — the model reflects your understanding of the domain, primarily for your own analysis.

You can also specify data types for attributes:
Recommendations:

  • For LDM, keep data types at the logical (human-readable) level — e.g., “Text” instead of Char(100), or “Integer” instead of Int(32). These will be converted into technical types in the physical model later by someone else, once the implementation approach is defined.
  • Common data types (but you're free to name/define your own): Text, Number (integer, decimal), Boolean (yes/no), Date (and/or time), Image, Video.
  • A useful type: Enumeration — a value from a predefined list. Unlike Text, where values can be anything, an enumeration limits values to a known set. Example: Status could be “Approved,” “Rejected,” or “Pending”. You can list the exact values in the data dictionary or accompanying documentation.
  • Another useful type: reference to another class by name. This one requires some focus. It’s helpful when classes are related. Let’s say your system includes Comments and Users. Are they related? Of course — users leave comments. So, one attribute of Comment will be Author. What’s its type? You might first think: text. But a better option is to show it as a reference to a User — i.e., to an object of the User class. So instead of: Author: Text you write: Author: User — meaning it's a link to an object of the User class.
Relationships:

Generalization (also called Inheritance):

If you’ve read the earlier article on use case diagrams, you’ve seen this before — but let’s recap. This is a relationship between elements (in our case, classes) showing what OOP calls inheritance. It’s drawn as a straight line with a hollow triangle pointing from the child to the parent class.

Generalization shows that class B is a more specific version of class A — the child clarifies, adds detail, or narrows the parent. In other words, the child is the parent, just with extras.
The child inherits all the parent’s properties (i.e., attributes) but can also have its own.

Usage: just as described — to show that some classes have subtypes.
The next two relationships are very similar in nature: Aggregation and Composition. Both represent “whole-part” relationships. In simpler terms, one element is included in another. If the arrow goes from A to B, it means class A is a part of class B. You can read the direction as “is part of.”
What’s the difference between these two relationships? Visually, aggregation is shown as a solid line ending with an unfilled (white) diamond, while composition is shown with a filled (black) diamond. So be careful where you paint your diamonds 🙂 Aggregation is considered a weak relationship; composition is a strong one. In conceptual terms, if destroying the parent object (in your system that might mean anything you define as destruction — permanent deletion, archiving, deactivation, etc.) also implies that the child object must be destroyed as well, then the relationship is strong — composition. If the child can exist independently even after the parent is gone, then it's a weak relationship — aggregation.

Example: Student – Group. Let’s imagine that a student can be simultaneously enrolled in both a Business Analysis course and a UX course, or any other training offered by some educational center. Now ask yourself: if the Business Analysis group is disbanded, do its Students cease to exist? Clearly not. The student still exists in the system, can belong to the UX group, or maybe no group at all — just be stored in the system as a past or future student. So this is a clear case for aggregation.

Example: Course – Educational Center. If the educational center is shut down, the very concept of a "Course" belonging to it vanishes. All courses tied to that center are also conceptually destroyed. This is a strong relationship — composition.

Usage: Just as described above — to show that one class is part of another.
Association. Association looks the same as it does in use case diagrams: a solid line, optionally with an open arrowhead indicating direction. An association is any meaningful or structural relationship between classes. We cover it last, because it’s a fallback: if you can’t describe the connection using inheritance, aggregation, or composition — use association.

Recommendation: In models used by business analysts, always make associations directed and always label them. Without direction and names, associations — being highly abstract — are often impossible to interpret correctly.
Multiplicity. Relationships can (and should!) also include multiplicity. Multiplicity defines how many instances of one class can be linked through this relationship.

Let’s break down an example:

1) 1..* Products belong to 1 Catalog.

1.1) To define multiplicity for the Product end: How many Products can "belong to" one Catalog? Think in ranges. From 1 (let’s say we don’t allow empty catalogs on the website) to infinity (no upper limit — shown with an asterisk).

1.2) For the Catalog end: How many Catalogs can contain a given Product? Let’s say each Product must belong to exactly one Catalog — not more. That gives us 1..1 or just 1.
2) 1..4 Products can be part of 0..* Orders.

2.1) How many Products can be in a single Order? Say the system limits it to a maximum of 4 products per order. So the range is 1 to 4 (since an order must have at least one product).

2.2) How many Orders can a single Product be part of? Maybe none (if it’s never ordered) or many — so: 0..*.
Recommendations:
  • LDM: Always include multiplicity for all relationships except generalization. Multiplicities are a goldmine of insight — they lead to valuable business questions and rules that should be reflected in the system.
  • BDM (Business Data Model): Use multiplicity when helpful — it's up to you.
Now let’s return to the example from our earlier article on use case diagrams. Our scenario:

We have a video hosting platform — a kind of rough, stripped-down version of YouTube. It has the following features:

  • Registration, login/logout
  • Viewing videos (via a homepage feed) and uploading new ones
  • Commenting and moderating comments
  • Adding videos to a "Watch Later" playlist

Let’s build a logical data model for this system.
Notable elements:

  • The system will store data (classes) such as Users, Videos, and Comments.
  • Users will have attributes including a Role, since we have different user categories (e.g., moderators). This will be an enumeration — a value from a predefined list.
  • Each Video will have an Author, which is a reference to a User — same for Comments.
  • A User can author 0 to many Videos and 0 to many Comments.
  • Moderators are a subclass of User and have a separate association with Comments — they moderate them.
  • Multiplicity here shows that each Comment must be moderated by 1 Moderator, though some may still be pending (i.e., not yet moderated).
  • Each Comment is part of a Video — and this is a composition: deleting the video will delete its comments too.
  • There's an interesting aggregation from Comment to Comment — a comment can belong to another comment. This models comment threads (nested replies). That’s also why the Comment class has a Parent comment attribute. So, why aggregation? Because in our setup, deleting a parent comment doesn’t delete its replies — instead, we just show “Comment deleted,” and keep the replies visible. Multiplicity for this relationship: Each Comment can have 0 to many replies (child Comments). Each Comment can be a reply to 0 or 1 parent Comments.
Some advanced aspects of UML Class Diagrams (not strictly necessary for analysts, but worth knowing).
In a more complete version of a class, you might also see operations (methods), along with a number of additional markers for the elements we’ve already discussed.

These aren’t likely to be essential for a business analyst, but it’s good to have a basic understanding — so you can read such diagrams confidently and know where to look deeper if needed:
  • Access modifiers can appear before an attribute’s name: a minus, a plus, or some other symbols. In development (for code-level classes), this defines whether the attribute is visible to external objects outside the class. To simplify, let’s take Student as a class: an attribute like Grade is visible externally (e.g., to the trainer) — in fact, it’s the trainer who sets it. Its access modifier will be public (“plus” symbol). An attribute like Confidence, however, is likely an internal attribute visible only to the object itself — its access modifier is private (“minus”).

  • In addition to attributes, a separate section may include Operations. Again, this applies to code-level classes: these are either operations that can be performed on the class, or operations that instances of the class can perform themselves. Operations also have access modifiers, return data types, and (in parentheses after the name) input parameters they can accept.
Classes can also be abstract. We already touched on this in a previous article on use cases, but to repeat: the names of abstract elements (in this case, classes) are written in italics. What does this mean? An abstract element is not “real” — it exists only for supporting purposes. A typical use case for abstract classes is their combination with generalization.
Common Mistakes:

Let’s make them all in one diagram (you can practice by trying to think through each one before the spoilers hit):
  • Incorrect directions of relationships.

With associations, it’s fairly straightforward — just follow the advice to always name them in the direction they should be read. But with other relationships, it’s easy to get confused.
  • Generalization is drawn from the child to the parent and reads as “is generalized into” or “is abstracted into.”
  • Composition and aggregation are also drawn from the part (child) to the whole (parent) and read as “is part of.”

  • Confusing generalization with aggregation/composition.

Generalization/inheritance = A is a more specific version of B. Aggregation/composition = A is a part of B as a component. There’s a big difference. In the earlier example, a Moderator cannot be part of a User. A Moderator is a type of User.

  • LDM: confusion between "system stores" and "system operates on".

When I say “confusion,” I mean the following: If you don’t know what the physical implementation of the data will be — whether a particular piece of information will be stored in a database or somewhere else — use the term: “The system operates on information X” when building your LDM (Logical Data Model). If you’re a bit more technically inclined and know for sure (or have found out) what will be stored and what won’t, then use the term: “The system stores X.” Example from the diagram: Should Email (emails sent by the system to users) be considered part of the LDM? Simplest approach: If you’re unsure, just include them in the LDM as information the system operates on. Developers will decide what to do with these emails — likely together with you. Advanced approach: If you’ve leveled up in your understanding of the system, you might say: “I know these emails won’t be part of our database, so I won’t include them in the model,” or: “I know we need to save all emails for history/logging purposes, so I’ll include them.” Only take this approach if you’re confident in your conclusions about how it’ll be implemented — or if you’ve already consulted with the devs.

  • LDM: slipping into a physical data model.

We’ve already covered how a Logical Data Model differs from a Physical Data Model. Do not include in your logical model:
  • IDs of records (ID)
  • primary and foreign keys
  • join tables for many-to-many relationships
  • technical data types
And other similar things that your technical background might be tempting you to include. All this is only relevant if the physical implementation will, for example, be a relational DB. I myself have a developer background, but even if I know our DB will be MySQL, I deliberately avoid making decisions like “there should be an ID in each class,” or “here’s how the tables will look,” etc. I must recognize that the team includes specialists who are more professionally equipped to make such decisions. And if designing the DB is not my area of responsibility (a systems analyst with a clear mandate might be in a different situation), then I shouldn’t be doing it — and I certainly shouldn’t be restricting the creativity of the person who will do it with unnecessary and clumsy decisions on my part.
]]> UML: Activity Diagram https://itmine.by/enarticles/tpost/mver50enp1-uml-activity-diagram https://itmine.by/enarticles/tpost/mver50enp1-uml-activity-diagram?amp=true Sat, 21 Jun 2025 12:09:00 +0300 Business analysis Activity diagram: why it’s needed, what’s interesting about it, and how not to mess up when drawing one.

UML: Activity Diagram

Next up: the Activity Diagram (we've already looked at Use Case and Class Diagrams).

Once again about notation:
  • Blue text — tips or rules not dictated by UML, but borrowed from other useful theories or practical experience.
  • Italics — examples.
An Activity Diagram is a process diagram (a type of behavioral diagram in UML). There are several of these in the world: flowcharts, Business Process Diagrams in BPMN — you'll find a close analogue in almost any notation. These diagrams illustrate steps in a process, their sequence, branching/loops and their conditions, and sometimes even who is responsible for what.

When to use it:

Use an Activity Diagram when you need to visually depict the kinds of things described above: a use case scenario that's too complex to read as text, a button behavior with tons of steps and branches, complex logic behind system calculations or decision-making, the flow of a business process, etc. Visuals make it easier for you to assess correctness and for others to understand.
Elements:

Action: The core element of the diagram — an atomic step within the process being modeled. For example, a step in a use case scenario. It's shown as a rectangle with rounded corners.

Decision and Merge: Show how a process can branch depending on some condition or merge back into a single flow. Both are shown as diamonds. For example, during a use case, the system checks if input data is valid and either proceeds or displays an error.
Nuances:

  • A decision is a fork into alternative flows (either-or); only one of the outgoing flows will be followed. To visualize this properly, imagine a dot (or dots) traveling through the diagram over time.
  • When flows merge, a merge waits for one incoming flow (not all). As soon as one arrives, the process continues. See the note about merge in the earlier example.

There are two ways to indicate what the decision is based on:

  1. Place the condition/question near the decision diamond, and write answers (called guards) in square brackets on the outgoing arrows. Analysts often skip the brackets — not strictly UML-correct, but understandable.
  2. (More UML-purist) Write full guard conditions on the outgoing arrows, without labeling the decision node itself.

Initial Node and Activity Final Node: The start and end points of the process. The initial node is a filled-in circle; the final node is the same, but inside a hollow circle. Analysts often label these with the system or actor state at the start/end of the process — great for use case preconditions/postconditions.
Nuances:

There can be multiple initial nodes, meaning the process starts from all of them — rare, but a great interview flex. There can also be multiple end nodes; the process ends when it reaches any of them.

Partition: A visual division of the diagram that groups elements by participant. For a use case, typical partitions are "Actor" and "System". These can be displayed horizontally or vertically.
Fork/Join: Similar to Decision/Merge but for parallel flows. Displayed as thick horizontal or vertical bars.

Nuances:

Unlike Decision, a Fork splits the incoming flow into multiple concurrent flows. A Join waits for all incoming flows (not just one) before the process continues.
Connections:

The primary connection is Control Flow — arrows with open heads that connect elements. These can include guards in square brackets, which define the conditions under which the flow follows that path. Especially relevant for decisions.
Advanced aspects:

You can show data passing on the diagram in two ways (and honestly, I still don’t know the meaningful difference between them — if you do, please send me a comment):

Object: A rectangle representing a data object passed between elements.
Even though the arrow looks the same, it’s formally an Object Flow, not a Control Flow. Mentioning that at interviews is sure to impress.

A second approach: Pins. Small squares attached to actions, also used to indicate data input/output.
Activity: This is the process itself. Everywhere we've said "process," you could swap in "Activity." The diagram as a whole is about one Activity. Sometimes boundaries of the Activity are shown explicitly — a rounded rectangle around the whole diagram.
To embed one process into another, use a special type of action: Call Activity Action. If you see an action with a trident icon, that means it's a call to another Activity, usually detailed in a separate diagram.
Interruptible Edge: Useful but can clutter your diagram. This lets you show that something can go wrong in a region of steps (not just a single action). For instance, the user could cancel the whole process at several steps. It involves a dashed-line region, an event symbol, and a lightning-bolt-shaped Interrupt Flow.
Common Mistakes:
As before, here are all of them in a single diagram. Then we’ll break it down.
  • Missing decision, merge, fork, or join elements where branching or merging happens.

Informal rule: actions should have just one input and one output. If more, you need branching/merging elements (diamonds/bars).

  • No actions — replaced by flows.

Flows (Control, Object, Interrupting) just connect elements. They cannot be actions or data objects. Always explicitly show actions.

  • Dangling subprocesses, missing branches, broken loops, and other logic errors.

If an action has no outgoing arrow, your process is stuck. Imagine those moving dots again: they must reach an end. A decision or fork with only one outgoing flow, or a merge/join with only one input? You're doing it wrong — these elements are meant to split or combine flows.

  • Missing guards on decision outputs.

Without guards, how do we know which path to take? Just add them.

  • Confusing actions and events.

An action is something done ("the system checks X"). An event is something that happens ("timeout occurs"). UML has a way to show events, and we covered one variant (interrupting event). They’re rarely needed and not everyone reads them well, so we mostly skip them here. Just don't mix the two.
]]> UML: State Machine Diagram https://itmine.by/enarticles/tpost/upydulblp1-uml-state-machine-diagram https://itmine.by/enarticles/tpost/upydulblp1-uml-state-machine-diagram?amp=true Sat, 21 Jun 2025 13:12:00 +0300 Business analysis State diagram: its benefits, drawing guidelines, and common misinterpretations.

UML: State Machine Diagram

Up next: the state diagram (or UML State Machine, if you want to sound fancy). We’ve already talked about UML in general, use cases, class diagrams, and the activity diagram.
As before, here’s the notation system:

  • Blue text — tips or rules not dictated by UML, but borrowed from other useful theories or practical experience.
  • Italics — examples.
A UML State Machine Diagram is a type of behavioral diagram that shows what states an object (the one we’re modeling) can be in and how these states change over the course of the object’s life.

What does “state” even mean? A state is a situation in which an object has certain fixed characteristics. Sounds complex, but for example, our “states” throughout the day might include: tired, inspired, hungry, sleepy, and so on — and we can be in multiple of them at once. Take the state tired: that just means the parameter “energy level” is low. Some triggers (events or actions) can change that parameter and thereby cause a shift in state — for example, the action take a nap (though not only that one).

To show the full picture of how our states change throughout the day — what states we can be in, and what triggers lead to transitions — we use a state diagram.

Business analysts use these diagrams to show the lifecycle of some data class from the logical data model, or to describe/analyze the states of a business domain entity while exploring the subject area. It’s useful when the object in question has a non-trivial lifecycle — in other words, when a data class or domain entity goes through several clearly defined states during its existence.

For instance, let’s say we’re building an electronic document management system. One of the key data classes is Document. In such a system, documents have a fairly complex life: scanned, sent for review, approved, archived, and so on. These are its statuses throughout its journey in the system — i.e., its states.
Elements:

There’s one key element here — the State. It's drawn just like an action in an activity diagram: a rectangle with rounded corners.
Initial State (sometimes formally called a Pseudostate, though that's diving into scary depths of UML philosophy) — This is the starting point of an object’s life, or of the part of its life we’re modeling. Like in the activity diagram, it's drawn as a filled black circle. It (and the outgoing transition) simply shows where the object’s life begins — i.e., which state is the starting one.
For example, if we’re modeling a person’s food-related states throughout the day, we assume their day starts hungry. So that’s the initial state we mark.
Final State — This marks the end of the object’s life (or of the modeled segment of it). It’s shown, again like in activity diagrams, as a black circle inside another circle. In our example, it means the person can go to bed from any current state.
There’s only one type of connection we care about here:

Behavioral Transition — A link between states that marks a possible change from one to another.
This connection can contain several parameters, but we’ll focus on:
  • Trigger — A label without brackets, specifying what action or event causes the transition from one state to another.
  • Guard — Like in activity diagrams, a guard is the condition under which a trigger actually causes the transition. If the guard isn’t met, the trigger won’t do anything. Just like in activity diagrams, it’s placed in square brackets.
In earlier articles, we discussed a video hosting system, built a use case diagram and a logical data model for it. I won’t repeat the scenario here, but recall that a data class called Comment had a status (shown in the data model). Moderators can make decisions on comments, effectively changing their status — i.e., transitioning between states.

This makes it a perfect use case for a state diagram.
Advanced Aspects:

Composite State — A state that contains substates. You can show transitions within it on the same diagram or split it out into a separate diagram (linked with the “double circle” symbol):
That’s pretty much it. UML does allow for additional elements in this diagram, but considering that business analysts don’t need this type of diagram often (and when you do, it’s very useful), we’re not going to dive into that extra complexity. No need to overcomplicate things.
Common Mistakes:

There aren’t many, since the diagram is simple to draw. But here are the usual suspects:

  • Pointless Usage

Don’t create “logically meaningful” states just for the sake of it. That’s just wasted effort. If you define states in your requirements, they should be driven by actual needs. Take our original example of a Comment: we shouldn’t say “conceptually, a Comment can be created, edited, viewed, deleted — so let’s make all those into states.” That’s useless. It adds no value to the understanding or implementation of the system. When you define states, you’re saying the system has to track them — which probably means you now need an attribute like Status on the Comment entity, which must change according to transition rules. The system needs to do this for a reason. If there’s no reason — don’t add the states.

  • Confusing Actions with States (And Misunderstanding the Diagram’s Purpose)

At a glance, someone might go: “Wait, isn’t this just another activity diagram? Why do we even need this thing?” I thought the same thing myself, back when I was trying to grasp the dao of this diagram. Maybe I’m just a little dense, but it took some digging to get that there’s a fundamental difference between a process and an object’s lifecycle.
We’re not showing a scenario here — steps, branches, actors, etc.
We’re showing what states an object can be in, and how it transitions between them over time.
This isn’t a “Have a meal” process (what steps it has, who’s involved, what can go wrong), but rather: what hunger-related states a person can be in during the day, and what transitions between them are possible — including when the day begins and ends.

Still don’t see the value? Well: you probably need to work with some complex entities in real life before this clicks. Or just consider the example above: Document in a document management system. Now imagine that document can have 20+ statuses as it moves through the system — all of which must be tracked. Why? At the very least, to show users the right status icon. And at most, to allow or block certain operations depending on current status. This diagram makes it easier not to miss key requirements, because it forces you to ask:
  • Can a document go from status A to status B?
  • Can it go back?
  • What causes the transition?
  • Under what conditions?
  • In which states can a document be created?
  • Or deleted?
  • What does it even mean for a document to “die”? Deletion? Archival?

These are critical questions you might overlook unless you zoom out and look at the bigger picture — and look at it from this angle.
]]> UML: Sequence Diagram https://itmine.by/enarticles/tpost/lhxj61n9d1-uml-sequence-diagram https://itmine.by/enarticles/tpost/lhxj61n9d1-uml-sequence-diagram?amp=true Sat, 21 Jun 2025 13:45:00 +0300 Business analysis Sequence diagram: why use it, what it includes, and common mistakes.

UML: Sequence Diagram

Last up in our UML series — the Sequence Diagram.
As always:
  • Blue indicates advice or rules not dictated by UML itself, but borrowed from other practices and theories.
  • Italics are for examples.
The Sequence Diagram is one of the behavioral diagrams in UML, and it belongs to a broader category called interaction diagrams. As Captain Obvious would say, these diagrams focus on interactions between participants in a process — and the Sequence Diagram is no exception. It visualizes how objects exchange messages over time. Think of it as similar to an activity diagram, but with a focus on who talks to whom when, rather than the steps of a process. This makes the sequence diagram especially useful when you have a process involving many participants and need to show the order and flow of interactions.
Elements and Connections:

We’ll mix elements and connections here to highlight the diagram’s key features:

Lifeline — represents a participant in the interaction. It’s like a partition in an activity diagram. Drawn as a rectangle (the object/participant) with a dashed line (“lifeline”) extending downward, indicating its active lifespan in the process.

By UML standards, the name inside the rectangle would be: objectName : className

But since we’re business analysts, we usually don’t show object and class details — we simply name the participant directly.
If the participant is external to the system (like in use case diagrams), you can use an actor icon to show that. In our example of a pizzeria, the person ordering pizza is outside the system and is therefore modeled as an actor.
Message — the essential connection. It represents an interaction between participants. Philosophically, not all messages are literal — they could represent clicking a button, for example. Messages are arranged top-to-bottom based on their order in the process. Each message is labeled with the interaction’s nature or data being passed.
Execution:
You’ll see “tubes” along lifelines where messages occur — these are Executions (Execution Specifications, Activations). Many just refer to them as activation bars.

These bars represent a time span during which a participant is actively doing something in the context of the process. Some modeling tools generate them automatically when you add messages to the diagram. You can label them to show what the participant is doing — though in practice, this is often skipped.

Still, reading them correctly helps: in our earlier example, the actor is “active” from the moment the order is submitted to when it's confirmed — logical, as they're engaged in placing the order. After that, they're inactive until the pizza is delivered.
More about messages:

1) Messages can be synchronous or asynchronous.

  • Synchronous message (solid arrowhead — all messages in the earlier diagram are like this) means the sender waits for a response before continuing. That is, the diagram should include a reply.
  • Asynchronous message (open arrowhead) means the sender does not wait for a response and proceeds immediately after sending.

2) Messages can be shown explicitly as responses to prior requests. Such reply messages are drawn as dashed arrows.

3) A message can indicate that it creates an object (e.g., a data object in an IT system). In that case, the message arrow points into the rectangle representing the newly created object (not its dashed lifeline). That object becomes a new participant (Lifeline) in the diagram. In an Activity Diagram, this would be done with Object or Pins. For clarity, it’s useful to add the stereotype «create».

4) A message can indicate that it destroys an object. In that case, we place an X mark at the end of the object's lifeline to show that it ceases to exist after receiving the message. The message itself isn’t styled differently, but again, for clarity, you can add «destroy».

5) Self-message: a message to oneself. This is a looped arrow returning to the sender. Formally, it indicates the object is invoking its own internal function, but for analysts (who don’t write code), this is usually used to emphasize key steps that the participant performs independently, without involving others.

Let’s add all that to the diagram:
What else?

Combined Fragment — this is an element used to show more complex process flows than simple sequential message exchanges. It’s shown as a rectangular region enclosing a “complicated” block of messages, with a keyword at the top indicating the fragment type.

Most useful fragments:

  • alt — shows alternatives (branches) in the process. It’s split into sections, each showing one possible path and its condition (in square brackets).
  • opt — shows optional interaction. Unlike alt (where one path out of several is followed), opt indicates that the entire fragment happens only if a certain condition is met.
There are other fragment types — loops, parallel flows, etc. We won’t cover them here as they are rarely used, but the formatting is similar to alt and opt.
Common Mistakes:

  • Overloading the reader.

You’ve probably already noticed: once we add fragments, object creation/destruction, and self-messages — the diagram becomes barely readable. You have to squint and focus, really working your brain. Keep that in mind. Any model is just that — a limited representation of what we’re modeling. Don’t try to show everything (data creation and deletion, all possible branches and steps). This is not an Activity Diagram, nor a Data Flow Diagram. A Sequence Diagram emphasizes the order, timing, and interaction between participants. If the diagram starts turning into a monster, consider showing some of that content in other diagrams more suitable for it.

  • Sequence Diagram vs Activity Diagram.

This is essentially a continuation of the previous point, but let’s call it out explicitly. At first glance, a Sequence Diagram may seem like just an Activity Diagram for multi-actor processes. It also shows process dynamics, but the focus (and this is key) is more on how participants interact, rather than on process steps.
In an Activity Diagram, what stands out are the steps, branches, loops, and other algorithmic elements. In a Sequence Diagram, it’s the participants and the order and method of their interactions.
Some business analysis gurus believe that Sequence Diagrams are more complex and confusing than Activity Diagrams — and dislike them for this reason (arguing that business stakeholders better understand Activity Diagrams). Still, it’s a useful tool to have in your arsenal. When you need to emphasize communication, a Sequence Diagram can illustrate it more clearly. Just make sure you understand what you're trying to show. For instance, illustrating a use case scenario — in my view — is not the best use of a Sequence Diagram. It’s a matter of taste, of course, but most use case discussions focus on steps, exceptions, and alternatives — not participant interaction. Unless you’re working close to a systems analyst, where system components are part of your requirements, this often isn’t necessary. And when a use case has only two participants — the actor and the system — you’ll end up showing all the steps as Self messages, and all exceptions/alternatives as Combined Fragments, which just clutters the diagram. That doesn’t really simplify communication.

  • Ignoring Response Messages.

Response messages (dashed arrows) are a widely accepted way to show that a certain interaction is a reply to a prior request. Many people experienced with such diagrams can quickly scan and identify responses this way — so don’t ignore the importance of thinking through message types and when/how to use different arrow styles.

  • Confusing Synchronous and Asynchronous Messages.

It’s not always critically important, but if you're using different arrowheads, make sure not to mix them up. Synchronous messages require a response. For instance, when a user clicks a link, they wait for the system to show a new page — they can’t continue in the process until they get the page or an error. On the other hand, when a user places an order, they usually don’t wait for an email confirmation that the order was created — they move on with the process of receiving the order. That’s asynchronous. If waiting for the email is necessary, then be deliberate about it and mark it as synchronous.
]]> Design and Implementation Constraints https://itmine.by/enarticles/tpost/xryggf6e51-design-and-implementation-constraints https://itmine.by/enarticles/tpost/xryggf6e51-design-and-implementation-constraints?amp=true Sat, 21 Jun 2025 18:08:00 +0300 Business analysis Reflections on what it actually is, an analysis of classic theories, some disagreements with those same theorists, and an approach to working with this type of requirements.

Design and Implementation Constraints

Today, I’d like to talk about constraints (in the sense of "design and implementation constraints"). These will be free-form reflections on this rather specific and rare type of requirements in the practice of many analysts. The goal is to understand what the experts say about it and share some of my own thoughts. I often find that this kind of requirements is challenging for analysts, especially beginners, so let's try to unpack it.

First things first: what is it exactly, and where does it fit in the broader set of information analysts work with?
Karl Wiegers and Joy Beatty — Software Requirements v.3:
A restriction that is imposed on the choices available to the developer for the design and construction of a product.
Let me rephrase this: a limitation imposed on the range of solutions available to developers in the context of designing and building a product.

I’ve emphasized key points here that we'll return to shortly. In Wiegers' classification, this is a subtype of non-functional requirements. He discusses constraints quite thoroughly, which I’ll explore later.
BABOK v3.0:
An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.
If we get philosophical, we could say this basically aligns with the definition before. But not necessarily — there’s room for alternative interpretations. Still, BABOK doesn’t offer much more on the topic, so we won't dive further here.
CPRE Foundation Level Handbook (IREB):
Constraints are requirements that limit the solution space beyond what is necessary to meet the given functional requirements and quality requirements.
Requirements that limit the solution space beyond what is needed to satisfy functional and quality requirements. Again, these are requirements, similar in meaning to what has been described above. Notably, in IREB’s classification, constraints are a separate category alongside Functional and Quality Requirements.
Now, here’s my own interpretation: constraints are things that limit the development team’s creativity in how they implement a solution. To grasp this more clearly, I recommend reading the article about what requirements actually are and how they differ from implementation details.

In particular, here's what we need to understand: there are requirements (what the solution must include) and implementation details/designs (how to implement those requirements). A feature like "Order Creation" and its functional and quality aspects are requirements. Code, database structures, and other developer decisions (and note: not just developers — this includes the entire development team: frontenders, backenders, testers, UX designers, project managers) are implementation details. These areas overlap, and sometimes it’s unclear where something belongs. It depends on the team and its processes (see the previously mentioned article).
In an ideal world, the customer and other external stakeholders are sources of requirements — they define what is needed. The how is up to the development team, the experts. As in: “Folks, don’t meddle in our domain — we’ll decide how to build what you need. That’s what you pay us for. You don’t need a database table called 'Orders' — you need to be able to create an order a certain way.” Of course, we all know that "what" doesn’t only come from people. Requirements can stem from business rules, documents, processes, systems, and more.
The point here is that sometimes external factors (stakeholders, regulations, third-party systems, etc.) do interfere with the how. Simply because they can. And when they do, they limit the development team’s options in design. This isn’t an ideal situation for us — teams don’t like being told how to do their job. But sometimes, there’s no choice: the client pays the bills; governments don’t care about your feelings; third-party services have rules for integration. So, who else but the analyst, the bridge to the outside world, should uncover these constraints?
Let’s look at it another way: constraints are a very specific kind of requirements that reflect how external entities interfere with the how. It might take time to internalize that.
Examples from Karl Wiegers' book with some notes:

CO-1: The system’s design, code, and maintenance documentation shall conform to the Process Impact Intranet Development Standard, Version 1.3.

Architecture, code, and documentation (yes, documentation is also part of how you develop the system) must conform to an external standard. Whether it's actually external in Wiegers' example isn't clear, but if it’s internal, then it’s not a constraint — just internal rules.

CO-2: The system shall use the current corporate standard Oracle database engine.

The development team is limited in the choice of DBMS.

CO-3: All HTML code shall conform to the HTML 5.0 standard.

A constraint on how HTML is written.

Mr. Wiegers also offers this insight:

Requirements that incorporate or are written in the form of solution ideas rather than needs are imposing design constraints, often unnecessarily, so watch out for those.

When stakeholders offer solutions instead of needs, they create constraints. And yes, that’s true. Whether and how to treat them as constraints is up to us. For example, UI often sits in the grey zone between requirements and designs. Many would argue that UI is a "how", not a "what". Ideally, stakeholders shouldn’t dictate specific UI implementations — just the quality expectations (usability, speed, etc.). It’s good to be aware of this, especially since your team likely includes UI experts. Maybe it’s even you, the analyst.
So, when a user says, "I want to click a link to create an order," don’t treat it like any other requirement. Instead:
  • Listen.
  • Ask: why exactly this way? “Look, we’re the experts here, my friend. Is it truly essential that this is a link? Why? If it is, sure — but maybe leave the decision about which control to use to our in-house experts, aka the smart people?”
  • If the constraint turns out to be non-negotiable then pass it along to the designer with something like: “This one has to be just like that — sorry, mate.”
  • If you manage to convince user that it’s not worth tying the team’s hands (for instance, by immediately offering him some friendlier alternatives), then don’t do anything at all. Just design it the way your team sees fit.
Let’s now look at what else Mr. Wiegers says about constraints (and I’ll dare to disagree with some of it — maybe I haven’t yet matured enough to see it his way — happy to discuss in the channel comments if there’s something I’ve misunderstood).

Sources of constraints include: ■ Specific technologies, tools, languages, and databases that must be used or avoided.

Yes — if these aren’t internal team decisions but are dictated from outside.

■ Restrictions because of the product’s operating environment or platform, such as the types and versions of web browsers or operating systems that will be used.

I disagree. Requirements about the operating environment are part of the solution requirements, not external constraints. They guide the implementation, sure, but that’s just regular development. Requirements, by nature, influence how the system is built. Okay, so we need to support Google Chrome as the browser — fine, we’ll design accordingly, taking that into account. How is that different from accommodating any other requirement like support for a specific feature?
■ Required development conventions or standards. (For instance, if the customer’s organization will be maintaining the software, the organization might specify design notations and coding standards that a subcontractor must follow.)

Exactly — yep. The example in parentheses makes it clear why this is a valid constraint.

■ Limitations or compliance requirements imposed by regulations or other business rules.

Yes — business rules (e.g. legal requirements around data storage in a given country or domain) are absolutely legitimate sources of constraints.

■ Interfaces to other existing systems, such as data formats and communication protocols.

Absolutely: if we need to integrate with something, that “something” might dictate how we store or encrypt the data we send. A third-party service might say, “Sure, we’ll open up our API to you — but only if your customer data is stored on your end in this exact encrypted format.”

■ Restrictions because of the size of the display, as when running on a tablet or phone.

Don’t agree — for the same reasons mentioned earlier. Screen size is part of the environment. If we’re building a system for the iPhone, its dimensions and specs are just requirements for where the system will run. Do these factors influence developer decisions? Yes, of course — just like any other requirement. But I don’t see how they’re external constraints.
These aren’t all of them, of course — but to me, they’re the most interesting and illustrative examples from Mr. Wiegers’ book.

Here are a few more examples from him that I find helpful:
CON-1. The user clicks at the top of the project list to change the sort sequence. [specific user interface control imposed as a design constraint on a functional requirement]

CON-2. Only open source software available under the GNU General Public License may be used to implement the product. [implementation constraint]

CON-3. The application must use Microsoft .NET framework 4.5. [architecture constraint]

CON-6. All textual data used by the application shall be stored in the form of XML files. [data constraint]
But then here’s another excerpt worth examining:
Note that some of these constraints exist to comply with some perhaps-unstated quality expectation. Ask why each constraint is imposed to try to reach that underlying quality requirement. Why must open-source software be used, as stated in CON-2? Perhaps because of a desire for increased modifiability, so that’s the requirement that leads to the constraint.
Here again, I’ll push back on the maestro a bit — or maybe just try to extend the thinking. So what’s the actual constraint here? If, based on a modifiability requirement, the development team chooses to use only open-source software, then this isn’t a constraint at all — it’s a straightforward internal design decision about how to implement a stated requirement.

However, if this mandate comes from an external stakeholder, then:

  1. You investigate — “Why exactly like this?”
  2. You find out that the stakeholder chose this solution to fulfill an underlying need (e.g., modifiability).
  3. You reflect that back: “Okay, so if extensibility is what you really care about, maybe let us decide how best to implement that?”
  4. If they agree — then CON-2 doesn’t need to be written down at all.
  5. But only if they don’t agree (and they have the authority to enforce it), does this become a legitimate constraint.
Now here’s what IREB has to say about sources of constraints:
When specifying constraints, the following categories of constraints should be considered:

▪ Technical: given interfaces or protocols, components, or frameworks that have to be used, etc.

▪ Legal: restrictions imposed by laws, contracts, standards, or regulations

▪ Organizational: there may be constraints in terms of organizational structures, processes, or policies that must not be changed by the system.

▪ Cultural: user habits and expectations are to some extent shaped by the culture the users live in. This is a particularly important aspect to consider when the users of a system come from different cultures or when Requirements Engineers and developers are rooted in a different culture to the system’s users.

▪ Environmental: when specifying cyber-physical systems, environmental conditions such as temperature, humidity, radiation, or vibration may have to be considered as constraints; energy consumption and heat dissipation may constitute further constraints.

▪ Physical: when a system comprises physical components or interacts with them, the system becomes constrained by the laws of physics and the properties of materials used for the physical components.

▪ Furthermore, particular solutions or restrictions demanded by important stakeholders also constitute constraints.
What makes me a bit uneasy are the italicized items:

Organizational seems to me like regular business rules, which — if relevant to the solution — should be reflected in the requirements. How exactly do these become constraints on design rather than just requirements the system must meet?

Same goes for Cultural: can user habits and expectations really dictate development process or technical choices? Would love to see concrete examples here to make that clear.
To sum up:
  • Understanding constraints and working with them effectively is incredibly useful.
Without that understanding, the development team may overlook these issues — and by the time they realize, it may be too late (think: major architecture changes leading to massive cost overruns).
But with this understanding — and with an analyst trained to look for them — the team can work with a clear list of things that must be considered during their creative implementation phase.
  • Basic algorithm for working with constraints:

1) Identify them — notice them in conversations, go through a checklist, study relevant laws and API docs, think through where constraints might be lurking in your project context.
2) Check if they’re truly unavoidable — ask: “Is this really a constraint? What happens if we remove it?”
3) Pass them to the team — ideally in the SRS or on a dedicated Confluence page — along with a tissue to wipe away the tears.
]]> IT Business Analysis — The Overall Process https://itmine.by/enarticles/tpost/7f4vocc391-it-business-analysis-the-overall-process https://itmine.by/enarticles/tpost/7f4vocc391-it-business-analysis-the-overall-process?amp=true Sat, 21 Jun 2025 18:43:00 +0300 Business analysis An overview of the typical stages of a business analyst’s work on a project.

IT Business Analysis — The Overall Process

Friends, in this series, I’m going to attempt an unusual and seemingly challenging task: to describe the business analysis process within an IT project as a usable guide.

It’s unusual because I haven’t seen such a guide in accessible terms and manageable volume. Authors typically like to discuss individual techniques rather than the process as a whole. It’s challenging because, in my opinion, the task is hardly fully achievable. Both points stem from the fact that IT business analysis is a creative kind of wizardry, only loosely susceptible to algorithmization. In other words, it’s not always clear what the final result should look like (the specific business analysis tasks can vary greatly from project to project and company to company), let alone the fact that the set of steps will almost always be unique. Describing the mission as “help the client realize their needs” is difficult to reduce to clear-cut instructions. Nevertheless, I will try — at least for the majority of projects a typical IT specialist encounters.

I should mention that, for example, I once lacked a guide along the lines of “take this as a foundation and then refine it yourself.” The closest thing I found was Karl Wiegers’ Software Requirements, but you had to actively chew through a lot of text. I hope my own vision (based on Mr Wiegers’ work, mixed with cool practices from BABOK, other solid theories, and personal experience) in the form of a concise guide covering typical business analysis stages will help beginners not to get lost and help more experienced folks tune their processes.
Of course, a sea of disclaimers upfront:

1) Describing the entire business analysis process from start to finish is, to put it mildly, a huge task. This guide will be simplified: it won’t cover every type of project, every software development approach (models, methodologies, frameworks, and so forth), every client type and domain, every team context (experience, distribution, etc.), and certainly not every possible scenario (especially those involving a full moon on the fifth month of a leap year).

2) There’s a saying that one of an analyst’s favorite expressions is “it depends.” That is, an analyst is not a role that acts repeatedly by a single algorithm under a clearly defined task. It’s more like a luggage carrier of techniques, from which they craft a specific process adapted to the here and now. But, again, I lacked a base back then to understand how one could even start shaping that final process. I only had a vague idea of where to dig and some clumsy thoughts about first steps. So, here I’ll describe an averaged typical process through my own lens. It can and should be modified by adding mental effort and project context.

3) Everything will be quite simplified. This is not a specification — it’s a quick start guide. Emphasis on what exactly to do and which hammer to pick up. There will be assumptions, simplifications, and scientific precision will definitely suffer. The full books polishing this foundation have already been written by Mr Karl and other great specialists.
To start, the business analysis process in IT projects looks like this:
In general, this is the process a spherical-in-a-vacuum business analyst needs to go through on a project to bring happiness to all stakeholders. That is, take these stages, reflect on their relevance and specifics for your current project, and get to work. Here’s the essence of each stage (we’ll discuss them in detail in future posts):
Business Analysis Planning and Stakeholder Identification/Analysis.
Conceptually, this is simple. Like any project activity (and business analysis is a mini-project, yes), first you need to think about how, when, what, with whom, and for what you will do. You can try to painstakingly design a plan as reliable as Swiss watches, or accept the uncertainty of our creative work and focus only on the near future. We’ll talk about details later, but the main points to consider are:

  • The overall business analysis approach: formal-detailed-long VS flexible-superficial-simple, or more waterfall-like VS agile (ideally a reasonable combo)
  • What artifacts (documents, prototypes, models, etc.) you plan to produce
  • What tasks need to be done (who, when, in what order) and the visible risks upfront
  • Who are your stakeholders, their important traits, and how you plan to interact with them to get your job done
  • How you will organize the useful information you gather and accumulate

This is not exhaustive but key. It’s important to understand: this scheme is not a waterfall (i.e., not a rigid sequence). Some might already be wondering how you can plan all this when you know nothing about the project yet. Right, you probably can’t build decent plans at this point. Plans will evolve as the information fog clears. At best, you can make rough hypotheses at the start. Then, as you gain more understanding of your place in the project, you’ll update and refine your plans. Conceptually, planning happens at the start, but a) detail and accuracy may be near zero at this stage, and b) you need to keep revising plans over time (so this stage is actually spread throughout your project activity).
The next three stages are the strategy analysis phase, aka discovery. Here, we need to understand what and why our team will do on the project overall.
Current State Analysis (AS IS) — understand what problems or opportunities led the client to request software development or any other service that brought us here (developing a new product, enhancing something existing, supporting a live system in production, etc.). This requires immersing ourselves in the client’s domain and activities.
Future State Definition (TO BE) — understand where the client (the money-payer) wants to get. Here we work out business requirements and other key details clarifying them. This is necessary to understand the overall impact the client expects from the initiative and the strategy to achieve it.
Solutions Identification and Analysis, and Definition of the Final Solution and Its Scope — here, together with the client and other key people, we think about which solution will most effectively bring us to the future state. That is, from “where” we want to go (step 3) we move to “how” we will get there. We need to decide what the development team’s focus will be (web app, mobile app, complex combo of business process improvements plus multiple software systems, enhancements to an existing system, buying and configuring an off-the-shelf product, etc.). This solution and the broad outline of its scope will guide all further steps. Scope definition can be tough to do purely with the client — you might need to check with users (next step) at least briefly.
It’s important to assess whether this whole phase is relevant for your project. Its appropriateness is often questionable. It depends on the service level your company provides, project type and your role, work already done without you, and the client’s motives. For example:
  • For a typical outsourcing developer whose job is just to implement client requests without poking into strategy, this phase might be unnecessary.

  • For a product with strategists (not you), your role might be to humbly elaborate on requirements for a solution smart people have already decided on.

  • Sometimes pre-sale has already covered this (maybe not perfectly), and you just need to deliver what was promised on schedule.

  • Even if the company and project value these activities, the client might dislike spending precious developer hours on this, expecting you to just “row” toward their brilliant vision.
In short, you must understand the context and evaluate whether this phase or its parts are appropriate. We’ll discuss this more later.
Now we move to detailed elaboration of the target solution. Sometimes the rest of the phases are broadly called delivery.
Understanding Users and Their Needs/Values of the Solution. Besides end-users, include other stakeholders who may have wishes or constraints about the solution. But about 90% of this work focuses on users. Of course, staying consistent with the “non-waterfall” principle, you’ve already somewhat understood your users before this point — for example, when discussing possible solutions and choosing one (hard to talk about solutions without knowing who they’re for and what they should deliver — i.e., scope). Here, we study users more deeply, categorize them, and clarify exactly what the solution should provide them.
Important: you won’t always have access to actual users. Sometimes a client or even your own creativity substitutes for users. This is not ideal, and you should try to reach at least some users, but circumstances vary — sometimes you must think about users without them. The stage remains necessary, but the nature of the work changes, which we’ll discuss later.
Requirements Development for the Solution. At this stage, you translate what you’ve learned about the solution’s value to users and stakeholders into specific things that must be included in the solution — both functional and non-functional. This is where you write specifications, user stories, and other key artifacts. Likely, you’ve already started this earlier because, again, this is not a waterfall. An experienced analyst documents requirements and team tasks continuously, even during previous stages.
Handoff of Requirements to Development — time to rest? Nope. Get ready to actively or passively participate in development, testing, and delivery. Questions about requirements will come — from the team, client, management, etc. Also, most development is iterative nowadays, so you’ll be working on the next iteration of the solution (to be fair, this is a new mini-waterfall starting with discovery or requirements for that iteration).
Post-release Support and Operation. After the system (or iteration) is released, your involvement doesn’t vanish. The client, users, and stakeholders will have questions: why isn’t this working right, how should it work, how can we change this because something in the business changed, etc. You help support the operational use of the solution, consulting anyone who needs help understanding it, tracking and processing change requests (when the client realizes too late that something needs changing and pays for it), and participating as a consultant or information conduit in bug fixes (when something was done wrong and the supplier pays for the fix).
Also, add evaluation of the solution — assessing whether the solution helps achieve the desired effect identified during discovery. This is often irrelevant in contract development, where “business value” assessment is out of scope. In product development, it’s more relevant but usually the product manager’s headache rather than the analyst’s. Still, various role combinations exist, so it’s worth mentioning.
This was a high-level overview of typical business analysis stages in an IT project. In future posts, I’ll explore each stage in more detail, discuss practical approaches to tasks within those stages, and highlight popular techniques and tools with links for further study.

As usual, I’m happy to receive any feedback and ideas for future posts. If you want me to focus on specific techniques or tasks — shout out!
]]> Business Analysis: Current State Analysis (AS IS) https://itmine.by/enarticles/tpost/kvalh09c51-business-analysis-current-state-analysis https://itmine.by/enarticles/tpost/kvalh09c51-business-analysis-current-state-analysis?amp=true Sat, 21 Jun 2025 19:03:00 +0300 Business analysis What studying the current situation on the client side involves, why it is important to dive into it at the start of the project, and how to do it.

Business Analysis: Current State Analysis (AS IS)

We’ll begin our business analysis journey from the second stage of the scheme mentioned in the previous article — analyzing the current situation (AS IS). Why not start with planning? Because we’ll discuss business analysis planning at the end of the cycle, after we’ve covered all the typical stages — to avoid brain overload from too much unfamiliar terminology and processes.

So, we begin our magic by studying the AS IS — that is, “how things currently are” at the client’s side (the person or organization who is ready to pay us). Why do we do this? The answer is simple: to understand the reasons why the client is willing to invest money into the project. But again, why? They’re willing, so let them pay — we wouldn’t complain. Yes, that approach works and is used by many. But let’s recall any interaction we had with sellers (not counting, say, buying bread). Wasn’t it more valuable when the seller acted as a consultant, trying to understand what and why we were looking for, attempting to solve our problem rather than just blindly selling what we came for?

In IT development, this is even more critical — IT investments are often very large. Contractors get paid significant sums for their work, and mistakes in projects, especially strategic ones, can be costly and painful for the budget. Throughout the IT project, an “analyst-helper” (who strives to solve the client’s problems) is far more valuable than an “analyst-forwarder” (someone who just passes information from the client to the development team).

Important: Recall the message from the previous article — AS IS analysis, being part of strategy analysis/discovery, is relevant only when that phase is applicable to the project. Always check with your BA lead, project manager, or any other person who can outline the scope of your responsibilities and the role of business analysis on the project. Also, pay attention to the client’s reaction to the tasks you propose or try to perform — it’s possible the client doesn’t see the point in you digging deep as a consultant and doing anything beyond direct development (just as we don’t like sellers pushing unrelated conversations when we know exactly what we want to buy).
Let’s put the goal of this stage into official language: the goal is to understand the client’s business needs and their context (the reasons, scale, impact, etc.).

Business Needs are the problems or opportunities the client has, which drive the change. Change is a term from BABOK and its Business Analysis Core Concept Model, meaning, roughly, the moves the client intends to make and is ready to finance. We, as contractors, help the client implement this change by delivering a solution that supports it.
Important points:

  1. Business needs are formulated as the needs of the client (whether an organization or an individual, depending on who approached us). These are not the needs of the market, or a specific user Bob, or other stakeholders, no matter how important they may be. It’s always the needs of the person or organization paying us.
  2. Business needs reflect the reasons behind what our team will eventually develop, improve, purchase, or configure. It’s important not to confuse client business needs with the needs of individual stakeholders. To avoid drowning in terminology, here’s an example: suppose we talk to a department head at the client’s company who struggles with controlling employee work. If we bluntly ask this person about their needs, they might give us two types of info: a) The company’s efficiency suffers due to insufficient employee control; b) The control process is inconvenient for the manager, who has to ask each employee about their daily work. The first sounds like the project’s core reason and motivation for investment, while the second is probably the manager’s personal pain, which we may also address later, but not at this stage or as a root cause of the project.
  3. Business needs are not requirements in the analyst’s information model. Requirements look to the future (TO BE) and concern the solution our team will deliver. At this stage, we’re not talking about solutions yet — it’s too early. Needs describe the current state (AS IS) and are expressed as problems or opportunities.
Examples of business needs:

  • Ivan approached us wanting a personal website with info about himself and his career achievements. His business need, expressed as a problem he currently faces and seeks to solve, might be: insufficient awareness among his target audience about Ivan and how impressive he is.
  • We have an internal automation project within our own company to develop an office lunch ordering system. The company’s business need as a client might be: loss of employee loyalty due to the lack of a convenient office dining system.
  • A brilliant startup founder came to us with an idea to develop a new social network with unique features. The startup’s business need, expressed as an opportunity, could be: generating profit through paid features for users of the new social network.
  • A non-IT example: in my business analysis course, I always try not to skip this stage and ask the client (i.e., the course buyer) about their business needs before purchase. Why do they need the course? If I get a response like “to acquire IT BA knowledge/skills for further employment as a junior BA in Belarus” (framed as an opportunity), I can confidently confirm that our online BA course is a good fit and proceed. If there are mismatches between business need and desired solution, I try to highlight that to ensure the client understands them. For example, do they only need theoretical knowledge? There’s a cheaper course focused on theory with minimal practice. Does BA mean working with data? That’s BI analytics, not analysis, and the course is not about that. Is it for mid/senior levels? Our course targets beginners, though it has some advanced features. Not in Belarus? Here are risks and variations in understanding what an IT BA is in different countries.
Now, what does it mean to “understand the context behind the needs”? It’s hardly enough when Ivan from the example above tells us simply: “insufficient awareness of the target audience about Ivan and how cool he is.” Our task later is to help Ivan develop a solution that truly solves this problem. To do that, we need to study this need thoroughly. What does Ivan do? Who is his target audience? Where are they? What do they currently know about Ivan, and as a result of what actions? Why does Ivan need greater awareness? How does he know the audience is currently unaware? What is the meaning of life?

By exploring these questions, we immerse ourselves in the client’s business. We study their business domain (subject area; often much more complex than these examples — imagine Ivan is a company providing mortgage services in Uganda), compile a glossary of domain terms, study their organization (if not an individual), its processes, architecture, technologies, policies, as well as the surrounding context (e.g., government policies in that industry).
Important: We do all this not for the sake of accumulating information itself. Studying the context is aimed at clarifying business needs, because that is our goal at this stage. Don’t blindly apply trendy Internet or BABOK techniques designed for comprehensive organizational and process analysis. In IT business analysis, our ultimate goal is to facilitate high-quality IT solution delivery. We are not business transformation specialists or consultants. Study only what clarifies business needs. Once you believe you understand them and the surrounding AS IS, stop. Study the rest only when there is a clear necessity.
Having understood what we need to get out of this stage, let’s talk about how to do it. In the previous note, I explained that the main goal of this cycle is to provide a quick start guide for working at each stage.

First, analyzing the current state is, like most analyst work, about working with information — in this case, information about the client’s business needs and their context. Working with information, if we recall and slightly extend the wisdom of our beloved Mr. Wiegers, involves: extracting it from those who hold it (or from places where it is hidden), analyzing it (removing the unnecessary, systematizing, bringing to a quality form), documenting it (if it needs to be recorded for future use — which is less often than you might think), and then verifying and managing it further (keeping it usable and up to date). We’ll touch on the main points of this below.
It’s no secret that the core task at this stage is to dig this information out of its sources — both obvious and hidden deep in minds or documents. The simplest starting point is to ask. Ask whom? Obviously, the client or their representative — for example, the contact person assigned to represent the company’s interests on this project. Usually, this is the first stakeholder we engage with.

How to ask? As analysts, we know about interviews (written, oral, face-to-face, remote), workshops, and surveys. Choose whatever suits you. Usually, the analyst starter pack is an interview with recording and a pre-sent agenda (topics list). We inform the interviewee what we’ll be asking about, then schedule and begin excavating the items mentioned earlier. Several meetings and additional communications are usually needed to complete the stage.
Example questions, in their “bare” form (no wrapping):

  • What are the reasons for starting this project?
  • What is wrong with the current situation? What opportunities do you see from the project?
  • Why do these problems occur?
  • How do the target processes work now?
  • What impact do the stated problems have?
Important tips:

1) Clearly communicate to the client why you’re doing this work — naturally, in terms of value for them and the project. I mentioned above that the client might be skeptical about such work. So, your approach should be something like:

  • We’d like to start by understanding the reasons behind the project.
  • This will help us avoid wasting your and our time in the future.
  • The better we understand the business needs and context, the more likely we are to deliver the right solution.
2) Avoid conducting such communication purely in writing. At this stage, you’re gathering a large volume of information, mostly through open-ended questions (“Tell me how your process X is organized”). The client will hardly be thrilled by the prospect of writing all this down in emails.

Like with any information elicitation, there are many tips and best practices that help do this more effectively and with less burden on the client. Let’s consider the key ones:
1) Agendas and meeting minutes (follow-ups). Don’t underestimate the usefulness of these tools. At this stage, they are especially valuable because:

  1. The client needs to clearly understand what we want from them, what we’ll be asking, and why — they will likely need to prepare for the conversation and possibly invite others.
  2. The chaos collected from open questions will need to be organized (cleaned from “noise”) and you will have to ask the client to confirm your final understanding — at this stage, it’s easy to misunderstand domain terminology and the essence of what’s happening overall because for the client this will be their first “visit to a psychotherapist,” and they might dump a sea of words on you, where you need to avoid drowning.

So, before the meeting or call, send the client an email with the following details:
  • Purpose of the meeting
  • When and where (of course, include necessary links and instructions, e.g., how to connect to the online session)
  • Duration
  • Who needs to attend (explain to the client that they may invite others if they find it helpful in the context of the discussed topics)
  • Agenda (list of discussion topics with as much detail as you think valuable to communicate in advance)
  • Accompanying materials and action plan for preparation (usually not very relevant for AS IS discussions but include if needed)

After the meeting/call, send the client an email containing (below is not a full “standard” follow-up template, just the useful core for most situations):
  • Key points from the information gathered during the meeting (filtered through your understanding and presented clearly), asking them to correct or confirm your comprehension.
  • Summary of next steps — especially if any were mentioned during the meeting (“You, client, will check with employees about…; we will start working on…; next meeting scheduled for…”) Ideally, follow the formula “who, what, when.”
2) Record the meeting. Preferably with participants’ consent. Plan in advance how you will technically do this (set up Zoom parameters, test screen recorders like Bandicam, prepare a phone recorder, etc.), how you will ask for permission to record (don’t forget to justify and “sell” this in terms of value), and what you’ll do if the answer is no. Is it worth recording? Yes, definitely, don’t skip it (both recording and reviewing afterward):

a) At this stage, the client gives you golden information. Missing a need because you had to both take notes and keep the conversation going is a poor outcome. The analyst must carefully handle information. Sometimes a single word extracted from the chaos can be a clue that leads to uncovering another need or important aspect.

b) No one likes to repeat themselves. An analyst is expected to minimize repetition. This is especially important at this stage — both because of the importance of the information for the entire project and because this is when you are still establishing your image with the client. We all miss things sometimes, but the simplest solution is to record and carefully listen later.
3) Use active listening:

a) During the meeting, guide the interviewee in the right direction: explain at the start what you want to hear (i.e., repeat what was in the agenda), and gently correct the course if you see you’re getting irrelevant information.

b) Make sure you understand the information correctly as you go: ask clarifying questions, paraphrase complex points for confirmation (“Let me try to put what you said in my own words…”; “Did I understand correctly that…?”).

c) Keep the interviewee engaged: show your own interest, sprinkle moderate emotional reactions, smile, wave.
4) Remember the information elicitation funnel (this is the process you need to go through to say you’ve truly elicited information, not just “asked and listened”):

a) Open questions: gather everything the person is willing to say on the topic (“Tell me the reasons for starting the project.”) ->

b) Closed questions: clarify unclear points and dig deeper into what you want to know (“So this affects…? What else does it affect? Who handles this process in your organization?”) ->

c) Confirm correctness of understanding: paraphrase and reflect key points back to the person (“Did I get it right that the key reason is …, but there’s also this aspect that should be considered?”) ->

d) Confirm the whole picture: summarize all obtained information in your own coherent form (“Let’s summarize: the project is driven by these three business needs: … Is that all? Anything to add?”).

Points c and d can be covered in the meeting minutes, i.e., documented in writing after the conversation.
5) Don’t forget the importance of precise terminology — glossary:

a) Whenever you encounter unknown terms or multiple/vague meanings of familiar words, ask immediately to confirm you understand the meaning they assign to them.

b) Record definitions (not necessarily during the meeting) and reflect them back to the client to confirm shared understanding. There are many cases where work went in the wrong direction because of differing interpretations of terms.
6) Try to communicate in the interviewee’s language:

Avoid overloading with IT or business analysis jargon. You can either use the terms but immediately explain what you mean, or replace them altogether with simpler words (e.g., instead of “Now we will discuss business needs underlying change and solution,” say “Let’s talk about the reasons for the project”). Generally, I recommend following the “Explain clearly and simply” approach rather than “Wrap it smartly so they see how awesome I am” — the latter has value only in very narrow cases.
7) Don’t forget to proactively provide context.
Finally, captain obvious says: everything you’ve elicited must be documented — information must not live only in your head. The final goal is to record it in your own words, i.e., not a stenography of the original chaos but reformulated and structured (organized by topics) information. Use whatever tool you like or the one used on the project for storing project information: Word or Google docs, Confluence pages, or for quick note-taking, mind maps (by the way, don’t neglect this option — it’s an excellent way to keep structured notes during discussions and afterwards). The structure of the document/page is not critically important — there is no widely accepted template for information from this stage.
You can also use two useful visual models (both for collaborative drawing during conversations and for preparing visuals afterwards, but with subsequent client confirmation):

  1. Business domain model — helps to structure and solidify understanding of the subject area.
  2. Ishikawa (fishbone) diagram — if you need to dig into the root causes of a business need. Build it combined with the “5 Whys” technique.
]]> Business Analysis: Defining the Future State (TO BE) https://itmine.by/enarticles/tpost/cfu4f28x21-business-analysis-defining-the-future-st https://itmine.by/enarticles/tpost/cfu4f28x21-business-analysis-defining-the-future-st?amp=true Sat, 21 Jun 2025 19:31:00 +0300 Business analysis How to identify the TO BE state for the client during discovery to outline the direction for the solution.

Business Analysis: Defining the Future State (TO BE)

How do you do, fellow kids.

Let’s continue diving into business analysis, and today’s topic is the next stage — defining the future state (TO BE). Logically, this follows after studying the current state (AS IS).

A quick reminder (which you can also find in the initial article of this series): we’re still working within the context of strategy analysis/discovery. This means that the future state isn’t defined in terms of “here’s the system we need to build,” but rather in terms of the client’s strategy — i.e., why and where they want to go with the project they brought to us.

Important: yes, I’m repeating myself, but it’s necessary — since this is part of discovery, this stage, just like the previous one, only makes sense when this whole phase is relevant to the project. And how do we know if it is? The BA lead, project manager, and other “big people” who can scope our work on the project will indicate this. Plus, quite often, the client themselves might hint (subtly) that we’re wasting time instead of actually working on requirements.
In essence, this is the stage where we elaborate business requirements. Sure, if you study BABOK, you’ll find a whole bunch of fancy terms you can add here: change strategy definition, gap analysis, organizational readiness assessment, resource planning, etc. But let’s keep it real and leave those advanced, rare projects to the pros — especially considering that we’re talking about a middle-of-the-road IT business analyst. Remember, the goal of this series is to provide a straightforward guide that works in most cases. For the fancy business techniques (although I doubt they fit most IT projects), that’s BABOK territory.

So, once we’ve understood the business needs and the context around them at the previous stage (i.e., we grasped the client’s “AS IS” situation with all its problems and desires), it’s time to define where exactly they want to get to. This is done in the form of business requirements, as mentioned earlier.

Business requirements are goals that serve as indicators of fulfilling the client’s business needs.

How does this work in practice? Usually, clients don’t come to us IT contractors with a bare-bones formulation of their business needs like “I have high costs on manual request processing.” Instead, clients come with a project to develop or improve something. But at this stage, it’s best to treat this proposed solution as “hypothetical.” As analysts, if we’re doing strategic analysis, we should step away from that solution and focus on studying the AS IS and defining desired outcomes from the solution.
The current stage (defining TO BE) isn’t explicitly marked here, and the diagram describes the entire strategy analysis process as a whole, but it’s useful to understand that we usually base our work on the client’s proposed solution — while keeping in mind that the outcome of discovery can be a new solution, more effective than what the client originally brought. That’s the power of business analysis at this stage.

Back to business requirements:

1) Business requirements are formulated as the client’s goals (whether an individual or an organization), for example: “Reduce client request losses by 80% within one month after the solution’s release.” So, in this text, you’ll see the term “business goal” used interchangeably with business requirement.

2) Business requirements answer the question: “Why is this solution needed in the first place (whatever it might be)?”

3) Business requirements are NOT the same as business needs. Business needs are the sources of business requirements (and therefore, in any documentation, they must be explicitly traced to each other). Business needs describe what is currently wrong (problems) or what the client would like to achieve (opportunities), for example: “I have excessive weight.” Business requirements, however, are presented as precisely formulated planned outcomes: “Lose 15 kg within 6 months.”

4) It’s better to keep business goals abstracted from specific solutions to avoid mental bias. At this stage, it’s especially important, since we still don’t have a solution — we don’t know which one the client will choose. That’s why we do this work step-by-step. Later, when the solution is chosen, we can fine-tune business goals and their parameters based on that particular solution. For example, at the end of strategic analysis, once we know what exactly we’re doing and the scope, we can clarify and supplement goals: “Reduce client request losses by 80% (after double-checking that it’s realistically achievable through the website solution we selected) within one month after releasing the MVP of the website (taking into account the time needed for promotion and adoption of that MVP with its set of features).”
5) The key indicator of a well-defined business requirement is its compliance with SMART criteria.

We’ve all heard of SMART — and even if not in the context of business analysis, probably from self-help courses where people define their points A and B, formulate SMART goals for world domination, and launch balloons into the sky. While I don’t want this article to feel like that, SMART is a useful technique for business requirements.

SMART stands for five main principles that ideally characterize business requirements:
  • S — Specific. The goal should indicate a concrete result, not an abstract phrase you can’t touch. Sometimes analysts slip here. Not “Improve efficiency,” but “Reduce process time.”
  • M — Measurable. The goal should have a clear indicator to tell at any point whether it’s achieved or not. This can be a quantitative metric or something that answers “goal met or not.” Examples: “Increase profit by 20%” or “Get the first service order.” Sometimes it’s an artificial metric invented for the goal, especially when it’s hard to quantitatively measure qualitative change: “Achieve an average customer service rating of at least 8 out of 10 over a year.” The metric can also be a range: “Reduce document processing costs by 20-40%.”
  • A — Achievable. Realistic. This means that when we hear a goal like “Make a million dollars from the product,” as analysts we should critically assess it and encourage the client to justify its feasibility, rather than blindly recording what’s said. We’re designing solutions based on goals, and what we invest in the solution should lead toward the goal, not into a dead end.
  • R — Relevant. The goal should be relevant to the business need it’s linked to. Simple: goals must flow from business needs. “Generating revenue from product sales” doesn’t directly translate into a goal like “Achieve a 5 out of 10 usability score for the app.” Indirectly, maybe, but not directly.
  • T — Time-bound. There must be a time indicator limiting the goal’s deadline. For example, “Within one month after the solution is launched.”
Important: SMART is not mandatory (especially for M, A, and T). I recommend striving for it within reason. If you hit a wall, better to let it go and just have a goal that clarifies why we’re all here. A clear example is product monetization. The client may not have a business plan or specific expectations about how much the product will earn. If they do — great. If not, you can talk it over and maybe help form something, but that effort might go nowhere if the client is okay with the investment risk themselves. “Make money on the product” — clearly understanding and keeping this goal in focus throughout the project is already much better than nothing.
So, to recap: we need to take business needs from the previous stage and transform them into business requirements here. And of course, record them somewhere, because we should document information from every stage outside of our heavily loaded brains. A typical artifact for this is the Vision and Scope document — specifically the part that corresponds to this stage of business analysis. There’s a discussion of what such an artifact contains in another article.
Important: by Vision and Scope, I don’t mean a Word document. Think of it as a collection of information from strategy analysis, maintained wherever convenient/where the team works/where the client wants. It can be a Word doc, Google doc, a set of logically connected pages in Confluence, notes in Notion, or even data in an RMS system if you’re really serious. In other words, just because we’re all Agile now doesn’t mean we skip documenting discovery outcomes in some form, and don’t use “We don’t write Vision and Scope because we do Scrum!” as an excuse to pat yourself on the back with a smoothie.
If we look at the typical contents of Vision and Scope (smart people have already suggested sections important for strategy analysis), what else can we develop at this stage besides business requirements?

It’s not always obvious when exactly to work on these next points, but let’s say: start now, and revisit them as discovery progresses (because our business analysis stages aren’t a strict waterfall).

First, there’s the concept of success metrics.

Often, business requirements alone seem insufficient to evaluate how valuable our developed solution is to the client. Besides the solution itself, there can be many factors influencing the achievement of business goals, plus business goals may be far in the future compared to the solution’s development and deployment. That’s where defining success metrics for the solution on the path to business goals helps: what indicators show that the solution is driving progress toward the business requirements over time?

I’ve already covered success metrics in another article, but here’s a quick recap. Suppose I’m the author of a business analysis course, delivering it as a solution to the client. What might be the client’s business goal? For example, “Get a job as an IT BA within six months with a salary of at least $300.” Can I, as the solution provider, be sure that the course itself will bring the client to that goal? No, of course not. Achieving such a business goal depends on other “projects” the client undertakes: actively sending resumes, taking a technical prep course, improving English to level X. There’s also external context beyond my control, such as the number of job openings. Success metrics help both the client and the solution provider (if they care) assess how well the solution contributes to achieving the business goals — so they can understand what might be wrong and adjust as needed.

For instance, I might propose a success metric: “Complete the course with a final score of at least 70%.” For me, that’s a marker that the solution is helping move toward the business goal. If this metric isn’t met, then in my opinion, the course isn’t helping achieve the original goal and something should be changed — either in the solution itself or in how it’s used.

Important: defining success metrics is not mandatory. If nothing besides the solution and context affects business requirements much, and you see no value in forcing artificial metrics, don’t suffer over it. Ask yourself and the client: are business goals enough, or would it be useful to develop additional metrics to understand how well the solution supports those goals?
Let’s now talk about business risks. Again, I’ll borrow the definition from the previously referenced article on discovery: business risks are things that might go wrong in achieving the goal, even with a working and ready-made solution. In other words, they’re factors that could negatively affect the applicability of the solution in reaching business goals.

As I’ve already mentioned, implementing the solution is rarely the only factor determining whether the goal will be achieved. So, if there’s anything else that could impact success, the next logical questions are: What exactly? And how?
For instance, in the earlier example related to training, a business risk might be: “The market could run out of business analyst vacancies,” or “Due to personal circumstances, the client might not be able to fully engage with the course to the extent necessary to achieve the defined success criteria.”

Risks might arise from market competition — for example, if competitors roll out more useful features, tipping the scales in their favor. Or from user behavior — users may resist adopting the solution. Or from regulatory changes — the government might issue a regulation that restricts something within the domain. And so on.

Important: risk isn’t just a hypothetical probability abstracted from the context. Take “The market may run out of business analyst jobs” — that might be a general possibility at any given time. But we only consider it a risk when there are actual signs pointing to it. For instance, during an IT market downturn, this could be valid. During a boom, with evident hiring activity, it’s not practical to treat it as a meaningful risk.
Here’s what needs to be done when working with business risks:

  • Document them — a table will do.
  • Try to assess the following aspects (ideally together with the client): a) Probability of the risk materializing. b) Impact on achieving business goals if it does occur. This can be done qualitatively (minor, moderate, significant) or quantitatively (e.g., on a 10-point scale).
  • For the main risks (those with the highest combination of likelihood and impact), help the client define a risk management policy. This is key — proactively managing risks adds real value.
Example risk management policies (continuing with the Course example):

Avoidance (eliminating the uncertainty causing the risk):

Let’s say there's a risk: “The client might not engage fully with the course because a month-long vacation in Hawaii was planned during the course period.” Once identified, this should be discussed with the client — this vacation could seriously impact the success criteria. A reasonable decision might be to reschedule the vacation, or at least recommend doing so.

Transference (shifting responsibility): Using the same risk, I as the provider might add a clause in the contract stating that the client won’t receive a certificate if they miss X sessions. The certificate, of course, is a defined success criterion. Whether this policy is optimal is a separate issue, but it's an available approach.

Mitigation (reducing the probability or impact of the risk): For example, “The client may not be able to participate effectively in online sessions due to poor internet.” Reducing probability: recommend the client secure a reliable internet connection with specific specs ahead of time. Reducing impact: include course session recordings in the solution and provide them to the client.

Acceptance — we acknowledge the risk and move on.
Recommendations for handling business risks:

1) Extract risks while gathering any information during the discovery phase. Pay attention to stakeholders’ wording. Phrases like “if,” or “it’s possible that,” especially when referring to things outside your team’s control, are red flags.
2) After formulating business needs and requirements (and later, the solution concept, scope, external dependencies, etc.), take a step back. Look at everything critically: what might go wrong in terms of achieving business goals? Important: for everything not directly part of the solution, remember this: as an IT business analyst, your role is to assist, not to take responsibility. In a typical IT project, unless responsibilities are narrowly defined, neither you nor your team is accountable for the business needs, goals, success criteria, or risks. Most likely, the contract will cover only the final deliverable and its characteristics — not business transformation or its outcomes. You do all this so that: a) The solution has real value, not just something the client dreamt up randomly, b) You help the client become aware of things they likely hadn’t considered before.
3) Also — this applies to any phase of analysis — always identify assumptions in the information you’re working with. These are not facts, but hypotheses, which often underpin other strategic analysis elements. An assumption is a statement you’re unsure about. It may be due to:
  • Unavailable info (e.g., the client’s SME quit and is unreachable).
  • Inherently unverifiable info (e.g., the business goal is based on a hypothesis that 15,000 users will install the app).
  • Lack of time or interest (e.g., no one wants to do market research, so you assume users need the product).

Assumptions are situational. They’re not like business goals or risks, which objectively exist — we might just not know them yet. Assumptions may or may not exist — it depends on how much information has been clarified. That’s why it’s crucial to document them: they can eventually be resolved. Periodically review and try to eliminate them.
For example, suppose the course business goal is based on the assumption that the client will begin studying within a month. But I’m unsure, because they’re hesitant. Then in the “Vision and Scope” section, I might write:

AS-1: The client will start studying within one month.

And in the business goal section, I’ll add: “See AS-1.”
How to elicit all this information:

The overall approach doesn’t differ from what we covered in the previous article. We still use standard elicitation techniques: interviews, workshops, surveys, etc. So, definitely refer to that article for tips on organizing collaborative work. Here are additions specific to this stage:

Key questions to ask the client (but present in them in a wrapped and empathetic way):

  • What is the desired outcome once the solution is implemented?
  • How will we know that the goal has been achieved?
  • When will we measure the results — what’s the timeline?
  • Would it help to define additional metrics to evaluate progress toward business goals?
  • Imagine the solution is already in place — what else could go wrong and interfere with achieving those goals?

Important: unlike in the AS IS phase — where we mostly extract information — here we’ll need to help the client develop it. We still start with inquiry, but we also need to be ready to guide, suggest, and generate ideas. Since clients often won’t have business goals, success criteria, or risks clearly defined, here’s how to help:

1) Explain why you’re doing this work:

  • It ensures you develop a solution focused on real impact.
  • It helps us maintain focus on the true purpose of the project — future decisions will be based on this.

Proactively include these explanations in your meeting agendas.

2) Blend written and verbal communication more freely at this stage. Writing often helps clarify thought and refine how you guide the client.

3) If the client is struggling, here’s how to help:

  • Provide examples of business goals, success criteria, and risks. Examples make everything more concrete.
  • Give direction: “We identified these business needs... so logically the goal should reflect whether we’ve addressed them.”
  • Offer suggestions, but do so after giving the client space to think. If they’re stuck, then step in with your ideas.
A sample (though condensed) dialogue that might happen at this stage with a client who doesn't fully grasp what's going on yet:
  • Mr. Anderson, as you’ll recall, we previously identified the reason for starting this project — what we referred to as a business need: a high rate of lost service requests. Now we’re suggesting we reframe this into concrete project goals. Here’s how that helps us: … (Here we refer to the earlier stated rationale for defining goals.) If you agree that this makes sense, do you perhaps already have some goals in mind, even if only loosely defined?

  • Nope, haven’t really thought about that, but I do get why it’s important.

  • Okay, let’s think through it together. Since we’re building off the business need, it’s logical to assume the goal — let’s call it a business requirement — is to reduce the number of lost service requests by implementing a solution. Sound good? Anything else to add?

  • Yep, agreed. We do need to eliminate those losses.

  • Awesome! Now, to make this a strong, well-defined goal, we need to attach a metric that will help us measure success, and also add a time frame. Any ideas?

  • Uhh… I guess the main point is that requests are no longer being lost…

  • Exactly! You’re on the right track, as always. Let’s dig into this: you mentioned that currently about 5% of requests are lost because they come in through too many different channels, which makes it hard to consolidate them all without error. Since we’re talking about an IT solution to manage these requests, a logical assumption is that we’ll consolidate all incoming channels — which should reduce the chance of human error. Would you agree?

  • Yep!

  • Okay, then would it be realistic to aim for zero losses — complete elimination? Or should we allow for a bit of wiggle room, since we can’t completely eliminate the human factor? Maybe reducing the loss rate to 1% is more feasible?

  • Yeah, that sounds reasonable.

  • Great. Then our final goal could be: reduce the number of lost service requests to 1% within… What kind of timeline are we looking at? Do you have any constraints or expectations on that? If not, here’s a suggestion: since this is an IT solution, there will be an adaptation period for the administrator. Would it make sense to aim for full adoption one month after launch, and then track request loss over the following month? Does that seem logical to you?

  • Makes sense, I agree.

  • Perfect. So our final goal is: reduce the number of lost service requests to 1% within two months. Now, let’s move on to so-called success criteria. These help us… (Refer to the earlier rationale for success criteria.) In the context of this particular business goal, it might seem unnecessary to define additional criteria — after all, we can just measure the goal in two months — but still, based on our logic above, one possible criterion could be: “All client-facing channels for submitting requests are fully replaced by the new system.” What do you think?

  • Yes, we’ll do that and make sure it’s working.

  • Cool. Now, let’s consider what could go wrong, even if the solution itself is solid. Will the admin be able to fully master the new IT system? How will you notify clients about the new request submission process? Could they still try calling directly? Anything else that comes to mind?

  • Yeah, the admin will definitely manage. We’ll redirect all clients to the website to submit requests. But you’re right, someone might still call directly.

  • Okay, then let’s formalize that into risk statements… (You can probably see where this is going from here.)
What can help at this stage in terms of techniques?

1) A fairly obvious technique — Business Objectives Model.

Why is it “obvious”? Essentially, it’s just a mind map that visually shows the traceability from business needs to business goals — and later, as the project progresses, to the scope elements of the solution that enable those goals. In other words, just keep in mind that this is something you can map out visually and present to stakeholders. A standard mind map works great for this.

2) Lean Canvas. This technique goes beyond just the current and previous stages, but it’s worth mentioning now. In essence, Lean Canvas covers nearly the entire discovery process, minus the definition of the solution scope. It's also conceptually simple: you bring a visual canvas with key information blocks to a workshop and collaboratively fill it out step by step. This gives you a ready-to-use framework for discussing everything mentioned earlier — in a visual and structured way.

Although “ready-to-use” might be an overstatement, as Lean Canvas is designed for mass-market products, not custom solutions. So let me clarify how to reinterpret it for broader applicability, particularly for business analysis in bespoke development contexts:

  • “Problems” should be reinterpreted (or even renamed) as “Business Needs” or “Problems/Opportunities”, rather than as user-centric issues — it’s too early in the business analysis phase to focus on user problems.
  • “Customer Segments” should be reinterpreted/renamed as “User Classes”, or better yet, “Stakeholders”. We'll discuss stakeholder analysis in the article on business analysis planning.
  • “Unique Value Proposition” can be reframed as “Stakeholder Values” — i.e., the value that the future solution will provide to each group of stakeholders. Again, this is a bit premature, since we don’t yet have a solution.
  • “Solution” — as already noted — is premature to define. That’s for later stages.
  • “Channels”, “Unfair Advantage”, “Revenue Streams”, and “Cost Structure” — all of these can be removed. They are either irrelevant or far less important in custom development projects.
  • “Key Metrics” can be renamed to “Business Goals and Success Criteria”.
  • Add new sections instead of the removed ones — sections that are relevant to strategic analysis in our context. At this stage, one such addition could be a “Business Risks” section. Other useful sections will emerge in later stages.

To reiterate: this is a conceptually simple technique. We a) identify the key information categories relevant to the discovery phase, b) organize them on a visual canvas, and c) run a workshop — one of the most effective methods for extracting requirements — to gather input from all stakeholders on these key areas.
]]> Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 1) https://itmine.by/enarticles/tpost/e4prrm4g31-software-requirements-what-they-are-type https://itmine.by/enarticles/tpost/e4prrm4g31-software-requirements-what-they-are-type?amp=true Sat, 21 Jun 2025 20:14:00 +0300 Business analysis

Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 1)

Let’s talk about requirements.

This article will, to some extent, repeat points from my earlier posts. However, I believe it’s helpful to bring everything together in a single, accessible guide — one that allows you to see the coherent big picture. The emphasis here is on how to mentally structure and gently fall in love with that picture — which, in my view, is a critically important skill for any analyst.

While the article is mostly aimed at beginners, I’m confident that even seasoned analysts will find a few gaps in their understanding to fill. Where appropriate, I’ll also include links to other posts that dive deeper into specific topics for more advanced readers.
Let’s start with the basics: Business Analysts in IT (and not just IT) work with requirements. That’s not all they do, of course, but ultimately, requirements are the central point around which their work revolves. Systems Analysts, if that role exists in your world, also work with requirements — perhaps different types (though not always), but still within the overall picture we’re going to examine. In other words, if you reduce the responsibilities of all IT analysts to a bare minimum, it boils down to this: define and deliver a high-quality set of requirements to the development team — requirements for what kind of IT solution needs to be built for the client.
If you’re not yet familiar with business analysis, here are a couple of key concepts that will appear throughout the article:
Solution — This refers to what the development team is going to deliver in the course of the project. If we’re asked to build a new piece of software, the solution is the target software system. If we’re asked to upgrade an existing product, the solution is an enhancement to system X. More broadly, the solution might be a hybrid of software, hardware, and human processes — or even something completely non-IT (if we take a broader view of business analysis). For instance, hiring new team members or implementing more efficient internal workflows on the client’s side can also be a solution. The analyst focuses on the solution (in a project, the analyst is the owner of knowledge about the solution the team needs to implement). In contrast, the project manager focuses on the project — the people building the solution, the resources, deadlines, processes, and so on.

Stakeholder — A person or group of people with related the solution. This is a simplified definition, but sufficient for our purposes. It includes the client (who’s paying for the solution), users (who will use the solution), the development team (including us, the analysts), the government or regulators, and others. The solution affects all these entities in some way, or they, in turn, influence the development and implementation of the solution.
Our first step in this journey is to understand what “requirements” are and what counts as a requirement — which is not as simple as it may seem. The full picture only starts to come into focus as you gain hands-on experience working with them. In essence, this is about defining the core scope of our work as analysts — what we need to focus on, and what areas we should approach with caution. The key thing to internalize is that “requirement” means different things in different companies and teams. This directly impacts the responsibilities of analysts, depending on how the work is structured and how roles are divided within the project team.

Let’s begin with a couple of well-known definitions of “requirement”:
BABOK: A usable representation of a need.
That’s... okay, but let’s find something a little less abstract.
IEEE 610.12-1990:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as defined in (1) or (2).
That’s more helpful. Now, let’s translate that into Human:
  1. A stakeholder has a need in the context of the project — something that helps them solve a problem or achieve a goal.
  2. Something the solution must contain, since there's a need for it.
That’s basically all you need to get started. These two aspects cover all types of requirements. And they are closely related: the second flows naturally from the first. That is, the solution must include whatever stakeholders need to ultimately be satisfied. So the core job of an analyst is simple (conceptually):
  1. Understand what all the relevant people and organizations need from the project.
  2. Ensure the solution is designed to meet those needs.
The tricky part comes in identifying the edges of what counts as a requirement. For example:
  • Are the client’s financial goals for the solution requirements?
  • Is the system’s database architecture a requirement?
  • Is the user interface a requirement?

You’ll find different answers depending on the team and context. Later I’ll present a generalized view of how these questions are typically answered — but keep in mind that teams vary in how they define and handle requirements. Where it’s relevant, I’ll point out that interpretations may differ. If you want to go deeper into this topic, I recommend reading this article — it’s aimed at those interested in advanced business analysis. For any analyst, one of the most important skills is learning to clearly identify the boundaries of the requirements space for the specific context you're in. This will help you avoid internal doubts like, “Should I even be getting involved in this?” You’ll know which parts are your job, and which are better left to other domain experts on the team.
Also, requirements are essentially about someone needing something from the solution. And it’s important to keep that idea clearly in your mind. For example:
  • A description of how the client currently works — not a requirement.
  • Business rules currently in force (from the client, industry, or government) — not requirements.

This doesn’t mean analysts shouldn’t study such information — on the contrary, it’s often essential. But that information is supporting context. It helps us formulate high-quality requirements but is not a requirement itself. Requirements are always aimed the target solution.
Let’s now explore how requirements can be classified, how to understand the different types, and why this specific structure is used.

If you’re new to this, here’s a heads-up: there’s no single universal classification that everyone agrees on. Several models exist, each with varying levels of popularity. Be prepared for the fact that a term you use might mean something slightly different elsewhere — that’s just the reality.

That said, since BABOK is the most widely recognized standard in the field of business analysis, we’ll use its classification as our base and then expand on it as needed.

According to BABOK, there are three main levels of requirements:

  1. Business Requirements
  2. Stakeholder Requirements
  3. Solution Requirements, which further split into:
  • Functional Requirements
  • Non-Functional Requirements

There’s also a related, auxiliary type: Transition Requirements. And this is also the order in which requirements are usually developed, which we’ll explore further in the following sections.
Business Requirements:

Business requirements answer the question: “Why does the customer need the solution?” The customer, in this context, is the one financing the implementation of the solution. So, we can rephrase the question as: “Why is the customer willing to pay for the solution? What’s motivating them?” It’s crucial to begin with this point because we should start any project by focusing on what’s being paid for — and on satisfying the person funding it. Everything else — other people’s needs and "nice-to-haves" — comes second.

At a minimum, business requirements are expressed as goals (commonly referred to as business goals) that the solution helps the customer achieve. In more advanced cases, a business analyst may break these down further, adding levels (more specific goals or , success criteria, and other clarifying details). However, no matter the format, the goal is to answer the fundamental question above. Figuratively, all business requirements should sound like: “The customer is willing to pay money in order to…”

Let’s look at some examples with varying focus:
You’re buying a microwave for yourself

✅ Enable food reheating.
❌ Buy a microwave.
This is a classic mistake: “implement a solution to implement a solution.” The requirement should reflect motivation, need, or the ultimate business effect — not describe a specific solution. Otherwise, we prematurely limit our analysis and miss possible alternatives (e.g., buying a gas burner, stove, or even building a campfire — all potentially valid solutions).

A mass-market product: a thermometer for extreme temperatures

✅ Earn $1,000,000 in product sales within a year.
❌ Provide the market with a unique thermometer.
This doesn’t reflect the customer’s motivation. “Provide” for what purpose? Is the customer really investing just to altruistically gift something to the market?

Software system: A web app for ordering office lunches

✅ Increase employee satisfaction with the company by 50%, as measured by a survey within six months of release.
❌ Enable office lunch ordering.
That’s a requirement of the next level — something important to users, not to the one funding development.
Each of these examples reflects the customer’s motivation to varying degrees (you as a consumer, a startup founder, or someone responsible for implementing the office food service system).
Where to look:
Technically, any stakeholder can contribute to identifying business requirements, as they may hold useful contextual knowledge. But in most cases (read: with higher probability), the core of this information lies with the customer — the person financing the project — or their appointed representative.
How to develop:
You can dive deeper into the topic here, here, and here, but let’s outline the key points:

  • The stage of business analysis aimed at defining business requirements is called Strategy Analysis or Discovery.
  • Many project teams, consciously or not, skip this stage and these types of requirements. The attitude is often: “It’s not the peasant’s job to question the lord’s motivations — he pays, and that’s enough.” Sometimes that approach is fine. Other times, it's dangerous.
  • High-quality business requirements begin with a clear understanding of the business needs of the customer. These needs eventually evolve into business requirements.
What they look like:
Business goals (ideally SMART) documented in a Vision and Scope document, or as separate pages/entries in Confluence or whatever system the analyst uses to store requirements.
What happens if you ignore them:
If the customer neglects or sloppily handles business requirements (and we shift that responsibility onto them), it’s a potential disaster: the team may build something that doesn’t actually serve the investor’s true goals — either in part or entirely. Imagine you go to a doctor and say, “I want procedure X.” You're the customer, and X is the solution you’re requesting. If the doctor doesn’t ask why you need it — doesn’t challenge your assumption — and just writes the referral, is that actually valuable? Sometimes yes, but not always. In IT, the stakes are higher: ignoring motivations can mean burning a huge budget. If analyzing customer motivations is within the scope of the provider's services, but the analyst skips it, consequences can be extremely negative. And even if the contract doesn’t give the customer grounds to complain (like the doctor example), the overall perception of the project may still be extremely poor.
Next level: stakeholder requirements. Why do these come next? Let’s think it through: to achieve the business goals, what must we do? Eventually, we realize: to meet business goals, we must deliver a solution that solves the problems of key stakeholders or aligns with their needs and expectations. For example, to earn money from a mass-market product, the product must 1) satisfy users and 2) comply with marketplace and legal requirements. This logic is consistent: to fulfill business requirements, we must fulfill stakeholder requirements.

A helpful analogy here is Impact Mapping. At the first level of the impact map, we articulate the business requirements. The second and third levels answer:
  1. Who can help or hinder goal achievement? (≈ stakeholders)
  2. How do we want to change their behavior to help achieve the goals? (≈ their requirements)
Stakeholder requirements are expressions of what individual stakeholders need from the solution. They focus on their personal needs. In practice, most stakeholder requirements are actually user requirements, as users are a major category of stakeholders (aside from the customer). Some methodologies even equate this level with “user requirements.” While that’s not necessarily wrong, keep in mind: not all stakeholders are users. In earlier examples, we had other types — marketplaces, government agencies, etc. Still, our primary focus will usually be on future users of the solution.
Stakeholder requirements describe:

  1. The tasks users should be able to accomplish with the solution.
  2. Any other expectations or conditions stakeholders may have.

The key question: “What do users and stakeholders need from the solution? What should it allow them to do, and how should it behave?” (Always keeping in mind the business goals it supports.)
At this point, it’s important to understand: stakeholder requirements are a bridge between business requirements ("what the customer wants to achieve") and solution requirements ("what the team must build"). Solution requirements (the next level) are direct derivatives of stakeholder requirements. While the stakeholder says: “I need X from the solution,” the resulting solution requirement will state: “The solution must include feature A, parameter B, property C.” Sometimes these will closely resemble the original stakeholder requirements. Other times, they’ll be more technical or detailed. Either way, stakeholder requirements are intermediate — they exist primarily to produce solution requirements. Once that happens, they serve little independent purpose.
Let’s look at some examples again:
You’re buying a microwave for yourself

You:
✅ It should heat food.
✅ It should be able to fit large dishes.
✅ It should be convenient to use.
❌ Given the auxiliary nature of stakeholder-level requirements, it may seem like it’s hard to make serious mistakes when formulating them — the main thing is to capture them as fully as possible. However, there is a general guideline: don’t descend to the level of solution requirements at this stage, and don’t talk to stakeholders in those terms. When a stakeholder says (or when you phrase a question to them like): “The solution should include…”, they’re not expressing their actual need/motivation — they’re describing what they believe the solution should contain. And it’s important to always remember that in the abstract vacuum of "designing solutions", it’s the analyst and development team who are responsible. To craft great solutions, we must understand the stakeholders’ needs and motivations.

The microwave should have a digital interface. The manufacturer might fulfill the stakeholder-level requirement “It should be convenient to use the microwave” in different ways. For example:
  1. The microwave should have a digital interface.
  2. The microwave should have a voice interface.
This is precisely why we avoid limiting ourselves or the client by prematurely describing how exactly a stakeholder-level requirement will be met. Instead, we phrase it in terms that reflect the stakeholders’ motivation, rather than the “I need X to be in the solution” mindset.

A mass-market product: a thermometer for extreme temperatures

Users:
✅ It should be able to measure temperatures ranging from -100°C to +100°C.
✅ It should be convenient to use in extreme conditions.

Client (yes, clients can also have these requirements — not answering “Why am I investing in this product?” but rather “What do I want from the solution to meet business needs?”):
✅ The thermometers should be visually branded so it’s always clear who made them.

Government:
✅ All thermometers must comply with standard X and pass certification Y.

❌ The thermometer should have a large button so that it’s easy to press while wearing gloves at the North Pole. (Here, again, we’ve prematurely dropped from stakeholder needs to the level of specifying the actual solution.)

Software system: A web app for ordering office lunches

Users (employees):
✅ I want to be able to order food during working hours.
✅ The food should be delivered to my desk.
✅ Ideally, I wouldn’t have to pay myself — the cost should be deducted from my salary.
✅ It’s important that other employees can’t see my order history.

Users (payroll department):
✅ We need to be able to access complete information about employee orders and their costs.

Development team:
✅ It should be easy to update menu prices in the system, as this will need to happen often.

❌ The system should allow exporting orders as Excel files.
❌ Access to the system must be via HTTPS. (These are again examples of dropping to the level of solution requirements prematurely.)
Where to look:
Ideally — from future users and all other relevant stakeholders. But you must realize that access to them may be limited. A client may take the stance: “Work out the solution details with me — don’t bother the end users; I know what they need.” And sometimes, like with mass-market products, it may be objectively difficult or impossible to reach end users, because the product is aimed at an open market rather than a known user base.

This is far from ideal, and the analyst should make an effort to engage real end users or their representatives. But in practice, the client may end up being the sole voice for these requirements — even if they don’t plan to use the system themselves. This carries substantial risk at this level (e.g., delivering something that doesn’t meet users’ actual needs), but isn’t necessarily catastrophic. For some projects (usually small or simple ones), it may be enough to rely solely on the client — though keep in mind they may unintentionally distort actual user needs.

How to develop:
  • Identify stakeholders as thoroughly as possible. Determine who among them may have requirements that are important to capture. Segment users into categories based on similar characteristics — for instance, by the types of tasks they’ll perform using the solution. Don’t forget indirect users (those who use the system via intermediaries) and non-human users (e.g., external software interacting with your system via API).
  • Engage identified stakeholders (not necessarily all of them — just representative and accessible ones) and extract their requirements using interviews, surveys, observation, and other techniques.
  • While gathering these requirements, use a checklist of solution-level requirements to ensure completeness. Since stakeholder requirements will eventually “evolve” into solution-level ones, it makes sense to use the latter as a checklist to avoid overlooking anything when working at this level.
  • Present user-facing stakeholder requirements in the form of User Stories or Use Cases. For example, a User Story Map can help you structure user stories, and a Use Case Diagram can visualize use cases. Prototypes (early interface mockups) can also help during discussion and validation.

What they look like:
There’s no single standard here. Since these requirements are auxiliary — they’re just a foundation for solution requirements — analysts typically store them however is most practical. Possible options:

  1. Not stored at all: stakeholder requirements are extracted, immediately converted into solution-level requirements, and only the latter are documented.
  2. Partially stored: Where relevant, stakeholder requirements are included within the context of solution requirements. This often happens naturally if User Stories or Use Cases are used, since stakeholder requirements are reflected in their phrasing or titles. Any stakeholder requirements not expressible this way are handled as in option 1.
  3. Fully stored: You maintain a separate document (e.g., “Stakeholder Requirements”) or dedicated pages in a system like Confluence, grouping stakeholder requirements by source stakeholder. This can be valuable primarily for traceability — helping future team members understand where specific solution requirements originated.

What happens if you ignore them:
You can technically skip these requirements only if, for some reason, you’re jumping straight to solution requirements — e.g., asking the client “Just tell me what should be in the solution”, or brainstorming features yourself for your own product, skipping this step entirely.

The key consequence: you end up with a product people don’t use — because it lacks essential functionality, is inconvenient, slow, etc. This, in turn, undermines business goals. Addressing user needs and aligning the solution with them is a crucial responsibility of a business analyst — and for consumer products, it’s vital to survival.

Other consequences can include missing state, industry, or development/support team requirements — all of which can be overlooked if you don’t explicitly think about such stakeholders.
Moving on to Solution Requirements.

If the analyst’s ethical mission is to bring happiness to the client (i.e. to help achieve their business goals), then the primary and most labor-intensive task is to develop a solid set of solution requirements and hand them over to the development team.

Solution requirements are essentially descriptions of what must be incorporated into the solution in order to fulfill the stakeholder requirements.

If we return to the Impact Mapping analogy, this corresponds to the fourth level of the Impact Map: “what, in terms of the solution, can or must we implement to bring about the desired behavioral change in stakeholders.” This includes features the system must provide, qualitative attributes it must exhibit, types of access it must support, and so on — in short, every aspect of what the final solution should be.
Let’s recall the definition of a “requirement”:
  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as defined in (1) or (2).
Based on what we already know, it’s easy to infer that the first point aligns with business requirements and stakeholder requirements: the client has an objective aimed at solving a problem, and stakeholders have needs and expectations.

The second point reflects the solution level. Though that definition is somewhat narrow in scope and should be expanded: “…and to implement what is described in point 1.” We don’t add things to the solution just for the sake of a contract — we do it primarily to fulfill what stakeholders truly need.

Just like other types of requirements, solution requirements are logical if you think about them. For many types of solutions — especially software (which, as IT business analysts, is our focus) — how can we fully describe what the solution must be, so that the implementers can develop it exactly as needed? We must describe its functionality (in simple terms, what it must do), as well as its supporting parameters — those that set the stage for functionality (qualitative attributes such as appearance, usability, reliability, etc.; methods of use; required certifications, and so on).

Of course, certain types of solutions (e.g., implementing a new business process) might require a different internal structure for their requirements. But since we are focused on software, those alternative schemes don’t concern us here.

Unlike stakeholder requirements, solution requirements are phrased from the point of view of the solution itself. That is, they can explicitly or implicitly start with: "The solution must include…,” or “The solution must be able to…”
Let’s start with the full picture of solution requirements. (This is a customized view — while it draws from popular theories, it includes practical nuances based on experience.)
Where to look (applies to all solution requirements):
Conceptually, there is no need to “find” them. As analysts, we already have the stakeholder requirements, and our task is to design a solution that realizes those needs. However, in practice, we do not work on these requirements in isolation from stakeholders. We'll continuously validate and specify how exactly to implement each stakeholder requirement with the same users and stakeholders we previously interviewed.
Let’s go over each subtype:

Functional Requirements – these are the backbone of solution requirements. They describe what the solution must be capable of doing for its users — in other words, how the solution, through its components and behavior, will support operations performed by users.

The key subtype here includes functional capabilities and their detailed behavioral requirements — meaning the solution is broken down into logically distinct features that address user needs, with detailed specifications of how each function should behave (as a response to user actions or other events).

Let’s go back to our examples:
You’re buying a microwave for yourself

Functional capabilities of the microwave:
1. Heating contents
1.1. Power adjustment
1.2. Time adjustment
1.3. Start/stop heating
2. Opening/closing the door

1. Heating contents:
1.3. Start/stop heating
1.3.1. The microwave must allow the user to place items inside for heating.
1.3.2. The microwave must enable the user to start and stop heating at a set power level for a specified duration.

A mass-market product: a thermometer for extreme temperatures

Functional capabilities of the thermometer:
1. Temperature measurement
2. Battery replacement
3. User settings

1. Temperature measurement:
1.1. The thermometer must have a button to initiate temperature measurement.
1.2. When the user presses this button, the thermometer must measure the ambient temperature.
1.3. Once measurement is complete, the thermometer must display the temperature on the screen.


Software system: A web app for ordering office lunches

Functional capabilities of the web application:
1) Authentication/authorization (log in and log out functionality; assigning user roles)
2) Order management (viewing, creating, editing, canceling orders; exporting orders as PDF)
3) Menu management (importing new menu from Excel; viewing menu)
4) Home page

1) Authentication/authorization:
1.1. When the user opens the system, it must display a login page where the user enters a username and password.
1.2. Upon login attempt, the system must verify:
A) That both fields are filled. If either is empty, the system must show: “Please enter your username/password.”
B) That a user account with those credentials exists. If not, it must show: “Invalid username and/or password.”
1.3. If the login is successful, the system must assign the appropriate role and redirect the user to the “Menu” page.
To be continued in Part Two.
]]> Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 2) https://itmine.by/enarticles/tpost/n279a285d1-software-requirements-what-they-are-type https://itmine.by/enarticles/tpost/n279a285d1-software-requirements-what-they-are-type?amp=true Sun, 22 Jun 2025 10:49:00 +0300 Business analysis

Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 2)

See Part One here.
Continued example for functional requirements:
❌ A common misstep here — one that’s not particularly critical and only considered a "mistake" from the perspective of a purist analyst working within a conventional, textbook framework (i.e., it may not even be a mistake for an analyst whose responsibilities shift the standard boundaries of their role) — is crossing the line between this level of requirements and the next.

But wait — you might point out — there is no “next” level, and you'd be right. So what we're actually talking about is the boundary between requirements and design specifics.
I’ve already referenced an article that explains this in detail, but here’s a summary: based on the requirements, experts from the development team will build the solution. So how do you know when you've done your job — when you've finished defining the requirements and further details fall into the domain of other experts? Put simply: once you find yourself venturing into a domain for which there is already a designated expert on the team, you're stepping beyond the requirements space and into design territory, which is outside your responsibility.

Here are a couple of anti-examples — situations where a seemingly appropriate requirement is actually incorrect in a certain context:

If the team has a UX specialist or a UI designer, the following requirement would be invalid:
❌ 1.1. When the user opens the system, the system must display a “Login” page where the user must enter a username and password to log in.

Why is this incorrect? As an analyst, you're operating in terms of “pages” and “enter” but the concept of the UI and the way users interact with the system is not your responsibility. By framing the requirement this way, you limit the specialist’s freedom to design the most appropriate interaction model.
A more appropriate formulation would be to abstract the requirement from the UI specifics and phrase it like this:
✅ 1.1. When the user opens the system, the system must provide the user with the ability to specify a username and password to authenticate with their account.

Similarly, if the team has someone responsible for system architecture or component design, and that person isn’t you, then the following examples are also problematic:
❌ When the user confirms the login, the system must check whether a exists in the database with the user's account.
❌ When the user confirms login on the frontend, the system must send a request to the backend to verify the account's validity.

At the requirements stage, we don’t yet know how the system will be implemented in terms of components. Sure, we can clarify those things with the team — but why should we, when it’s more correct to abstract the requirements from their implementation and avoid stepping outside our role?
How to develop:
  • Take the set of User Stories or Use Cases from the previous stage (i.e. what users must be able to do within the solution).
  • Use these as a basis to derive the solution’s features. This is an optional step — many analysts work just fine using the original User Stories/Use Cases as the “atomic units” into which the solution is broken down, grouping detailed behavioral requirements around them.
  • Enrich the User Stories / Use Cases / Features with a detailed description of the system’s behavior: how it reacts to user actions or other events (e.g., automated system actions triggered by timers), and make sure to cover all negative scenarios as well.
What they look like:
A collection of User Stories, Use Cases (here and here), or Features, each with detailed behavior descriptions within the Software Requirements Specification document, or within a page or section in Confluence (or any other tool the analyst uses to store requirements).
What happens if you ignore them:
It’s practically impossible to ignore or omit the functional capabilities of the solution. If you skip this part of the requirements work, you essentially fail to communicate what the solution must do — its functionality and behavior — to the development team.

In reality, this information will still get passed to the team in one form or another, assuming your project includes any kind of work on requirements at all. It might not be written down in a document — maybe it will be communicated verbally — but that still qualifies as working with requirements.
For information systems, there’s a specific subtype of functional requirements — Data Requirements. Information systems deal with, well, information (thanks, Captain!), meaning that most of their functions operate on some sort of data. Without describing that data, it’s hard to provide a comprehensive view of what a function actually does.

Most features in a software system revolve around data: viewing it, creating it, modifying it, or deleting it. This is where the CRUD(L) model comes into play — Create, Read, Update, Delete, and List — one of the most useful tools in a business analyst’s arsenal. Data requirements summarize which types of data the solution handles and describe their details: type, format, whether they’re required, and so on.

Let’s break it down with a few simplified examples.
You’re buying a microwave for yourself

This isn’t an information system, so data requirements don’t apply — unless the microwave’s software includes a component that needs to store information (like a history of heating cycles).

A mass-market product: a thermometer for extreme temperatures

Data:
1) Temperature Measurement
1.1. Measurement Date (required; format: DD/MM/YYYY)
1.2. Temperature (required; format: degrees Celsius, range: -100 to +100)

Software system: A web app for ordering office lunches

Data:
1) User Account
…
2) Daily Menu
…
3) Menu Item
…
4) Order
4.1. Order Author (required; reference to a user account)
4.2. Order Date (required; format: DD/MM/YYYY)
4.3. Dishes in the order (required; array of references to Menu Items)
4.4. Portion count per dish (required; array of positive integers)
4.5. Total cost (required; positive float with two decimal places)
How to develop:
  1. Create a context diagram for the solution, showing the data exchanged between the system and its users or external systems. Identify the information "flying around" between them.
  2. Dig into the functional features of the solution and their behavioral descriptions to extract all relevant data the system works with.
  3. Define data classes/entities and their attributes based on all collected data. For each attribute, describe key implementation-relevant details: whether it’s required, its type, format, etc.
What they look like:
A logical data model (a diagram showing entities and their relationships — more on this here and here) and a data dictionary describing each entity’s attributes. This can live inside a Software Requirements Specification (SRS) document or on dedicated pages in Confluence or any similar system used to store requirements.
What happens if you ignore them:
Not the end of the world. Data requirements are more of a supporting perspective — they help analysts refine the functional requirements and help the development team implement them correctly. The risk is that skipping them may result in lower-quality functional requirements — missing pieces, inconsistencies, ambiguities — which can then lead to scope creep, extended requirement sessions, rework, bugs, or simply more interruptions from the team seeking clarifications.
Now that we’ve fully described the system’s functions and behavior, it’s time to move into the “exciting” world of its additional aspects — Non-Functional Requirements (NFRs).

Analysts aren’t big fans of NFRs — they’re not as straightforward as functional requirements, especially when it comes to phrasing them clearly and precisely. But ignoring them can be dangerous, so let’s dive in.
Non-functional requirements are the properties or characteristics of the system — i.e., the conditions under which it must operate. In contrast to what the system should do (functional requirements), NFRs define how well it should do those things, or what qualities it should possess.

The categories of NFRs can vary depending on the type of solution. For example:

  • For a physical device, relevant NFRs may include material, shape, and so on.
  • For certain types of software, things like data integrity or installability might matter — but not for all systems.
  • Some NFRs are common across most domains, such as usability, security, and safety.

Since we’re focusing on software requirements from an IT analyst’s perspective, we’ll look at a standard classification scheme for NFRs in software systems.
Quality attributes define the qualitative characteristics of the system. In simple terms, they answer the question: How well should the system work? These characteristics can significantly affect how effectively users or stakeholders interact with the solution. For instance, a menu page could load in 10 seconds — or in 5 minutes — depending on system performance.

Quality attributes are typically divided into external and internal:

  • External quality attributes: What end users directly perceive.
  • Internal quality attributes: Important for other stakeholders, with less direct impact on user experience.

In practice, analysts usually deal with external attributes, while internal ones are often theoretical knowledge — though a thorough analyst should still at least give them some thought.

There are dozens of quality attributes (some frameworks list 40+), but here are the key ones:
External Quality Attributes:
  • Usability — How user-friendly or easy to use the system should be.
  • Performance — How fast or how much the solution performs its functions.
  • Availability / Reliability — To what extent the solution must be available or unavailable for use (time intervals, downtime, etc.), and how reliable it is.
  • Security — How well the solution protects against information leaks and unauthorized access.
  • Installability — How easy it is to get the solution up and running.
  • Safety — How safe the solution is in terms of impact on user health or property.
Internal Quality Attributes:
  • Efficiency — Although not always an external quality attribute, it's often important for end users. It concerns how efficiently the solution consumes the resources it needs to operate.
  • Portability — Not always an internal attribute either; refers to how easily the system can be moved to another operating environment.
  • Reusability — To what extent components of the solution can be reused in developing other solutions.
  • Scalability — How easily the solution adapts to increasing loads.
  • Modifiability — How easy it is to make changes to the solution’s functionality or other aspects.
  • Verifiability — How easy it is to verify that the solution works as intended.
Let’s try to formulate examples for each type:
You’re buying a microwave for yourself

Usability: The microwave handle must be designed to allow a full hand grip (preferably considering average hand size).
Performance: The microwave must accommodate containers at least 30 cm in diameter and 20 cm in height.
It must heat a dish weighing X to temperature Y at power level Z.
Availability/Reliability: The microwave must be able to operate continuously for up to 1 hour at maximum power.
Security: —
Installability: The microwave’s packaging must allow it to be unpacked by hand, without requiring any additional tools.
Safety: The microwave handle must not cause burns, regardless of the power setting or heating duration.
Efficiency: The microwave must consume no more than X units of electricity per Y time unit when operating at maximum power.
Portability: —
Reusability (for the manufacturer): The microwave handle must comply with standard X so that it can be used across the entire microwave product line.
Scalability: —
Modifiability (or more accurately, Maintainability): The heating element must comply with standard Z to simplify service and maintenance.
Verifiability: —

A mass-market product: a thermometer for extreme temperatures

Usability: The thermometer must have a 4×4 cm measurement initiation button so it can be operated while wearing protective gloves.
Performance: The thermometer must display the temperature within 3 seconds of starting the measurement.
Availability/Reliability: The thermometer must remain operational in ambient temperatures ranging from -100°C to +100°C.
Security: —
Installability: —
Safety: —
Efficiency: The thermometer must use no more than 1% of the battery charge per temperature measurement.
Portability: The thermometer must be equipped with a carrying strap.
Reusability: —
Scalability: The thermometer must support batteries of different capacities (standards X, Y, and Z).
Modifiability: —
Verifiability: —

Software system: A web app for ordering office lunches

Usability: The user must be able to access the menu within no more than 3 actions after opening the system's start page.
Performance: Page load times must not exceed 2 seconds with a local network bandwidth of ≥100 Mbps.
Availability/Reliability: The system must be available 100% of the time between 12:00 and 14:00 on working days.
Security: Only the creators of orders and users with the "Payroll Department" role must be able to view existing orders.
Installability: —
Safety: All dishes listed in the system must be labeled with potential allergy risks.
Efficiency: System data must occupy no more than 1 GB of hard disk space on the server.
Portability: —
Reusability: The authentication module must be designed as a reusable component for future corporate web applications of the client.
Scalability: The hosting environment must support up to 300 simultaneous users without requiring upgrades or migration.
Modifiability: Developers must be able to update dish prices without interrupting system operation.
Verifiability: The system must include a hidden option (not available to regular users) to test layout compatibility across various devices.

❌ Just as with functional requirements, it's better to abstract from implementation details (“how”) and focus on the value of the requirement to stakeholders (“what”). This distinction can be blurry, but in all of the following anti-examples, the logic is that it’s up to the development team experts — not the analyst — to determine whether the requirement’s proposed implementation is appropriate, especially when it falls outside the analyst’s responsibilities.
The ‘Menu’ page must be available as a first-level system menu item.
JavaScript scripts must load in under 1.5 seconds at ≥100 Mbps network speed, and image files must not exceed 1 MB in PNG format.
The system must be developed using the ultra-language ProgrammingScript2.0 to ensure maximum security against unauthorized access.
Dish prices must be stored in XML files, dynamically retrieved without requiring code recompilation.
How to develop:
  • While working with stakeholder requirements (let’s take a step back here), keep an eye out for quality-related keywords from stakeholders — things like "fast," "convenient," "reliable," "secure," etc. These often signal quality attributes and should be noted and captured along with other types of requirements.
  • It’s also a good idea to discuss quality attributes separately with stakeholders using a checklist (for example, the one above). Go through it point by point to understand how important each attribute is. Once the relevant quality parameters are selected, try to formulate concrete requirements based on them and express them in a high-quality manner — meaning the requirements should be verifiable, complete, understandable, etc.
  • Remember that quality attributes can generate functional requirements. In such cases, these also need to be detailed. For example, a security requirement like "The system must log all user actions that modify data" leads to a functional feature — logging of changes — which must be elaborated with behavioral requirements: when exactly the system should log, and what kind of records it should create.
What they look like:
If you’re working with documentation (like a Software Requirements Specification or Technical Specification), quality attributes should be grouped and listed in a dedicated section.

If you’re working with a backlog and User Stories, there are several ways to handle this:
  • For quality attributes relevant only to specific pieces of functionality, include them as acceptance criteria within those User Stories.
  • If the attribute entails a standalone task that can be completed in a short timeframe, it can be expressed as a separate User Story.
  • If you're unsure of the best approach, at the very least keep a separate list of these requirements on a dedicated page or within a knowledge base (e.g., Confluence). The team can then help determine how to translate them into backlog items.
What happens if you ignore them:
Consequences can range from minor to very significant. In small-scale projects, overlooking quality attributes rarely causes major problems. In larger or more complex projects, project parameters like time and budget may increase significantly if these requirements are discovered too late. Some quality attributes can heavily influence system architecture, and the cost of rework could be massive. In short: don’t skip these requirements. They’re worth discussing during stakeholder interviews.
The next type of NFRs: Design Constraints. These are a unique kind of requirement that, to fully grasp, your brain has to click into place. A more detailed explanation can be found here, but here’s a summary:

When external stakeholders (e.g., customers, users, regulators) or external conditions (business rules, integration requirements) dictate implementation-specific details — things like technology choices or system design — these should be considered requirements too. More precisely, they should be treated as Design Constraints — limits imposed by external conditions that affect the team’s freedom of implementation.

We’ve discussed that implementation details (UI design, architecture, tech stack, database structure) are typically within the development team's creative domain — where they’re free to make decisions based on the analyst’s requirements. However, sometimes external circumstances intrude on that freedom and dictate the "how."

For example, if a client says, “We need the database to be SQL-based because our internal expert will be maintaining it,” that’s a design constraint. As analysts, we need to be aware of this special category of requirements and make sure to document them clearly for the development team.
You’re buying a microwave for yourself

✅ The interior coating of the microwave must be made of non-toxic material — this stems from national regulations in the country where the product will be manufactured.

A mass-market product: a thermometer for extreme temperatures

You could create a similar statement here that limits the manufacturing team’s freedom. Just don’t confuse constraints with other types of requirements — constraints refer to implementation specifics, not functional or non-functional characteristics (even if dictated by external sources like regulations). Constraints are about how to implement a requirement, not what to implement.

Software system: A web app for ordering office lunches

✅ The system must be implemented in Java — because the client insists on this due to their internal team's expertise.
✅ The code must use CamelCase notation — for example, if the client plans to submit the code for government audit, which requires that convention.

❌ The most common error here is confusing team-made implementation choices with constraints. Analysts often see examples that include “implemented in Java” and assume they need to list the entire tech stack. That’s incorrect.
The development team has its own internal documentation for these decisions. It’s not the analyst’s job to dictate implementation unless external factors impose a requirement. Analysts should only document constraints that are mandated from outside and that the team must follow.
How to develop:
  • While working with stakeholder requirements, watch for signals when stakeholders cross into implementation territory — mentioning how to do something instead of what to do. Note these carefully.
  • Ask proactive questions, especially to the client, about whether there are any such constraints.
  • Clarify whether these are true constraints — investigate the reasoning and necessity. Ideally, unnecessary constraints should be challenged or removed. Once validated, document these constraints alongside other external requirements.
What they look like:
These are usually presented as a separate section in a Software Requirements Specification, or as standalone entries in Confluence or similar tools where the analyst maintains requirement documentation.
What happens if you ignore them:
In theory, design constraints can have a huge impact. For instance, if they limit the tech stack, you might need to redo all the development work.

In practice, critical constraints are usually voiced proactively by stakeholders, so missing them often leads to only minor issues. Still, many analysts tend to overlook this category entirely — and while that rarely leads to disaster, it's still best not to skip it.
To be continued in Part Three.
]]> Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 3) https://itmine.by/enarticles/tpost/zr9yxj0kv1-software-requirements-what-they-are-type https://itmine.by/enarticles/tpost/zr9yxj0kv1-software-requirements-what-they-are-type?amp=true Mon, 23 Jun 2025 09:41:00 +0300 Business analysis

Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide (Part 3)

This is the continuation of the article “Software Requirements: What They Are, Types, and Why It All Works This Way — A Detailed Guide”. See Part 2 here.
Another aspect of NFRs — External Interface Requirements.

Let’s start by recalling that an interface, in its broadest sense, is a mechanism through which a system interacts with the outside world. For example, a human being is a complex system with interfaces like eyes, mouth, ears, fingertips, and so on. Software systems, likewise, can — and typically do — have interfaces: mechanisms for communicating with other software or hardware systems, as well as with users.

The user interface (UI) is the mechanism by which a user interacts with the system. This doesn’t necessarily mean a graphical interface — it could also be a command-line interface or even a voice interface. Apart from users, software systems often communicate with other software systems, usually via APIs (Application Programming Interfaces), or with hardware devices. Hardware interfaces are encountered much less frequently in a typical analyst’s work (note: we’re not talking here about the system environment in which the solution operates — e.g., the server hosting a web application — but rather external devices the system must communicate with). For instance, maybe your software directly controls a printer or communicates with a payment terminal.

The key takeaway here is this: as analysts, we must clearly identify the external entities — software and hardware — that the solution needs to interact with in order to function, and we must describe these interactions accurately in the requirements.

It’s also important to clarify that I personally adhere to the practice of excluding UI requirements from this category. I leave only software and hardware interfaces here. The reason is that, in practice, UI is an inseparable part of functional requirements, and for our target audience, UI (if it’s part of the analyst’s responsibilities and not the domain of a separate UX designer) is deeply tied to behavioral functional requirements. Describing UI separately in some “supporting” chapter detached from system behavior would be inconvenient and uninformative.

Also, note that the level of depth and detail in this category can vary significantly depending on the team’s working style. Most often, external interface requirements include the following set of information:

  • What external interfaces exist — what other systems the solution needs to interact with.
  • What the interaction points are for each of them — for instance, all the API methods the solution must call, and the points in the functional requirements where these calls are to occur.
  • How each point of interaction works: protocols, data formats, data mapping (correspondence between internal data and external request/response formats), and any transformation logic needed. Some of this can be found in the third-party system’s documentation (e.g., most widely-used public APIs provide full descriptions online), so there’s no need to duplicate it — better to provide a link.
  • How the system should respond to errors from external systems — for example, if the API returns a “data not found” message.

In short: descriptions of third-party system interfaces themselves usually already exist — either publicly or in documentation — and the development team can study these on their own if you point them in the right direction. Your job as an analyst is to describe how these interfaces are used in your solution: when to call them, what to send in a request, what data to extract from a response, and how to handle unexpected situations.
Quick examples (very brief, since we're not writing a full specification here):
You’re buying a microwave for yourself

The microwave must be equipped with a USB port for connecting to a diagnostics system.

Software system: A web app for ordering office lunches

The system must regularly import menus from the “Cafe Menu Aggregator” web application.
The system must import data daily at 08:00 (GMT +3).
API method (see documentation at this link): GetDailyMenu
Request data:
  • Date = current date at time of call
Response data:
  • For each Meal in the response: Name (dish name), Price (dish price), Img (dish photo).
If the response code is 152 Menu not found, the system must display the message “Sorry, the menu for today is unavailable.” on the Menu page.
How to develop:
  • Build a Context Diagram to identify which external systems (other than users) interact with the solution, either by calling it or being called by it.
  • Study the documentation for each such system and define the requirements in detail using the checklist above.
What they look like:
  • Requirements detailed using the checklist above, placed in a dedicated section of the Software Requirements Specification (SRS) document.
  • Interaction points with external interfaces will also be reflected in the functional behavioral requirements (within the descriptions of relevant Features or Use Cases).
  • Alternatively, they can be documented as separate pages or entries in Confluence or any other requirements management system used by the analyst. You can also describe specific third-party system interactions directly in User Story acceptance criteria if that’s where the interaction will be implemented.
What happens if you ignore them:
If you overlook the need for integration with an external system altogether, the project scope may unexpectedly balloon — and that piece will often be one of the more complex and risky to implement.

If you under-specify the details, it usually won’t cause critical issues — the development team can cover it with some clarifying questions — but it’s not ideal.
The final category of NFRs: the “Miscellaneous” bucket.

This is a catch-all category for requirements that don’t fit neatly into any of the other NFR types we've already discussed. Given the wide variety of solution types, this category can include a lot of directions. Common types of “miscellaneous” requirements for software solutions include:

  • Operating environment requirements — in what context the system must operate or be deployed (e.g., supported browsers; specific mobile or desktop platforms and versions; server specs needed to host the system; device screen resolutions; the public URL where the system will be accessible).
  • Localization requirements — support for multiple languages, data formats, time zones, etc.
  • UI design requirements — color schemes, branding standards, etc.
You’re buying a microwave for yourself

The microwave must be red (RGB code: #E30F47) — UI design requirement
The power cord must be compatible with plug type Z — operating environment requirement

A mass-market product: a thermometer for extreme temperatures

The thermometer must be certified under standard Y before use — certification requirement
The thermometer must operate in a range of -100°C to +100°C — operating environment requirement
The thermometer must be available in “Extreme Tourism” retail stores — this could be an operating environment requirement, or interpreted as a quality attribute (Installability)

Software system: A web app for ordering office lunches

The system must function correctly in the following browsers: Google Chrome (latest version), Firefox (latest version) — operating environment requirement
The system must be accessible at: https://meals.bestsolutions.net — operating environment requirement
The interface must be available in Russian and English — localization requirement. (Note: this should generate associated functional requirements — e.g., how the user switches languages, plus all UI text in both languages.)
The visual design must comply with the corporate brand book (see description here) — UI design requirement
One last category — Transition Requirements.

This final category is often overlooked by analysts — more due to unfamiliarity than intent. Transition requirements are different from all the others in one key way: they are temporary. All the other requirements are permanent — i.e., they describe the solution for as long as it exists (unless those requirements change). Transition requirements, by contrast, describe what must be done once or periodically to successfully deploy the solution in a live environment.

Transition requirements can apply to the solution itself (e.g., a temporary feature or a one-time setup step), or to the surrounding environment (e.g., notifying users or training staff).
Common examples:
  • Migrating data from old processes into the new IT solution.
  • Training users on how to use the system.
  • Setting up user accounts and permissions for existing staff.
You’re buying a microwave for yourself

A user manual must be written for the microwave and included in the package.

Software system: A web app for ordering office lunches

User accounts must be created for all company employees.
How to develop:
  • Study typical examples of transition requirements (for example, this list).
  • Discuss with stakeholders, asking leading questions like: “Is there anything else we need to do when launching the solution to ensure it’s ready for use?”
What they look like:
Clearly formulated requirements within a dedicated section of the Vision and Scope or Software Requirements Specification document (to make sure neither you nor stakeholders forget them at go-live). Alternatively, keep these in a Confluence page or other documentation system where the analyst tracks requirements.
What happens if you ignore them:
Usually, the consequences aren’t severe. Still, just like any other requirement, skipping this category might lead to unexpected increases in project scope — e.g., discovering late in the game that someone needs to do a lot of setup work. Thankfully, these are typically low-effort tasks compared to building the core solution.
That’s all, really. I hope this article has shown how, by moving step by step — from the reasons for building the solution, to the needs of stakeholders, to what must be implemented (in terms of both functions and non-functional aspects) — we ultimately arrive at a comprehensive specification of the target solution from a requirements perspective.

This gives the client confidence that their investment is being used to build the right thing, reassures stakeholders that their needs are addressed, and gives the development team a full blueprint to build exactly what’s required.

As always, I’d love to hear your feedback — especially your thoughts on where this explanation might be unclear or incomplete. After all, this is a core responsibility of an IT business analyst.
]]> The Analyst and the Diagrams They Draw https://itmine.by/enarticles/tpost/fa4n49mea1-the-analyst-and-the-diagrams-they-draw https://itmine.by/enarticles/tpost/fa4n49mea1-the-analyst-and-the-diagrams-they-draw?amp=true Mon, 23 Jun 2025 10:05:00 +0300 Business analysis A look at why I use diagrams in my work and which ones I rely on: UML, DFD, BPMN, IDEF, and Mind Maps.

The Analyst and the Diagrams They Draw

I've written a lot about UML, and every now and then I get questions like: "Does a modern, agile, dynamic analyst really need that UML of yours?" And it made me think that it would be useful to explain why I need diagrams in my work at all, and which ones specifically. Ideally in a simple, practice-focused way.

So let’s start with why an IT business analyst needs diagrams. Aside from helping others grasp information more easily, diagrams also offer personal benefits:
  • Drawing is helpful even just for yourself. For instance, if you view a system's data as a model (with all the relationships clearly shown), you will: a) get a high-level picture much more easily, and b) likely spot gaps or mistakes. Compare that to trying to scan a block of structured text.
  • Diagrams as checklists. Many notations have built-in rules that guide your thinking. For example, if you draw a process diagram with a branching point, you realize each branch needs at least two outcomes. If you only have one, something’s wrong.

Now, does an analyst really need modeling notations? Honestly, in most day-to-day work, they feel overkill. Unless you’re expected to be a hardcore UML purist, the benefits above can be achieved with intuitive sketches. Yes, it’s true that notations increase the chances of your diagrams being correctly interpreted, but there are a few more nuances worth noting:

  • Learning notations improves freestyle. A person who’s seriously studied standard modeling approaches will draw clearer, more complete, and more accurate diagrams. And since even small errors or miscommunications in requirements can cause major issues, this skill matters. The real benefit of studying UML, BPMN, IDEF, DFD, etc. isn’t so much the rules themselves as it is learning how to model.
  • You avoid reinventing broken wheels. Over time, you build a toolkit of perspectives: use cases, architecture, algorithms, environments, data structures, flows, states, etc. This helps you choose the most effective lens for each problem. And you don’t have to invent tools from scratch every time. Once you grasp this mindset, you can forget about UML purity. Your diagrams become even more useful, because you know how to "cook" them properly before improvising.
Here’s what’s stuck in my practice and why. I've tried most popular notations, but only a few earned a place in my heart. Let me walk you through the ones I like best, how and when I use them.
UML (Unified Modeling Language)

UML is a language for drawing things related to software (in smarter words: https://shesterov.by/homeen/tpost/9fvno0z8z1-uml-and-the-it-analyst). UML includes many diagram types, most of them aimed at developers. But a few are gold for analysts dealing with requirements.

Use Case Diagram — the most analytical of diagrams. Once, "Use Case" was synonymous with IT analysis. Now we have User Stories, but Use Cases still work great when:

  • You want to quickly visualize what the system does for users and external agents.
  • You need to show this to stakeholders.
  • You document requirements via Use Cases and want a big-picture view.

They're fast and easy to draw. The benefits still hold. Compared to User Story Maps, which focus on development priorities and detailed steps, Use Case Diagrams highlight the big wins for users. Maybe I’m old-school, but I still find them incredibly helpful.
More here: https://shesterov.by/homeen/tpost/406crafae1-uml-use-case-diagram
Class Diagram — great for any structural modeling. Department hierarchy? Glossary? Sure. While not always the best fit (I prefer mind maps for many structures), Class Diagrams shine when modeling domain structures: key concepts and relationships in the problem space (see: https://shesterov.by/homeen/tpost/tlf8tf9h61-ba-techniques-explained-business-domain).
I used UML Class Diagrams for a long time — and quite successfully, I’d say — but I’ll admit that over time, mind maps started to push them out of that role. As a tree-like structure, especially when built in a tool with hotkey-based editing, mind maps are absolute fire. They’re quick, intuitive, and brutally efficient.

That said, one area where Class Diagrams still shine is data modeling. They're not the only notation that works for this, but personally, I like them best. Since we’re talking about requirements, these aren’t database schemas — we’re dealing with logical data models or similar layers of abstraction that stop well short of physical implementation. More on that here: https://shesterov.by/homeen/tpost/4067s3mrf1-uml-class-diagram
Activity Diagram. Where once flowcharts ruled the land, the Activity Diagram has taken over. It’s a more powerful, more flexible beast. This is my go-to diagram for visualizing complex processes — steps, branches, loops, and other algorithmic fun. When a process gets hairy, this is where I turn. More here: https://shesterov.by/homeen/tpost/mver50enp1-uml-activity-diagram
State Machine Diagram. It shows how something transitions between different states over its lifetime. It’s similar to an Activity Diagram but shifts focus: instead of highlighting steps in a process, it zeroes in on how an object behaves and changes over time.

I don’t use these often — not because they’re useless, but because the need to model state transitions doesn’t come up every day. But when it does, this diagram is absolutely killer. It gives you a new lens to look at the modeled object — and often uncovers a ridiculous number of gaps in both the requirements and your own understanding. More here: https://shesterov.by/homeen/tpost/upydulblp1-uml-state-machine-diagram
Sequence Diagram. This one focuses on participants and how they exchange messages, not on algorithmic flow. Personally, I’m not a big fan of using it for every little thing (like some analysts seem to be), but it’s in my toolkit nonetheless.

To me, it’s still a kind of process diagram — just one that emphasizes the “who’s talking to whom” side of things. In my flavor of business analysis, that angle is needed less often than algorithm-focused modeling. But when you do need that emphasis, Sequence Diagrams are great. More here: https://shesterov.by/homeen/tpost/lhxj61n9d1-uml-sequence-diagram
Honorable Mention: Deployment Diagram. Rarely needed, but occasionally useful for showing how software maps onto hardware.
DFD (Data Flow Diagrams)

The Context Diagram (aka DFD Level 0) is foundational. I almost always start thinking through a solution by drawing one.

For those not raised on Karl Wiegers' books: a context diagram shows the boundaries of your system (but not what’s inside — it’s a black box for now), the external agents (people, hardware, software) interacting with it, and the information exchanged. It’s incredibly useful for:

  • Defining solution boundaries (a common stumbling block for junior analysts).
  • Identifying all external actors connected to your system.
  • Serving as a launch point for future data modeling — the data flows in/out become seeds for a proper data model.
I use lower-level DFDs less frequently, but they’re still handy if you need to crack open that black box and show data flows inside the system.
BPMN (Business Process Model and Notation)

This one’s for modeling real-world processes — business processes, to be exact. It’s not meant for visualizing software logic (at least not originally).

There are four types of BPMN diagrams, but in practice, everyone uses just two: Process Diagrams and Collaboration Diagrams — they’re similar enough that folks just say “BPMN diagram” and don’t sweat the subtype. The other two are so niche they’re not worth mentioning.

Personally, I don’t love BPMN for the kind of IT analysis I do. I get why it’s valuable for analysts who are deep in business process modeling, but that’s usually the exception in IT analysis, not the rule. Sure, BPMN can show things (steps, events, branches, participants) more richly than UML Activity, but honestly? That richness often turns into overkill. Most analysts go for simpler diagrams (flowcharts, UML Activity), not more powerful ones. And since BPMN is harder to draw and slower to read, it sometimes lands poorly with stakeholders. I’ll use it to flex a little in front of stakeholders or when the project specifically requires it — but otherwise, I skip it. Still, it's good to know BPMN exists and offers a more powerful way to visualize processes when needed.
IDEF (Integration Definition)

Also a modeling notation for IT systems. Outdated, frankly — UML has replaced it in almost all use cases. Some universities still teach it, and allegedly the U.S. Department of Defense is a fan. But in practice, I see little reason to become a disciple.

That said, IDEF0 is worth mentioning. It models functions, processes, or tasks — basically anything that takes inputs and transforms them into outputs. And it gives a cool perspective that’s occasionally useful on a whiteboard.

An IDEF0 context diagram (not to be confused with a DFD context diagram) views a function as a black box with four ports:

  • Inputs (what’s processed),
  • Outputs (results),
  • Controls (what governs how it works),
  • Mechanisms (what executes it).

This lens is surprisingly insightful and quick to sketch — often highlighting stuff you might otherwise overlook.
Mind Maps

Pure fire. One of my favorite tools for visual thinking. So much so that I use dedicated software for it — because drawing diagrams usually means slow mouse-dragging, while a good mind-mapping tool is all hotkeys and blazing speed.

What I use them for:
  • Project planning (personal and work-related),
  • Checklists of all kinds,
  • Notes and summaries,
  • Knowledge bases...

Basically, anything that fits into a tree-like structure and benefits from quick, visual layout.
Fun fact: one specific analys technique actually grew out of mind mapping — Impact Mapping. More here: https://shesterov.by/homeen/tpost/m77p1kae81-impact-map-and-user-story-map-how-to-tac
So, what do I draw? Imagine this: I’ve got a whiteboard and someone standing nearby. I need to pour some non-trivial knowledge into their head, fast. That means I’ll be talking and sketching.
Here’s what I reach for:

  • If it’s a process: UML Activity Diagram (if the focus is on the algorithm), or UML Sequence Diagram (if it’s about participants and message flows).
  • If it’s structure: Mind Map (if tree format works), or UML Class Diagram (if I need boxes and relationships).
  • If it’s something else: one of the other diagrams mentioned above, or I’ll freestyle something custom.

Naturally, in this kind of quickfire setting, the diagrams won’t be UML-perfect. Arrows might point wherever, and no one will care. What matters is clarity, not formalism.

Bottom line: these diagrams — when used wisely — cover almost every situation an analyst will face when working with requirements and communicating them to the team or stakeholders. Just take a moment to ask yourself: Will the person reading this actually get it? If not, either simplify or teach. Either way, it’s a win.
]]> Business Analysis Planning, Explained the Easy Way https://itmine.by/enarticles/tpost/xmic4a5gv1-business-analysis-planning-explained-the https://itmine.by/enarticles/tpost/xmic4a5gv1-business-analysis-planning-explained-the?amp=true Mon, 23 Jun 2025 11:23:00 +0300 Business analysis Let’s break down what business analysis planning really is — and decode all that fancy BABOK lingo without the headache.

Business Analysis Planning, Explained the Easy Way

The previous post on strategy analysis, discovery, and vision and scope “in plain terms” seemed to hit the mark, so I’m going to stick to the same format and talk about something else that’s just as useful — business analysis planning: what it is, why you should care, and how to approach it.

I first heard of business analysis planning as a standalone activity through BABOK. There’s actually an entire knowledge area in BABOK (though most people just treat them as work areas) called Business Analysis Planning and Monitoring. We’ll talk a bit about how BABOK frames it, but the focus will be on a simpler, more practical take.
Business analysis planning, for a BA, is basically getting ready to do your job. Just like with any project — be it work-related or personal (and by “project” I mean anything with a unique set of steps and a goal) — it’s usually smart to pause for a second and think through what needs to be done and how to do it well. In other words, measure twice, cut once.

Now, let’s be clear: “planning” doesn’t mean spending days overthinking every detail. If you’ve set aside at least 15 minutes to think your work through — that’s already planning. Whether it’s good planning depends on what you considered and how much experience you bring into it. I can’t magically give you experience in this post, but I can offer a checklist of things worth thinking about, which should already make the whole process worth your while.

So, when do we actually plan business analysis? Naturally, at the beginning of the work (and often even before the project has been officially approved or contracted). But not only at the start. Think about how you plan personal projects. For anything more complex than a quick trip to the store, you rarely have all the input right at the beginning — sometimes, you have none at all. That’s why many people who value planning treat it as an ongoing thing: whenever you’ve got enough info to move forward with a chunk of the plan, that’s when you update it.

A good analogy: planning a vacation. At first, it’s just broad strokes. As the trip gets closer, you work out the finer details. And if you’re like me — a bit of a systems nerd — you might even review and tweak those plans while you’re on vacation.
So what does BABOK say? In BABOK version 3, there are five tasks under this knowledge area:

  1. Plan Business Analysis Approach — thinking through the overall way a BA (that’s you, or your team) will work: what needs to be done, how it’ll be done, and what the expected outcomes are.
  2. Plan Stakeholder Engagement — figuring out who your stakeholders are, what you need from them, and how you’re going to interact with them. BA work is people work, and this is a reminder of that.
  3. Plan Business Analysis Governance — yeah, sounds intense. But it’s just about defining how decisions will be made during the BA process: who’s responsible for what, and how we manage things like approvals and changes.
  4. Plan Business Analysis Information Management — deciding what kind of info you’ll work with, how you’ll capture it, organize it, share it, and so on. BA is also heavily about handling information.
  5. Identify Business Analysis Performance Improvements — this one’s more about monitoring than planning: tracking how things are going, identifying where to improve, and adjusting accordingly.
We’ll skip #5 for now since our focus here is planning. That leaves us with four key areas, and I’ll structure the checklist around those.

As with any checklist, the idea is to go through it and make sure you haven’t forgotten anything important. Some points you’ll think through in detail (if they’re really relevant to your project), others you might skim or skip (maybe they’re not so important right now, or there’s not enough info yet). The key thing is: this checklist is about what to think through during planning — not what the final deliverables or documents should be.

Let’s dive into each task one by one.
1. Plan Business Analysis Approach

1.1. Planning Approach

This is how it’s presented in BABOK, but I’d expand it a bit to: “What will our overarching approach to business analysis on the project look like?”

BABOK boils this down to a scale with two endpoints:

  • Predictive (detailed upfront planning).
  • Adaptive (less planning, more real-time adaptation).

I won’t linger here since I’ve already said a few words about it: Agile vs. Waterfall: Specifics of a Business Analyst’s Role.

The key thing to understand here is: our work heavily depends on the chosen — or imposed — business analysis approach. Tasks, processes, artifacts, required skills, and even mindset can vary drastically depending on whether you're working in a high-bureaucracy organization or a product-oriented Agile team. This planning task is about avoiding the mindset of “I just write and refine stories and nothing else,” and instead building a richer toolbox — selecting the right screwdriver for each screw.

In real life, the approach to business analysis is almost always a hybrid, not an extreme on the scale — we just tend to lean more one way or the other. The goal is not to slap a label on the analysis effort (“predictive” or “adaptive”) but to make a conscious decision about which direction to lean in — and then reflect that decision in all subsequent planning: it will affect how we document requirements, the scope of our work, our tools and systems, how deeply we do risk management, how thoroughly we study stakeholders, and so on.

(Disclaimer: all examples in this article are simplified for clarity.)
We’re working in pure Agile, so my business analysis will be heavily skewed toward adaptiveness (and I’ll keep that in mind throughout all the following planning sections).
1.2. Formality and Level of Detail of Business Analysis Deliverables

This is primarily about the “containers” of information the analyst will use to hold business analysis outputs (particularly requirements — though I’ll use “requirements” as shorthand here, full discussion here: Requirements vs. Non-Requirements: Where the Analyst Ends).

Formality means the degree of freedom in choosing templates for your artifacts. A formal artifact could be a government-standard technical specification, a rigid requirements spec, or a Vision and Scope document. Informal ones are Agile artifacts — like user stories or simplified documentation (e.g., UI prototypes with annotations).

Detail refers to both the depth and breadth of requirements. The highest level of detail means requirements that cover all behavioral nuances and system specifics. Unsurprisingly, your choices here will correlate with the approach chosen in 1.1.

In this section, we reflect on what artifacts we’ll create and whether we’ll maintain them in an up-to-date state (something worth considering separately).
We will compose an SRS using the corporate template since the contract requires a well-structured document. For behavioral requirements, we’ll stick to use cases — finer detail (like individual UI controls) isn’t needed, as the team can design excellent UIs based on usage scenarios. We’ll keep the SRS up-to-date because it will serve as a crucial knowledge base for reasons X and Y.
1.3. Business Analysis Activities

(Combining BABOK’s .3 Business Analysis Activities and .4 Timing of Business Analysis Work)

Here we map out our activities. As with section 1.1, we can focus on the near term or attempt to draft a full project-wide plan. The full version would include a list of tasks, timelines, assignees, effort estimates (note: effort ≠ duration — you may work on something for a month but only 25% of your time), dependencies (e.g., Task X can't start until Task Y is done), and expected outcomes.

If we lean predictive, just Google “Gantt chart” or ask ChatGPT about it. But even in an adaptive approach, it helps to understand — at least directionally — what we’re doing and when. It’s also often needed for estimates — for your own clarity or your PM’s peace of mind.

With a predictive approach, it’s straightforward (exhaustively plan everything years in advance, while secretly knowing it’ll never go exactly as planned). In contrast, in adaptive environments, I like how Max Dorofeev puts it:
A rational flâneur is someone who, unlike a tourist, reevaluates their route at each step based on new information. In other words, they:
  • Acknowledge they don’t know everything upfront.
  • Accept uncertainty will decrease as the project progresses.
  • Adjust plans accordingly.
...
Like an investigator who can’t lay out a full Gantt chart before starting the case, or a doctor who can't prescribe treatment before test results — trying to plan the whole project from day one is a rookie mistake. You don’t need the full plan now. At most, a couple of tasks for “today and tomorrow” is enough. A rational type will step in again soon, evaluate outcomes, and decide what’s next.
Simple task list example from Business Analysis for Dummies.
1.4. Business Analysis Risks (Identification and Analysis)

A risk is (simplified) a potential future event that could mess up your business analysis. Identification means brainstorming and outlining the list of visible risks. Analysis means evaluating their likelihood and impact — and figuring out what to do about them.

To identify risks, use a checklist of common ones (e.g., Mr. Karl’s Software Requirements has a great list in “Requirements-related risks”), and expand it as you gain more scar tissue from real-life mishaps.
In analyzing, you might rate each risk on a scale (say, 1 to 10) for:
a) likelihood,
b) impact.
Then calculate a composite risk score (e.g., by multiplying or averaging) and assign a final label: red, yellow, or green.

Finally — and this is the whole point of this section — decide what to do with the serious ones:
  • Avoid: remove the cause. (E.g., drop a feature likely to have conflicting requirements.)
  • Transfer: shift responsibility. (E.g., adopt a change management approach where requirement changes incur additional cost.)
  • Mitigate: reduce likelihood or impact. (E.g., agree in advance with the client on response times; or define that if no response comes within X days, the team proceeds with the default suggestion.)
  • Accept: do nothing.

If your risk management efforts influence other parts of the business analysis plan — you’re doing it right. That’s where the true value of risk work lies.
  • Client takes forever reviewing documents → build in buffer time when sending for review/approval.
  • Client constantly suggests new features → proactively explain prioritization and co-create a prioritization process.
  • Risk of missing key info during requirement elicitation (e.g., team of juniors) → meticulously plan meetings and define clear goals for each session.

1.5. BABOK also mentions Acceptance — getting stakeholder buy-in for all of the above. This only really applies in bureaucratic environments. In reality, we often do all this planning just for ourselves or our team — the client and other stakeholders usually don’t care about our meticulous planning. They just want results.

2. Plan Stakeholder Engagement

2.1. Perform Stakeholder Analysis

We need to:
a) Identify the stakeholders,
b) Define their roles (in the context of our analysis/change/solution),
c) Note additional relevant attributes (e.g., attitude toward the project, you, the weather; their level of influence; the benefit they get from the solution; any usage constraints, etc.).

This step should not be skipped — it’s rarely irrelevant. The key is to use every trick in your toolkit to avoid overlooking important stakeholders. Missing a critical one is a significant business analysis risk (see section 1.4).

The result should be a table listing stakeholders, their roles (e.g., client, users, SMEs, dev team and roles within it), and any useful parameters.
  • Maximilian Petrovich, client. Value: achieving business goals.
  • Sales team staff, direct users. Value: reducing manual work. Access: require VPN to the local network.
  • Payroll department, indirect users (receive reports). Value: accurate reporting. Attitude: extremely negative, irritated by system changes.
2.2. Planning Stakeholder Interactions

(Merges BABOK’s .2 Define Stakeholder Collaboration and .3 Stakeholder Communication Needs)

For each stakeholder group, think about:

  • How often and when to communicate (e.g., don’t ping your grumpy PM too often — batch questions and updates).
  • Reasons for communication (when it's necessary to approach them).
  • Their location and how it impacts communication (e.g., client in a different time zone — hello, late-night calls).
  • Communication channels and tools (e.g., email for client, walk over to devs’ desks).
  • Their preferences (ask which messenger the client likes and install it — keep the boss happy).
  • How much detail to share (e.g., give the dev team full SRS to read at night; present the client with summaries during calls).
  • Formality level (e.g., polished emails to the client; casual Slack with their employees — you’ve already shared a beer with them).

Key tool here: Communication Plan (a table summarizing the above points as needed).
Example
3. Plan Business Analysis Governance

3.1. Decision Making

At this stage, we need to think through who and how will make decisions on various business analysis-related matters:

  1. Identify the stakeholder(s) who will have the final say. Usually, it's the client, but in more complex cases, there may be multiple decision-makers for different areas. For example, we’ll go to Maximilian Petrovich to resolve conflicts between requirements from different user groups; we'll escalate communication issues with external stakeholders to PM Afanasy; and John will have the final approval on solution requirements and their priorities. The key is to ensure that a decision-maker (or a few, depending on the context) is defined — avoid ending up in a “no one wants to decide, and I have five top stakeholders with equal influence, all pulling in different directions” situation.
  2. If relevant, define how decisions will be made — by a single person, through voting, or using a more sophisticated algorithm. Rarely comes up for a typical analyst, but it’s worth keeping in mind just in case.
3.2. Change Control Process

In a more mature setup, this can include the following:

  • Process for handling change requests. For example: The author sends the request to analyst Bob → Bob performs an impact analysis → Bob passes the estimate to the development team → Bob relays the estimate to the client → Bob waits for the final decision. In an agile setup, this process could simply translate to creating a new backlog item placed according to its priority.
  • Information to include and work through in each request. For instance: author, business value, user value, project risks, and development estimate from the tech team.
  • Prioritization approach for change requests — what criteria, which techniques, and which people will be involved in prioritizing them among all others.
  • Who and how will perform the impact analysis — i.e., analyzing how a change will affect the solution. For example, if the client's interest rate formula changes, how many documents or components must be updated? Most likely, you or a designated analyst on the team will handle this. This is usually facilitated through a solid traceability system in documentation (see section 4.3).
3.3. How We Will Prioritize Requirements

Here, think through who and how will take part in prioritizing different types of requirements (business goals, scope items, quality attributes, etc.). Define the prioritization technique, the process, and its participants.
We are going to hold dedicated meetings with the client before each sprint to prioritize the current list of “wants.” Prioritization could be done by reordering backlog items accordingly.
3.4. Requirements Approval Approach

We know that approval processes can range from highly formal (literal paper signatures) to very informal (client hears it on a call, waves it off, and gives the go-ahead for development). In any case, it’s worth deciding:

  • Who the decision-maker is for different types of requirements (overlaps with section 3.1);
  • At what moments they make those decisions (e.g., during the transition to development phase, at the start of each iteration, or on an ad hoc basis as requirements are fleshed out);
  • In what format this approval takes place (e.g., emailing the specification for approval).
4. Plan Business Analysis Information Management

Let’s keep this brief and to the point — the items are fairly straightforward, but it’s crucial not to overlook them.

4.1. How Will We Organize Information (Especially Requirements)?

Here, for example, we might decide to write separate Word specifications for each solution module, plus a general spec tying them all together. Or we might choose to use Confluence, in which case we’ll define a structure and page templates for user stories.
4.2. How Detailed Should Information Be for Different Audiences?

For instance, we may define that the Vision and Scope document will outline features in broad strokes, while the specifications will be highly detailed and written in the development team’s terminology.

This point overlaps with section 1.2, and it doesn’t really matter where exactly this gets addressed, as long as it does get addressed.
4.3. How Will We Ensure Information Traceability?

What mechanisms will we use to explicitly link pieces of information?

For example, we might rely on hyperlinks in documents — each feature will explicitly reference the business requirement it supports. We’ll maintain a catalog of business rules and annotate where requirements originate from them, with references back to the parent rule.
4.4. Approach to Reusability of Information

Chances are, you won’t need to overthink this, but it’s still worth mentioning. For instance, you might recognize that it makes sense to keep a separate catalog of business rules for the client organization, as these rules may be reused across multiple projects. In that case, you’d plan to structure it accordingly and ensure analysts from various projects can contribute collaboratively.
4.5. Where Will We Store Information and How Will Access Be Managed?

For example, we’ll store specifications on Google Drive. Therefore, Bob will need to set up the infrastructure and configure version history. Editing access will be granted to analysts, while read-only access goes to the client and the development team.
4.6. Will We Bother with Requirement Attributes, and If So, Which Ones?

Requirement attributes are additional metadata about the requirement (beyond the content itself).
Here’s what we’ll track:
  • Unique ID (for epics, user stories, and quality attributes);
  • Author (which analyst added the requirement — tracked for user stories so we know who to poke if something goes wrong);
  • Priority (not written explicitly — backlog order reflects priority);
  • Source (trace link to parent requirement, business rule, or stakeholder that generated this requirement);
  • Status (e.g., draft, proposed, approved, developed, tested, met Definition of Done).
That’s pretty much it. You can document all of this in a grand “BA Plan” or “BA Approach,” jot it down in informal notes (a mind map, a Confluence section, chocolate wrapper notes, etc.), or even just keep it all in your head — plans don’t have to be written down. Think about how many “project” plans you carry around in your brain. The main thing is not to suffer for it later.

To reiterate: the key action when you first get involved in a project (and occasionally after that) is to go through each of these points like a checklist. Spend at least a few seconds on each — even just to think, “I don’t need this — I’ll skip it.”
What happens if you don’t? Is it OK for you, if...

  • “Huh, my team avoids reading the specs. Maybe I should talk to the PM... Wait, did I even consider whether the specs are clear and useful for them?”

  • “The client stopped responding... Oh no, they’re on vacation! Maybe a pre-agreed communication plan would’ve helped?”

  • “Whoa — turns out users are exporting our reports to pass them on to Finance. Crap, did we even check the format Finance needs? Guess they’re indirect users we didn’t account for.”

  • “The client just threw a ton of change requests at us. Do they even know we’re on a fixed-price contract and this won’t be done for free, overnight? No? Now what?”

  • “The client never reads the specs we send. Maybe now’s the time to ask whether they understand what they’re for, what we expect from them, and whether they’re even capable of reviewing them?”
]]> Data Requirements: Why They're Awesome and How to Work with Them (Part 1) https://itmine.by/enarticles/tpost/4f1u46lln1-data-requirements-why-theyre-awesome-and https://itmine.by/enarticles/tpost/4f1u46lln1-data-requirements-why-theyre-awesome-and?amp=true Mon, 23 Jun 2025 11:59:00 +0300 Business analysis Data requirements: their place in requirements classification, Context Diagram, CRUDL, and Logical Data Model

Data Requirements: Why They're Awesome and How to Work with Them (Part 1)

Let’s talk about an awesome and crucial thing in requirements work: data requirements. In this article, I’ll try to convincingly explain why data requirements deserve your time and attention, what can happen if you ignore them (and, conversely, what perks you get when you handle them properly), and what exactly working with these requirements entails.

A bit of context. As IT analysts, we work with information systems. And information systems work with — surprise — information. Their very essence is to allow that information to be manipulated, either autonomously or by providing users with functionality to do so (create, update, delete, view — the magic acronym CRUD that analysts have heard many times). What are data requirements? They are the requirements for the information the system must operate on.

Personally, I’m a strong believer in this approach: the more angles from which we examine requirements, the better the final system requirements will be in terms of completeness, consistency, and so on. Sure, there are times when speed trumps thoroughness. But data requirements are not the aspect I recommend sacrificing for the sake of faster delivery — and I’ll explain why shortly.

Data requirements are about looking at the target system not through the lens of its behavior or quality attributes, but rather through the lens of the information that behavior operates on.
Where do data requirements fit in requirements classifications? Most analysts are familiar with classifications by Mr. Wiegers and BABOK, and maybe have even seen the term "data requirements" mentioned — but try to recall where exactly they’re placed. Kinda hard, isn’t it? Exactly — because they're not explicitly placed anywhere. And that’s… not ideal. Let’s dig into some of the well-known theories (useful, by the way, if you're preparing for interviews): what do the big names say about data requirements?
a) The gurus (Karl Wiegers, Joy Beatty — Software Requirements, 3rd edition):

"Data requirements are not shown explicitly in this diagram. Functions manipulate data, so data requirements can appear throughout the three levels."

Honestly, I have no idea how data requirements can “appear” at all three levels of their hierarchy. Either Mr. Karl has ascended into realms inaccessible to mere mortals, or he got distracted by cat videos. What, for instance, are data requirements at the level of business requirements (i.e. business goals)? To me, data requirements only make sense at the level of solution requirements, because it's the solution that works with the data.

b) BABOK v3:

"Functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage."

That’s it — BABOK doesn’t sweat the details. It briefly mentions data requirements within functional requirements.

c) IREB:

"Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment."

Again — data requirements are part of functional requirements.
I agree with the last two sources. Since software functions operate on information, I recommend explicitly recognizing two key subtypes of functional (solution-level) requirements:
  • Behavioral requirements (what the system does)
  • Data requirements (what information the system works with)
What does it mean to work through data requirements?

It means giving them a dedicated space in your documentation, and just like with any other type of requirements — eliciting, analyzing, documenting, and managing them. I even recommend working through them in parallel with behavioral requirements, or sometimes even before. That’s because a system’s behavior often amounts to “CRUDing” the data described in these requirements.

Let me walk you through a simple process for working with data requirements, suggest a few techniques, and explore a sample case along the way.
Let’s say you’ve spoken with the client and stakeholders and defined a simple e-commerce website. Its core features:

  • A page with general store information
  • A product catalog to browse
  • The ability to place an order
We’ll skip business requirements and stakeholder (including user) requirements here, since we’ve already decided we’re at the solution requirements level (i.e. the third level in classic waterfall business analysis).
A basic analyst might now reach for familiar tools: time to write user stories, maybe use cases, or some other way to break the system down into chunks and describe their behavior.
1) What I recommend instead — and what Karl Wiegers himself recommends — is starting with a Context Diagram.

Now, the context diagram isn’t part of data requirements per se (it's more about defining the scope of the solution), but it’s a great starting point for working on them.

Mr. Wiegers offers this great insight:
"A good place to start with data requirements is with the input and output flows on the system’s context diagram. These flows represent major data elements at a high level of abstraction, which the BA can refine into details as elicitation progresses."

I won’t go into detail on how to build such a diagram — Mr. Karl covers that beautifully in his book. Let me just recap the essentials.
A context diagram shows:

  • The boundary of the system (but not its internal workings — it’s still a black box)
  • External actors (people, hardware, or software systems interacting with it directly)
  • The essence of those interactions, in terms of the information exchanged between actors and the system

It’s built using DFD (Data Flow Diagram) notation.

Let’s build such a diagram based on our example.
Note: the arrows show data, not actions. That’s why this diagram is such a great launchpad for data requirements.
2) At some point in your BA process (perhaps even now), I recommend applying the CRUDL technique, as it ties directly into data requirements.

Just a quick overview (there are many deep dives out there, for instance):

CRUDL helps assess the completeness of solution scope by analyzing operations on known data requirements:
  • Create – add a new object
  • Read – view object details
  • Update – edit object details
  • Delete – remove the object
  • List – view a list of objects (secondary but almost always necessary: you usually need to list items before reading or updating any one of them)
Let’s define two key terms here:

  • Data entities (also known as data objects or data classes): major chunks of information composed of smaller pieces.
  • Attributes: atomic pieces of information.
If something can be broken down into smaller information units — it's a data entity. You’ll find more elaborate definitions out there, but this simple one will serve us just fine.
In our context diagram, we can already identify data entities: Order, Company Info, and Product — all are clearly structured sets of data. Note: I went straight to the concept of “Product,” because a catalog is not a data entity in itself — it’s just a collection of many Products. Same with Orders — the system may have many. In some systems, you might have separate entities like “Catalog” or “Product Category” (especially if the system supports customizable catalogs), but that would go beyond our simple case.
Let’s apply CRUDL to these entities and build a table showing the typical operations we expect for each, along with basic questions to the stakeholders and the answers we received:
Now that we understand the solution scope better, let’s add this information to our initial description:

A simple e-commerce store where the key features are a general info page, browsing a product catalog, and placing orders. Admins (via a single pre-created account) can view submitted orders. They can also add/remove products from the catalog and view them.
Here we see our first undeniable benefit of working with data requirements:
By analyzing standard operations using CRUDL, we’ve significantly expanded the functional scope of the solution — plugging obvious gaps.
This is a huge win for the analyst. Had we simply gone with the initial stakeholder wording, we would have missed nearly half of the implicit (unstated) requirements.
The first key component of data requirements in our documentation — one that we should already begin developing (and later refining alongside user stories, use cases, and related artifacts) — is the Logical Data Model (LDM).

Let me clarify up front: in theory, there are more elaborate approaches where analysts are advised to develop several levels of data modeling, each with its own fancy name. But in my experience, one model has always been sufficient — what you might call a business analyst’s view of the information the solution will work with.

Since an analyst shouldn't tie requirements to specific implementations, this model is called logical — that is, independent of how things will be physically realized. The analyst (assuming they’re not a systems analyst or a part-time architect) doesn't know in advance whether a database (and what kind) will be used for storing data, or if everything will be dumped into plain old .txt files.

The logical data model shows what information the system will operate on and how this information is related. There are various notations for drawing such models (IDEF, ER, Crow’s Foot, UML). I personally prefer UML, particularly the UML Class Diagram.

How do we build such a model?

I've already covered this in more detail here and here, and below I’ll briefly walk through the key points. If at any point it feels like you need more detail or examples, I suggest checking out those links.

a) First, let’s add our data entities as rectangles (or “classes” in UML terms):
A couple of notes:

  • Why didn’t I include “Company Info”? For beginners, this might seem odd. Including it wouldn’t be a major mistake, but from experience, I know it doesn't count as dynamic data. What we care about in a system are dynamic data — information that can change over time, not through code changes but through user interaction or automated updates. “Static” data, on the other hand, is hardcoded by developers. Based on stakeholder input, “Company Info” fits this latter category. It will be fixed in the page’s code, can’t have multiple instances (we won’t ever have multiple company infos), and concepts like CRUDL (Create, Read, Update, Delete, List) don’t really apply — except for reading.

  • Why did I include “User” (which represents an admin, since customers don’t need accounts)? According to the same stakeholders, there’s only one admin account, manually set by developers. Still, after some reflection (or discussion with stakeholders), I decided it can change. Maybe not by users directly, but via direct database edits. It's quite likely that, in the future, we’ll need multiple admin accounts or will need to change login details without touching code.
b) Now let’s add relationships between entities.

Relationships show how large blocks of data (entities) relate to each other. If you’ve worked with databases, this part is straightforward. If you haven’t, try this analogy:
Imagine all this information stored in an Excel file. To display or save dynamic data, the system "looks" inside this file. Each sheet represents a data entity, and each row on a sheet is an object of this "class". For example, a “Products” sheet would contain rows for each individual product.
So, would any rows need to reference other sheets to show relationships between data? Probably yes:
  • Orders are linked to Products, since each order refers to the products purchased.
  • Users (admins) aren’t inherently linked to anything, but suppose we get a new stakeholder requirement: for audit purposes, we want to track which admin added each product. In that case, Products should be linked to Users, so we can trace back who added what.
UML lets us draw four kinds of relationships (not mandatory, but they help convey meaning — just make sure your readers understand them or that you’ve taught them):

  • Generalization (Inheritance): A child class B is a more specific version of parent class A. For example, Product (parent) and Laptop (child).
  • Aggregation and Composition: Both show whole-part relationships. If deleting the “whole” also deletes the “part,” it’s composition (strong). If not, aggregation (weak). E.g., Product (part) and Catalog (whole).
  • Association: A catch-all relation between classes. Use it when the others don’t apply. Always make associations directional and name them — otherwise, they’re vague and hard to interpret.
Let’s now draw relationships reflecting what was discussed above. Both are associations because other types don’t make sense here.
At this point, we might discover missing requirements. For example, above we introduced the idea of tracking which admin created which order. This kind of question can emerge from asking ourselves: “Should Entity A be connected to Entity B? And if yes, how?”
Time to add multiplicities. Multiplicities are notes on the ends of relationships that indicate how many objects of one class relate to another.

Read each association and ask the right questions:

1.1) How many Products can be in one Order?
Let’s say the stakeholder replies: “Five — it’s our internal limit.” So, 1 to 5. (Make a mental note that the system must not allow empty Orders.)

1.2) How many Orders can include one Product?
0 (maybe it’s never ordered) to infinite.

2.1) How many Products can one User add?
0 to infinite.

2.2) How many Users can add one Product?
Just one — a Product is added by a single User.
Let’s update the model accordingly.
Multiplicities are a great way to extract useful questions and hidden business rules. In our example, we suddenly learned there’s a five-product-per-order limit. Would you have thought of that without this exercise? I’ve seen projects fail in production due to overlooking such details.
Now let’s move to attributes.

Recall: attributes are the atomic pieces of information that define an entity. That is, what information makes up an Order, Product, or User? After some thought and stakeholder discussion, we can add attributes to our diagram. This is our final modeling step. But don’t ask stakeholders vague questions like, “What attributes should the Order have?” You’ll either lose them or annoy them. Phrase questions in human terms: “As a customer, what info do I see when viewing a product card?”

Here are the attributes (which I’ll add to the diagram) with some comments.
Product:
  • Who added — this is a linking attribute, a reference to the User who added the Product.

User:
  • Only Login and Password — no need for Role yet, as all accounts are admins.

Order:
  • Products — marked as [] to show it’s a list (i.e., multiple product references).
Don't cross the line: what makes this model logical?
As stated earlier, analysts shouldn’t tie requirements to implementation choices — we don’t yet know how information will be physically stored. Sure, as active participants in the project, we’ll eventually learn that. But at the requirement-gathering stage, it’s still a black box. And we shouldn’t make architectural or development decisions in place of those more qualified.

Some key points:
  • No IDs. You might be wondering: why no unique identifiers? If you're used to databases, this seems wrong. But from a business perspective, IDs are irrelevant — no one needs to view or input them in the system. We don’t even know if a database will be used or if it will require such keys. Let the storage designers figure that out — they’re the experts.
  • No junction tables. We’re not designing database schemas here. For example, no intermediate tables to handle many-to-many relationships — again, we don’t know if we’ll even use a relational database.
In the second part, we’ll talk about the data dictionary and how it ties into behavioral requirements.
]]> Data Requirements: Why They're Awesome and How to Work with Them (Part 2) https://itmine.by/enarticles/tpost/3lyrnsar91-data-requirements-why-theyre-awesome-and https://itmine.by/enarticles/tpost/3lyrnsar91-data-requirements-why-theyre-awesome-and?amp=true Mon, 23 Jun 2025 12:57:00 +0300 Business analysis Data Requirements: the Data Dictionary and its connection to other types of requirements.

Data Requirements: Why They're Awesome and How to Work with Them (Part 2)

In the first part, we discussed what data requirements are and where to start working with them.
4) The second key component of data requirements is the data dictionary (also called a data glossary).

In general, the data model itself would already be quite helpful both for you and the development team. But if time allows, a data dictionary becomes a fantastic addition.

The data dictionary is best presented in a table format. In this table, I recommend including the following details for each data entity:

  • Attributes (their names).
  • A description of each attribute in plain language, i.e., an explanation of what this attribute means in terms of the system’s information.
  • Is the attribute mandatory for every instance of the data entity? In other words, can the attribute be left empty? Using the Excel analogy mentioned earlier: could there be rows on the tab dedicated to this entity where the cell for this attribute is blank?
  • What is the data type of the attribute? For example, integer, floating-point number, text (either free-form or constrained to a narrower format), image, video, boolean (yes/no), enumeration (one value from a predefined set), date, etc. We will look at some of these types in the examples below.
  • Additional details: format specifics, data source, and anything else you find useful to specify.

Here is the data dictionary for our example, along with explanations of some interesting points as we go:
Required?

  • Why isn’t the Image attribute mandatory? After discussions with the stakeholders, we determined that not all Products have images if the admin does not add one when creating the Product. Naturally, this needs to be reflected in behavioral requirements: how to display a Product card without an image.

  • All other attributes cannot be empty under any circumstances: "Added by" obviously cannot be empty; "Title", "Description," and "Price" were agreed with the client to be mandatory (meaning these fields are required when creating a Product).

Data Types:

  • "Added by" is specified as a User. This is a method I like to use when referring to linking attributes. It shows that this is a reference to a User — an object of the User class.

Additional Details:
Usually, this column describes format specifics, especially those that will be important to consider in behavioral requirements.

  • For the Image attribute, the file type and maximum file size are specified. This will directly affect whether the system will allow the admin to upload that image when creating a Product. Other parameters could also be specified, such as dimensions and aspect ratios, but in this example, no such restrictions exist (meaning the system must be able to accept and properly display images of any size and ratio in the Product card).

  • "Added by" has no format specifics — it’s just a reference to the admin who created the Product.

  • For text attributes, the maximum length is indicated. This means the system will not allow entering text longer than that during Product creation. If there were no such restrictions (either from the perspective of what users are allowed to enter or how to display arbitrarily long text in lists and cards), we wouldn’t discuss or document these specifics with stakeholders.

  • A similar approach applies to the Price, which is a floating-point number. We discussed and agreed with stakeholders that the price cannot be lower than 0.01 and higher than 1000.00, and it must be entered with two decimal places. Thus, admins cannot specify a price outside this range when creating a Product. Such constraints can be relevant for numbers, dates, times, and anything that can have minimum and maximum values.
For the User entity, the attribute details are straightforward, but let’s look at the additional details:

It’s explained that these data will enter the system in a non-obvious way — that is, not entered through the system’s UI by users. A note about the data source is included so developers understand how these data should appear in the system. No other description is needed here for this example. In a more complex case, we could have specific formats for Login and Password (for instance, referring to a standard email format for Login, and a description of password requirements according to the company’s security policy).
Data Types:

  • The Payment type attribute is listed as an Enumeration. I recommend this data type when the attribute can take only one value from a predictable set of options. That is, not any number or arbitrary text, but like in our case, either Cash or Card. Naturally, from a UI perspective, this will be collected not via a text field, but through radio buttons, dropdown lists, or something similar.

  • Products — similarly to what we discussed earlier — this is a reference to Product instances, plus here an array symbol is added to indicate that there may be multiple such references.

Additional Details:

  • We noted that the Total Cost a) is calculated by the system (i.e., it’s not entered manually by users), and b) is fixed at the moment the Order is created. This is essentially the reason for defining this attribute: product prices may change after the order is created, so simply referring to the Product and its current price would not work. Also, we included the calculation formula here so it’s documented centrally.

  • For Payment Type, we described the set of allowed values, which is necessary because it is an enumeration.
Note how, by doing this work (developing the data dictionary), we also explicitly thought through and detailed many nuances: mandatory fields, format specifics, which translate into important requirements for how to collect this information in forms and how to correctly display it. Without explicit focus on the data dictionary, predicting the fate of such requirements is hard: an analyst might consider them, but it’s unclear how timely or thorough that would be — it depends on how the planets align.
Don't cross the line: like with the data model, in the data dictionary we try not to delve into technical implementation details. What this means:

a) Data types, as you may notice, are “human-readable.” For example, Text (not Char(100)) or Integer (not Int(32)). These become “technical” data types in their physical implementation, once that becomes clear.

b) Linking entities is also abstract. For example, if I were designing a relational database, I’d link Product to User by UserID. But I’m not designing a database here, and I don’t even know if there will be one or what kind of data storage and linking methods will be used.

c) Format constraints on attributes are linked to behavior, not storage. For example, a delivery address might have a max length of 200 characters because, for some reason, we don’t want users to enter more — so it’s easier to display, etc. We don’t discuss database-level limits here. Implementation concerns matter (remember feasibility), but not as input I can specify upfront — I’ll get those during requirements review with the dev team.
What else does the data dictionary provide? It’s a single source that helps keep behavioral requirements consistent. Without it, here’s what could happen: when working on the Order creation form (User Story for creating an order), I’d think “dear stakeholder, let’s figure out what the user needs to enter and how.” Later, when detailing order editing — I’d repeat the same work; when detailing how to display the order to admins — again the same process (“what useful info do we show here?”). This is a breeding ground for inconsistencies: something collected from the user might not be displayed, or vice versa; optional info entered might not be handled correctly when shown, etc.
Having a central data dictionary greatly eases this and drastically reduces such errors. You always have one place with info on whether a parameter can be empty, its type and format, how it’s calculated, and so on.
5) Although we have finished with data requirements, here’s a brief note on how I recommend considering data requirements in the context of other requirements, highlighting two key points:

a) Much of what we thought through while doing this work are business rules (or at least have business rules as their information source). What important business rules can we extract from our work above?

  • A customer can place an order for no more than 5 products at once.
  • Prices in the online store are indicated as floating-point numbers with two decimal places.
  • The maximum price of a product in the online store is 1000.00.
  • The online store accepts two types of payment: cash and card.

b) From any behavioral requirements (acceptance criteria for user stories, detailed use cases, etc.), you now need to trace back (link) to the data dictionary wherever behavior works with information. Without this, the part of our work here loses its meaning. What this means in practice:

  • Put your LDM (Logical Data Model) and data dictionary side-by-side in your documentation (for example, in the “Data Requirements” section of your SRS or on a dedicated page in your project’s Confluence).
  • When describing system behavior, reference these resources as precisely as possible so developers understand exactly what data you collect from users or display to them.
US01 Creating a Product

As an admin, I want to be able to add a product to the system so that it becomes available for customers to order.

Acceptance criteria:

1) When viewing the product list, I can open the form to add a new product.
2) To add a new product, I must specify the following parameters:

  • Name (link to the Title attribute for Product).
  • The system does not allow me to enter text longer than the maximum length (described via attribute link).
  • Description (link to the Description attribute for Product).
  • The system does not allow me to enter text longer than the maximum length (described via attribute link).
  • Price (link to the Price attribute for Product).
  • If I attempt to enter a price outside the allowed range (described via attribute link), the system will shout at me.

3) If I do not provide any of these parameters and try to add the product, the system screams.
4) I can also add an image for the product (link to the Image attribute for Product).
  • The system allows me to add images only in the specified format (described via attribute link).
  • If I attempt to add an image file exceeding the maximum size (described via attribute link), the system swears at me.
]]> Software Requirements (Karl Wiegers, Joy Beatty) — Points of Debate and How I Suggest Addressing Them https://itmine.by/enarticles/tpost/h1fuoi4ln1-software-requirements-karl-wiegers-joy-b https://itmine.by/enarticles/tpost/h1fuoi4ln1-software-requirements-karl-wiegers-joy-b?amp=true Wed, 03 Sep 2025 09:13:00 +0300 Business analysis I genuinely love this book and have great respect for its authors. However, over the years of studying it, I’ve accumulated a number of questions — and that’s what we’ll try to discuss here.

Software Requirements (Karl Wiegers, Joy Beatty) — Points of Debate and How I Suggest Addressing Them

Let’s talk about a classic by Karl Wiegers and Joy Beatty — Software Requirements, Third Edition. I genuinely value this book, its solid theoretical base, and I have great respect for the authors — I still consider it a must-read “bible” for IT analysts working with software requirements. That said, over the years I’ve developed some questions about it, mostly around the classification of requirements and artifacts. Unsurprisingly, I had many more questions about the second edition, which makes me think some of these questions may well be addressed in a future fourth edition (if it ever comes out).
Since this book is often the first touchpoint for people entering the profession, shaping their initial theoretical foundation (and since many also use its requirements templates), I think it’s useful to highlight areas where it could be clearer. To sum up my position: I strongly recommend studying this work, especially for those just starting out in IT business analysis. But if you notice the same inconsistencies I did, keep them in mind as you build your knowledge and apply it in practice. Of course, it’s possible I’ve misread the authors’ intent — if anyone spots flaws in my interpretation, I’ll gladly take the correction.

So, let’s begin.
First off: the model includes System requirements.
What’s odd is that the classification is otherwise built around the content of requirements. Business requirements explain why the solution is needed. User requirements capture what users want from it. But then, system requirements suddenly break this logic:
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware.
In other words, the model shifts to a different axis — the level of perspective on the solution. Why try to merge apples and oranges? Business, user, and other types of requirements are equally relevant whether we’re talking about a complex solution, a standalone software, or even a non-software system. A requirement can’t really be classified as either “business” or “system” within this model, because the model mixes two different dimensions:
(a) what the requirement describes, and
(b) what level of solution it targets.

In the framework we use (and advocate), we simply removed “system requirements.” The hierarchy works perfectly well without them — and it’s easier to grasp.
Another note: business rules are not requirements (the authors themselves stress this repeatedly). So should they even appear in this model without being clearly separated? In my experience, beginners who skim the diagram often assume business rules are just another type of requirement, which leads to confusion.
User requirements. If we compare this to BABOK (and the overlap between the two models is significant), BABOK uses the term Stakeholder requirements at this level — and I think that’s the better choice. Requirements at this level don’t always come from users alone. The authors themselves admit this:
Some people use the broader term “stakeholder requirements,” to acknowledge the reality that various stakeholders other than direct users will provide requirements. That is certainly true, but we focus the attention at this level on understanding what actual users need to achieve with the help of the product.
The problem is that in practice, if we stick with the term user requirements, we risk narrowing our focus and overlooking important needs. For example:
– developers may have internal requirements (the authors mention this later when discussing internal quality attributes),
– sponsors may demand things like “put our logo on the homepage,” even if they’re not users,
– regulators may impose requirements through business rules.
That’s why I recommend using Stakeholder requirements instead and treating them as such in practice (after proper stakeholder analysis to identify who to involve and why).
Data requirements. These don’t appear in the model at all. The authors note:
Data requirements are not shown explicitly in this diagram. Functions manipulate data, so data requirements can appear throughout the three levels.
But I don’t see how data requirements could exist across all three levels. What would “data requirements” at the business-requirements level even mean? Business requirements are about business objectives. To me, data requirements belong only at the solution requirements level (more on this below), since they directly specify what information the solution must handle. They should be captured in the SRS or similar artifacts that record solution requirements.
BABOK (3): functional requirements: describe the capabilities that a solution must have in terms of the behaviour and information that the solution will manage.

IREB: Functional requirements concern a result or behavior that shall be provided by a function of a system. This includes requirements for data or the interaction of a system with its environment.
I agree with both. Since functions operate on information, I think it makes sense to split functional requirements into two key groups:

– Behavioral requirements
– Data requirements
Solution requirements. This category is missing in the model, though in BABOK it’s the third level of requirements. While that’s not fatal, I find this level rather unclear in the book. The authors write:
Software requirements include three distinct levels: business requirements, user requirements, and functional requirements. In addition, every system has an assortment of nonfunctional requirements.
But why structure it this way? Why are nonfunctional requirements treated differently from functional ones? Why not just group both under a third level called Solution requirements? Why do business rules sit on the same “level” as business requirements (though they can influence all requirement types)? Why do quality attributes appear alongside user requirements (though, like FRs, they must be built into the solution)?
The BABOK model avoids this confusion: the third level is Solution requirements, which consist of FRs and NFRs. That makes it clearer, easier to align with other frameworks, and more practical for separating artifacts (e.g., an SRS that is focused on and contains both FRs and NFRs).
Business Requirements. When it comes to business requirements in the book, I see some contradictions.
The baseline definition seems clear enough:
Business requirements describe why the organization is implementing the system — the business benefits the organization hopes to achieve.
I would take it as the foundation (it also aligns with most other sources). But then comes this:
“Business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more projects to deliver a solution and the desired ultimate business outcomes. Business opportunities, business objectives, success metrics, and a vision statement make up the business requirements.
Why vision statement? A vision statement describes what our target solution will be, not why the organization needs it.
Two core elements of the business requirements are the vision and the scope.
This complicates things even further. Scope defines the content of the solution (features — functional, characteristics — non-functional, probably use cases or user stories — user reqs). Again, that’s a what, not a why.
My recommendation: keep business requirements limited to what was stated at the beginning — business opportunities, business objectives, and success metrics. A vision statement is not itself a requirement concerning the solution, but rather the definition of the target solution, which all requirements in the model are aimed at.
So it’s useful to keep in mind that not all content of the Vision & Scope document qualifies as business requirements. For example, these sections are important context but not business requirements: background (AS-IS situation), vision statement, business risks, assumptions and dependencies, scope and limitations, stakeholder profiles, project priorities.
This brings us to the section Project priorities in the Vision and Scope document. The authors write elsewhere:
So far we have been discussing requirements that describe properties of a software system to be built. Let’s call those product requirements. Projects certainly do have other expectations and deliverables that are not a part of the software the team implements, but that are necessary to the successful completion of the project as a whole. These are project requirements but not product requirements.
I understand the idea of overlapping domains, but I prefer keeping the theory as simple as possible at the outset, with clear boundaries:
– Analysts focus on the solution (product requirements).
– Project managers focus on the project (project requirements).
Which is why I find it odd that the Vision and Scope document (supposed to focus on the solution) suddenly includes project priorities:
…five dimensions of features, quality, schedule, cost, and staff.
Except for “features” (solution scope), the rest are clearly project parameters. Operating them requires project-management knowledge and skills. So I would leave this out of the analyst’s scope of responsibility and their artifacts. In my opinion examples like this belong in the project domain, not business analysis:
– Budget overrun up to 15% acceptable without sponsor review
– Team size is half-time project manager, half-time BA, 3 developers, and 1 tester; additional developer and
half-time tester available if necessary
Transition Requirements. I actually like the concept of transition requirements and see them as necessary. Unfortunately, the authors mention them only briefly. For example, in the SRS “Other requirements” section:
Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
BABOK treats transition requirements as a distinct category, which I think is the right choice. Forgetting about them can be risky.
Closely related is the Deployment Considerations section of the Vision and Scope document:
Summarize the information and activities that are needed to ensure an effective deployment of the solution into its operating environment.
This is a bit unexpected. Earlier, in their discussion of project requirements, the authors list:
Project requirements include...

  • Infrastructure changes needed in the operating environment.
  • Requirements and procedures for releasing the product, installing it in the operating environment, configuring it, and testing the installation.
...

This book does not address these sorts of project requirements further. That doesn’t mean that they aren’t important, just that they are out of scope for our focus on software product requirements development and management.
So why do deployment considerations appear in Vision and Scope? The only way I can reconcile this is if Vision and Scope is intended as a hybrid document, mixing solution and project content.
My recommendation: treat this section as transition requirements instead. That said, I suggest distinguishing between:

– Transition requirements: additional temporary activities/measures needed so the delivered and deployed solution (with its FRs and NFRs) actually provides business/user value. Examples: user training, data migration, user notifications, account creation.
– Project work for delivering the solution: activities inherent to the development/deployment process of the solution with its FRs and NFRs (coding, builds, testing, server setup, production rollout).

The first group is definitely within the analyst’s scope. The second — not so much in my opinion.
Background vs. Business Opportunity. Another minor detail in Vision and Scope: the split between Background and Business Opportunity.
Background: Summarize the rationale and context for the new product or for changes to be made to an existing one. Describe the history or situation that led to the decision to build this product.

Business Opportunity: ....describe the business problem that is being solved or the process being improved...
...describe the business opportunity that exists and the market in which the product will be competing...
Describe the problems that cannot currently be solved without the envisioned solution.
To me, the difference is unclear. I prefer the BABOK concept of Business Need — which may be a problem or an opportunity. Business needs lead to business requirements. They are both part of analyzing the current state (AS-IS) and describe what’s wrong or what improvements are desired. That’s enough; we don’t need two separate sections with overlapping content.
Gaps in the Requirement Types Model. The book’s model of requirement types is strong overall, but when comparing it to actual requirement artifacts, I see mismatches.
Take the SRS Operating Environment section. It’s very important. But what type of requirements are they? If we read "The COS shall operate correctly with the following web browsers: Windows Internet Explorer versions 7, 8, and 9; Firefox versions 12 through 26; Google Chrome (all versions); and Apple Safari versions 4.0 through 8.0". — that is clearly a requirement. Yet it doesn’t map cleanly to the model.
My suggestion: add a “Miscellaneous NFRs” bucket — for all non-functional aspects that don’t fit under quality attributes, external interfaces, or constraints. This would cover operating environment requirements, internationalization/localization (which is also a section in the SRS that doesn't directly map to the requirements types model), and other case-specific items.
Following on that, the book also has an [Other requirements] placeholder for the SRS, with examples like legal/regulatory compliance, installation and startup requirements, logging and monitoring, and so on.
And while I understand that any model is, by definition, imperfect, why not still leave room for such requirements under the label "Miscellaneous NFRs"? We have either FRs or NFRs — these are the only categories for software content. That way, there won’t be any difficulties aligning the model with the artifacts described above.
Finally, a few words about the Characteristics of Excellent Requirements. The set of “qualities” is excellent. However, there are no explanations regarding the limitations of their applicability across different types of requirements. And, as I see it, such limitations do exist.
Let’s dig in (and for those who don’t want to read everything — you can jump straight to the green marker).
In an ideal world, every individual business, user, functional, and nonfunctional requirement would exhibit the qualities described in the following sections.
Complete — I agree, but: the authors focus on presenting user requirements using use cases, user stories, and event-response tables. At the same time, if we go back to the idea that user requirements should be expanded to stakeholder requirements (and, as the authors briefly mention, include descriptions of product attributes or characteristics important to user satisfaction), questions arise.

In my understanding, user/stakeholder requirements are the initial “wants” (often rough), which are later refined by the analyst into solution requirements (FRs and NFRs). And the term “rough” implies that before being analyzed and transformed into solution requirements, these user requirements cannot be considered high-quality.

Example of a user requirement: The system should allow ordering food during working hours (for an employee food-ordering system). When refined into FRs/NFRs, this becomes, for example, a use case “Order Food”, detailed internally with FRs. But is the original user requirement “complete”? It’s hard for me to say.
Correct — agreed, this is relevant for any requirement and, more generally, for any information handled by an analyst.
Feasible (The requirement can be implemented given the known system capabilities, operational environment, and within project time, budget, and resource constraints). Does this apply to business requirements? According to the ideal “from problems to solution” process, at the stage of developing business requirements, we don’t yet know what our final solution will be. How can a business goal be technically feasible if we don’t know what we are going to build? By the way, for goals, there is the SMART framework, which includes Achievable (for the client within the current business context), which is closer to the truth.

Also, can we assess the feasibility of user requirements? For example, “I want the system to be fast.” Only after it’s refined into an NFR does it become something like “Page load time should not exceed 2 seconds with a local network bandwidth of ≥ 100 Mbps.”
Necessary — applicable to all types of requirements. Business requirements must correspond to the business needs they address, stakeholder requirements must align with business requirements and stakeholder needs, and solution requirements must meet stakeholder requirements.
Prioritized — this is a slightly different issue. There is undeniable value in prioritizing business requirements; it’s also might be relevant for stakeholder requirements. But hardly anyone does something like:
Assign an implementation priority to each functional requirement...
Every acceptance criterion in a user story or every system step in a use case (or any other format describing system behavior) is a functional requirement. Who would bother prioritizing every step for all use cases, and why? Why prioritize design constraints if they just need to be followed? Therefore, a note is needed: each team decides what constitutes a work unit (or backlog item in Agile terms) that should be prioritized (e.g., scope units like features, use cases, user stories or quality attributes).
Unambiguous — again, I agree this is useful for any type of information. But I will refer again to user/stakeholder requirements — these “wants” only gain “quality” when transformed by an analyst into solution requirements (FRs and NFRs).
Verifiable (Can a tester develop tests or apply other techniques to determine whether each requirement has actually been implemented in the product?) Testers are unlikely to verify the achievement of business objectives, and checking raw user-level “wants” (e.g., “I want the system to be fast”) is also questionable. Testers will verify solution requirements.
How I would summarize:

  • For business requirements, the SMART acronym is excellent — we can take it as the “ideal set of qualities” for this type of requirement.
  • For stakeholder requirements (including user requirements): on one hand, they don’t need high quality if we treat them as raw material and input for solution requirements. On the other hand, the portion formatted as use cases or user stories can be checked against specific quality parameters: for user stories, there’s INVEST; for use cases, I haven’t seen a catchy mnemonic, but classical recommendations exist on how to identify and describe them.
  • For solution requirements (FRs and NFRs), the checklist above works, but with caveats. Prioritization is a good example.
Conclusion:

I hope the points I listed above help to internalize the theory from this excellent book and apply it in practice with minor adjustments.
In any case, Software Requirements is an enormous and amazing work. Many thanks to Karl Wiegers and Joy Beatty for it!
]]> Lean Canvas, Feature Canvas, and Other Canvases — Concept, Applicability for IT Analysts, and Practical Tips https://itmine.by/enarticles/tpost/ni4kdnkij1-lean-canvas-feature-canvas-and-other-can https://itmine.by/enarticles/tpost/ni4kdnkij1-lean-canvas-feature-canvas-and-other-can?amp=true Sun, 22 Mar 2026 21:31:00 +0300 Business analysis Today we’re going to talk about canvases, with a particular focus on how to squeeze as much value as possible out of them if you’re a business analyst.

Lean Canvas, Feature Canvas, and Other Canvases — Concept, Applicability for IT Analysts, and Practical Tips

Today we’re going to talk about canvases, with a particular focus on how to squeeze as much value as possible out of them if you’re a business analyst. We’ll touch on the Business Model Canvas, Lean Canvas, Feature Canvas, Value Proposition Canvas, and even come up with our own Canvas. We’ll see that all canvases are conceptually similar — you just need to understand how to cook them properly, while the semantic variations are not that significant.

Where did they come from in the first place? A bit of archaeology tells us the following.

The ideas behind the first canvas (Business Model Canvas) were introduced in the book Business Model Generation (Alexander Osterwalder, Yves Pigneur), where the authors identified nine key elements of any business model and showed how to describe them on a single page. And to do it in a way that is simple, fast, visual, and collaborative. It’s easy to notice that these are exactly the principles underlying all canvases.

We won’t go into a detailed breakdown of the BMC with all the nuances and block-by-block advice from the authors, because this canvas is easy to google. However, we will list the blocks:
  1. Customer Segments — customers for whom the company creates value.
  2. Value Propositions — the products and services into which the company embeds that value.
  3. Channels — how we deliver value to customers.
  4. Customer Relationships — how we maintain relationships with customers.
  5. Revenue Streams — sources of income.
  6. Key Resources — the company’s key assets.
  7. Key Activities — the main actions/processes required to implement the model.
  8. Key Partnerships — partners and suppliers.
  9. Cost Structure — expense categories.
The visual nature of canvases was already baked in at this point: the authors recommended using a board, sticking notes on it, and generally treating the canvas as a living artifact for collaborative work.

In 2010, Ash Maurya created the Lean Canvas based on the BMC. The original idea was to apply the concept of a visual one-page canvas to startup product development (while preserving speed, simplicity, and visual collaboration). Naturally, the sections became somewhat different:
  1. Problem — customer problems that we solve. You can also add Existing Alternatives — how people currently solve these problems.
  2. Customer Segments — customer segments. You can also also include Early Adopters — segments actively looking for solutions and willing to try something new.
  3. Unique Value Proposition — what is unique about the value the startup is ready to offer customers.
  4. Solution — solutions for each problem.
  5. Channels — customer acquisition channels.
  6. Revenue Streams — how we will make money.
  7. Cost Structure — cost categories.
  8. Key Metrics — metrics that will help measure product success.
  9. Unfair Advantage — things that competitors will find difficult to copy.
What about the out-of-the-box applicability of these two canvases for IT analysts?

In my view and based on personal experience, the Business Model Canvas is not very often useful for an IT analyst. In some situations where the business model needs to be understood (for example, we have absolutely no clue how the client’s company operates and we need to study it to better understand the context for the target solution), it can make sense to fill it out together with the client to understand their organization. Similarly, if the stars align in such a way that we are implementing a product for a client that will significantly affect how the organization operates (for example, the organization will be built around that product), and we are the analysts allowed to actively participate at that level of strategy, then we can create a similar canvas for the TO BE situation as well.

The Lean Canvas in its original form is also not always useful for an analyst — specifically, only if you are an analyst developing your own product or working in outsourcing with a startup-oriented product from a client, and you are actively involved in generating its initial concept. That is, this is discovery / strategy analysis in the context of a building a product from scratch. I’ve used it much more often than the BMC, but not exactly in the form in which it was originally designed — we’ll talk about that below.
Canvas evolution didn’t stop with these two examples. Another one appeared: the Feature Canvas. A Feature Canvas is essentially a discussion of a product feature before it is developed.

There are many variations of the Feature Canvas, and here is one of them. All the sections in the template are fairly self-explanatory, so I won’t dwell on them in detail. Personally, I haven’t used this, because the tools I already had were sufficient for discussing features with stakeholders, but it’s useful to know that such a thing exists.
Apparently, Alexander Osterwalder liked canvases very much, so he and his co-authors later came up with the Value Proposition Canvas — a tool for more detailed work on the value proposition (one of the sections from the BMC).

The Value Proposition Canvas consists of two blocks: Customer Profile and Value Map. Customer Profile includes Jobs (what the person is trying to accomplish), Pains (what gets in the way), and Gains (what they want to achieve). The Value Map includes Products & Services (what we can offer), Pain Relievers (how we can reduce pain), and Gain Creators (how we create value for the customer).

Again, we won’t dive into details here. In my work, I’ve drawn something like this a couple of times, but mostly just for fun.
Overall, canvases are a great technique, and I definitely recommend adding them to your toolkit. As I mentioned above, they should be viewed primarily as a conceptual way of working through information, and only secondarily as a checklist with a specific set of data. Canvases fit perfectly into the agile approach — that is, when we need to quickly and with minimal effort work through a certain set of information, and do it not in isolation but together with useful people.

So what do we do to make that happen?
1. We take an information elicitation technique that allows us to get the maximum result in the shortest possible time — a workshop, of course.

2. We gather everyone who has something to say on the topic. If we’re building strategic canvases, that includes the client/product owner, key stakeholders on their side (for example, representatives of target user groups), a technical lead from our side, and, depending on the situation, a PM, UX specialist, and other roles that are important at the moment. Just keep in mind that it’s important to have people representing different perspectives — technical, project, and business.

3. Given that any workshop requires a program (you usually can’t just say, “Guys, I gathered you here — talk to each other”) and proper facilitation, a canvas is a perfect fit — canvases already contain an embedded program: sequentially fill the sections with useful content. All you need is to organize the process correctly, and for that we follow these steps.
1) Preparation:

  • Think through the order in which the canvas sections will be filled based on their meaning. The order shouldn’t be random: many sections are developed based on previous ones — for example, Problems first, and only then Solutions for each Problem.
  • Prepare the canvas itself. This can be a physical board for in-person workshops or a board in Miro, FigJam, or similar tools.
  • Prepare facilitation tools (physical or digital): in particular, a timer and voting mechanisms.
  • Plan the duration (keep in mind that you shouldn’t exceed three hours for the entire workshop so you don’t overload participants — it’s better to split it into several sessions), participants, and other standard workshop parameters: location/tools for the session, breaks, recording, and so on.
During the workshop:

2) Communicate the goal of the event to everyone and what outcome we want to achieve, as well as the format and rules.
For each section:

3) Explain its meaning — what we expect from participants in terms of content — and provide guiding questions. It’s worth placing these questions directly on the board so participants always have them in front of their eyes. And do it in plain language: it’s one thing to say, “Here we fill in business needs,” but you’ll get much more from people if you frame it like, “What are the reasons for starting this project? What organizational problems are we solving with this project?”

4) Give participants time to put sticky notes on the board and set a timer for that. You decide how much time each section deserves. Just think in advance about how much cognitive effort each section will likely consume. On average, this is 5–15 minutes per section. Also communicate the rule: one idea — one sticky note.

5) When time is up, discuss what participants have posted: for example, the author explains the idea, while others comment. It is strongly recommended to timebox this as well so you don’t exceed the format — discussions can easily spiral out of control, and if you let them run free, you’ll be stuck there until night.

6) The analyst, acting as facilitator, removes duplicates and merges or decomposes ideas during the discussion — in general, tidies up the result so that only the necessary, well-structured content remains.

7) If necessary, vote — for example, when there are many ideas in a section. You can give participants a couple of magnets or sticky notes of a different color so they can place them on the ideas they particularly like. In digital formats, you can use likes or something similar.

8) A useful point that is often forgotten: immediately include one or more sections in the canvas for TBD / parking lot / action items. There will always be topics requiring additional discussion or research. For example, while discussing the pros and cons of a mobile application, you may realize that there isn’t enough evidence or that additional research is needed. To avoid getting bogged down in the moment, remember that the canvas is just a starting point. Detailed analysis or research (by the client, engineer, or analyst) should be taken outside the workshop scope, while clearly documenting who needs to do what.

After the workshop:

9) Save the canvas — take a photo or keep it in its original digital form and send it to all participants.
Like any workshop, filling out canvases requires several things:

  • As noted above, preparation and careful facilitation are important during the process. In general, a workshop is a powerful information elicitation technique, but it is usually quite energy-intensive and requires skills in managing group dynamics. So set aside a morning for it and show up energized.
  • It requires (unsurprisingly) the presence and active participation of stakeholders. Without that, the magic won’t happen. That’s why we say this technique works so well within the agile paradigm — agile without active involvement from the client (or at least a legitimate product owner) is difficult to get off the ground.

Why these canvases are so powerful as a technique:

  • A fast and efficient way to work through the necessary set of information. We bring the right people together and generate a large amount of useful content while discussing it along the way.
  • Visual nature. This is not a long document produced by an analyst after a series of interviews, but a visual (and even aesthetically pleasing, if you have a sense of beauty) picture. Don’t underestimate the power of that — both for clients and for your team.
  • It’s collaborative work, part of which we shift onto the client and other stakeholders. In other words, we don’t write the document alone — we let others contribute to the artifact. This approach increases engagement and ownership because people formulate the ideas themselves.
  • It’s interesting. Participants stick notes, place magnets, and generally take part in something engaging.
  • The canvas can later be printed and placed somewhere within easy reach as a one-page poster.
  • The canvas is easy to change (at least in the digital version) as hypotheses are tested and context evolves (for example, when business ideas change).

What to keep in mind:

Canvases provide a high-level understanding. This follows logically from the format itself: if you compare an analyst’s deep dive into a topic over a couple of weeks (with careful stakeholder selection and thoughtful post-analysis after each conversation) to a workshop with strict time limits for each section, it’s obvious that something has to be sacrificed. And that’s where it’s important to understand that this is only a starting point — you will refine the necessary elements later if needed, even through a series of individual interviews and additional research.
Given that the canvases discussed above are useful in relatively narrow situations, in my practice I more often use something that can be provisionally called a Discovery Canvas. I actually just named it that for the purpose of this article — in reality, I usually say that it’s a variation of Lean Canvas. This is when you need to conduct a quick and efficient strategy analysis not only for startup products. There is nothing unusual about it — it simply consists of sections from the classic Vision and Scope document, filtered or supplemented depending on the specifics of the project (you might want to read this first: Strategy Analysis, Discovery, and Vision and Scope — Demystified).

Here is what it might look like and in what order it can be filled. I’ll just note again that this is only an example — in practice, you need to think carefully about which sections and their order are relevant depending on your involvement in the project and which questions are appropriate to discuss.
  1. Business Needs — business needs (problems or opportunities that the organization/client wants to address). You can also add context (symptoms, AS IS metrics, affected processes).
  2. Business Requirements / Success Metrics — business requirements derived from business needs. Optionally: success criteria for the solution (what indicators over time will show that the solution helps achieve the business requirements).
  3. Solutions — solution options for achieving business requirements. Here you need to discuss their pros and cons and agree on the final solution.
  4. Business Risks — what might go wrong in achieving business requirements, even with a ready and working solution. If appropriate, also discuss policies for handling them.
  5. External Dependencies — what external factors does the successful functioning of the solution depend on in terms of achieving business requirements?
  6. Stakeholders — stakeholders related to the business requirements or the solution. You can also add their roles with respect to the solution, since that will be our focus.
  7. Value Propositions — the value stakeholders will receive from the solution (if they receive any).
So this is a template for classic strategy analysis, but filled out in a workshop format inspired by well-known canvases.

What is not included here in the context of discovery / strategic analysis is scope (solution boundaries). And that’s intentional — scope is not something that works particularly well in the workshop format described above. There are separate techniques for scope that can perfectly complement the canvas in subsequent sessions: Impact Map and User Story Map: How to Tackle the Scope Fast and Hard (Part 1 and Part 2).
]]>