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.
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:
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.
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):
That’s our initial data analysis — done.
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.
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.
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:
And just like that, CRUDL becomes even more powerful for you personally.
- 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.
