Using anti-requirements to find system boundaries | Hacker News Reader

Using anti-requirements to find system boundaries

particular.net

55 pointsdavidboike12 comments

Uh oh. That's a new one for me. I was taught about the idea of anti-requirements at some intro class at my university, but it was presented differently.

Instead of trying to probe your stakeholders with nonsense questions, anti-requirements were something you'd naturally come up with, and which you would include in the initial spec/design (and later keep track of). Their point wasn't about DDD or any tactical-level thing - it was to channel the natural... creativity of people during initial project planning into fences around project scope. It allowed and encouraged responding to "what about..." questions with a firm "no, we explicitly don't care about this" - so that later, when your developers start making vague hints about designing the shopping cart as eventually-consistent distributed object, or something equally "reasonable" from their POV, you could politely remind them that this is way past the fence and far on the pasture of out of scope, not doing that.

Of course, we had an exercise of coming up with anti-requirements, which went about as well as the TFA with its examples. Only now it finally clicked for me that anti-requirements, in the sense I was taught, are about documenting denials to most obvious hare-brained ideas - so obvious that they're likely to be independently thought of by someone multiple times during the project, and could lead to unnecessary waste of time and resources if attempted.

I stopped asking anti-requirements because the people you're asking will give whatever answer they think will make you enthusiastic about the project.

When they have to walk back what they said six months or a year later, they just see it as a new requirement on the system. They don't realize they've sabotaged the entire project by lying about their certainty that we will ever do whatever they said 'no' to.

How do you do this and remain employed? I get that the examples in the article are contrived, but still, it seems annoying and inefficient.

How to address the requirement "We must update the name of an item every time the description changes."? This is clearly false; so therefore, name and description do not belong in the same entity. This idea seems preposterous and would result in every field being in a separate entity. It seems unreasonable that an entity can not have two fields which are independent of each other.

What if your domains evolve autonomously as desired and as a result develop a disagreement on quantity? The warehouse wants to aggressively prune orphaned carts as to release inventory reservations, but sales wants carts to be immortal so they can remind customers that they still want to buy the things. Can they really evolve independently just because this field is copied into three entities? Haven't you introduced a new problem by destroying the single source of truth and now must maintain a synchronization of the values?

I don't grok this at all.

It reads to me like fuzz-testing the requirements.

The bigger problem I'd see is not remaining employed, but getting stakeholders to ever take you seriously again after harassing them with asinine questions.

As a thought exercise, it's cute, just not something you subject actual people to.

What about:

"The total cost is the square root of the quantity. Preposterous!"

-> therefore there is no relationship between the quantity ordered and the total cost?

I don't see how this method proves which properties are related and which aren't. You can come up with ludicrous relationships between any two properties, but that doesn't mean there's no relationship at all.

I don't understand the benefit of anti-requirements. It seems trivial to put your attributes in a matrix and identify relationships between them. Randomly making up requirements doesn't seem effective

It's a suggestion for a tool to create that matrix. i.e., you propose these "anti-requirements" as a way to surface attributes that have no direct relationship.

Feels a bit kitschy to me, but with the right audience, or with an inexperienced BA, perhaps it has merit.

But why not just create it directly? To use the article's example, you can just directly fill in or ask questions about the upper triangle of the matrix below. Adding in the anti-requirements just adds the possibility of missing a combination.

     Name  Desc Price Qty

Name

Desc

Price

Qty

> To use the article's example, you can just directly fill in or ask questions about the upper triangle of the matrix below.

And how do you formulate those questions?

This article is proposing a method.

"Just ask," you might respond, but the point is that non-technical audiences might struggle if you just ask "Do we think Name and Price are related?" because that's very abstract.

Formulating it as a specific example of a potential rule or relationship creates something concrete and relatable that people can react to.

Again, I think it's a bit kitschy, but having worked with non-technical audiences who struggle to think in terms of abstract relationships between data elements, I can see some merit in the idea.

The issue never seems requirements gathering at some point in time. The issue is that the requirements change in the future and may change not in the ways we predicted or guessed from this weird exercise.

Using anti-requirements is a powerful way to increase autonomy by breaking your domain into separate islands that can evolve independently.

First time I've heard of anti-requirements, though it seems I've kinda used them albeit more directly. For example I'll just ask "I assume the description does not depend on the price, is that assumption correct?"

Another thing I've noticed is that stakeholders mostly think about the everyday stuff and thus can forget about edge cases. I've been in several projects where "never ever" turned out to mean a few times a year. Feels like asking about such anti-requirements like in the article could be very prone to this.

On another note, the example used in the article feels contrived. Like why such a denormalized shopping cart entity to begin with?

It also misses an obvious requirement, that the customer should get the quantity paid for. Or at least describe how to handle properly updating cloned attributes like Quantity. Ie what if one of the systems fails to update an increase in Quantity?

Reply on news.ycombinator.com