Building a functionally complete set of user goals using the C.R.U.D. method

A list of goals that any system’s user needs to be able to accomplish using the system-under-design (a.k.a actor-goal list, a.k.a. user stories) is a central part of any functional requirements. However, unless that list is functionally complete, its deficiencies and omissions will propagate throughout the remainder of the development process and potentially wreak havoc later. This post deals with one of the (many) ways you can help your list of user goals not to be one of those “deficient ones”

“A robot designer applies a crud method and produces a list of goals on the computer screen, digital art”, OpenAI Dall-E 2, 2022

Introduction

As we stated in the subtitle, an actor/goal list (or a list of user goals in any form that you fancy) is a central segment in any set of functional requirements and it’s pretty much what its name implies.

Actor goal list is a list of all the entities (physical users, stakeholders, automated systems, etc. — a.k.a. “actors”) that interact with the system in any way in order to achieve some goal significant to them, and a corresponding list of all those particular goals that each individual actor needs to be able to accomplish.

If what you’ve just read sounds convoluted or complicated— don’t worry, it is really quite simple, and there will be examples just a few paragraphs down the line, which should make everything much clearer.

The importance of an actor/goal list, however, is that it serves as a root (or a hub in the hub&spoke model) from which all other requirements (use cases, acceptance criteria, etc.) are derived.

Or to put it in another way, any other functional and non-functional requirement you define MUST be directly “routable” to one or more of the user goals specified within the actor-goal list.

But however you put it, it’s rather obvious that it is crucial that your actor/goal list is functionally as complete as possible.

This text elaborates on one possible method of achieving that goal.

What does CRUD actually stand for?

You are probably familiar with this acronym, but most likely not in the context of functional requirements.

It stands for “Create-Read-Update-Delete” and is usually used to describe the simplest complete usage scenario for a given entity in your system. For example, if you have a classifieds system, and you have an “ad” entity (“ad” as in “classified ad” — a piece of information about an object or a service offered for a sale), then this entity can be created, read (or displayed or consumed), updated and deleted.

CRUD is also used as a term to describe the basic administration UX/UI for a given entity — as they typically allow for one or more of those operations on an entity they administer.

We’ll leverage the fact that CRUD describes the simplest complete usage scenario for a given entity and try to use it for building a complete actor/goal list.

An example of an actor/goal list

So let’s start with an example of an actual actor/goal list:

A seller can…

1. Send purchase notification to a buyer
2. Receive purchase notification from a buyer
3. Confirm a purchase notification sent by a buyer
4. Rate a buyer
5. Write a review about a buyer for a particular transaction/ad
6. …

A buyer can…

1. Send purchase notification to a seller
2. Receive purchase notification from a seller
3. Confirm a purchase notification sent by a seller
4. Rate a seller
5. Write a review about a seller for a particular transaction/ad
6. …

A customer support chief can…

1. See all purchase notifications for a given time period
2. …

A data analyst can…

1. See detailed statistics for all created reviews, grades, and purchase notifications
2. …

One thing to notice in the list above is that all goals are user-level goals ie. goals that can be achieved within “one sitting” and which are of significance to a main actor of the use case.

Consider the following example: “Receive purchase notification from a buyer” is a legitimate goal for a seller — after that goal is achieved, he has accomplished something of value to him, as opposed to “Visitor logs in as a seller”. In the latter one, there is no value for the seller in achieving that particular goal — it’s just a technicality he has to get over with “en route” to achieving a goal that he actually wants to achieve.

The rule of thumb here is to try to focus your design effort on the user-level goals first, and cover the low-level ones either via UI agnostic use cases, functional acceptance criteria, etc.

So now, let’s find out how we can build one such list using the operations defined by the CRUD acronym.

The “Method”

As we already established, building a strong and functionally complete actor/goal list is nothing less than crucial.

The reason for such a strong statement is that a complete actor/goal list will ensure that all requirements that would later be based upon those goals (such as use cases, UI/UX designs, etc.) would — as a consequence - define your system without any important functional gaps.

Or in other words

The functionally complete actor-goal list is a prerequisite and a basis for any functionally complete set of requirements

That said, you can create this list “organically” — ie. by “thinking it out” or by using some design method.

One design method/trick that has proven to be handy (at least to me) is to use the CRUD acronym and apply it to all Terms/Objects/Entities which are within the scope of your project.

For a hypothetical project/feature “User reviewing and grading” in the context of a generic classifieds system, it would go something like this.

Step 1: Identify Terms that are within the project scope

In this case, there are some obvious ones: “review” and “grade”, and since at this stage you know a bit more about your idea, you’ll also identify things like “purchase notification”. So let’s list them:

• Review
• Grade
• Purchase notification

(one important note — all those terms should already be, or become a part of your ubiquitous language)

Step 2: CRUD it!

Ok, so what we do next is combine each of the terms in our list with four CRUD verbs, in a way that we end up asking ourselves the following questions:

1. “Who VERBs this TERM?”,
2. “How the TERM gets VERBed by those actors who can do it? ”

For example, let’s start with the “C” — or Create:

Term: Review, Verb: Create

Question: Who Creates the Review?

Answer: Sellers and Buyers do.

Question: How does the Review gets created by the seller and buyer?

Answer: A seller submits a review of a buyer with whom he had a transaction. A buyer submits a review of a seller who he had a transaction with.

Cool, we’re getting somewhere. And we’re also discovered that there should probably be some certificate of the transaction — and we have just such a thing in our list — a purchase notification (otherwise now it would be time to update our list of terms).

So far we have the following Actor goal list:

Buyer

• Submits a review of a seller he had a transaction with

Seller

• Submits a review of a buyer he had a transaction with

Now let’s move on to “R” — or “Read”. The verb “Read” in the context of this method is interpreted a bit broader than just the simple act of reading — it should be thought of more along the lines of “Consume” or “Use” as well as “Read” — so each of those verbs can be used interchangeably. Let’s give it a go.

Term: Review, Verb: Read (or Use or Consume)

Question: Who Reads/Uses the Review?

Answer: Seller and Buyer do. Also, an administrator does

Question: How does the Review get used by the seller and buyer?

Answer: Seller receives and reads a review of him, written by a buyer who had a transaction with him. (same goes for buyers as well, so we’ll omit it here). The administrator reads any submitted review.

Let’s update our actor goal list:

A buyer can…

• Submit a review of a seller he had a transaction with
• Receive and read a review of him written by a seller who he had a transaction with.

A seller can…

• Submit a review of a buyer he had a transaction with
• Receive and read a review of him written by a buyer who he had a transaction with.

An administrator can…

• Read any submitted review

and that’s all there is to it really, we continue the process with every TERM-VERB pair we’ve identified, and as a result, we update and expand our actor/goal list and potentially expand our TERM list as we discover new actors and terms along the way.

Step 3: Behold your resulting actor/goal list

Following the process described above for a few additional iterations, we might end up with something along the following lines:

A buyer can…

• Submit a review of a seller he had a transaction with
• Receive and read a review of him written by a seller who he has a transaction with.
• Confirm that he had a transaction with a particular seller on a particular ad.
• Submit a grade for a seller he had a transaction with.

A seller can…

• Submit a review of a buyer he had a transaction with
• Receive and read a review of him written by a buyer who he has a transaction with.
• Confirm that he had a transaction with a particular buyer on a particular ad.
• Submit a grade for a buyer he had a transaction with.

An administrator can…

• Read any submitted review
• Read any submitted grade
• Read any transaction confirmation (Purchase notification)
• Delete any submitted review
• Delete any submitted grade
• Delete any transaction confirmation (Purchase notification)
• Update any submitted review
• Update any submitted grade
• Update any transaction confirmation (Purchase notification)

A customer support agent can…

• Verify and publish any submitted review
• Verify and publish any submitted grade
• Change any submitted review
• Change any submitted grade
• Delete any submitted review
• Delete any submitted grade

Note that the list above is neither fully complete (there are some other roles involved — such as data analyst, Customer support chief, etc.), nor it describes an ideal solution (buyers and sellers probably should be able to change/cancel their reviews, etc.) — but I believe it serves as an illustration of the expected results of this technique, and could easily be made better and more complete using the same method if we’ve applied more time than the scope of this text allowed for.

The conclusion and some usage instructions

The method described in this document is heuristic in its nature, and I certainly make no claim for it to be perfect or even very elaborate, but in my experience it proved to be a very useful tool, resulting in quite a strong actor/goal lists, and I find its simplicity one of its strong points.

That said, don’t try to use it as a magic provider of complete actor/goal lists, but rather as a tool for getting the first complete and strong draft of your list in a comparatively little time, or alternatively build your first list “organically” and then use the method described here to figure out things that you omitted or overlooked.

However, whichever approach you end up choosing, always make sure to scrutinize the resulting list and augment it or change it whenever you feel like it needs improvement.

That is really how this method should be used, in my opinion, and the way it produces the best final results.