A guide for self-testing business stories before submitting them for review to the analytics lead and team

Hi all! My name is Olga. I am a middle systems analyst in a large Russian IT company.

Quite a lot of experience working with business stories helped me create a list of rules for self-testing before the final presentation to the team. And in this article I want to share them with you.

A little theory

What is a business story?

Business stories (or also called “business scenarios” or “use cases”) are a system analysis tool that are used to describe the interactions between users and an information system. They focus on telling the story of how users interact with a system within a specific business process or situation.

Why do we need business stories?

1. Understanding business needs: Business stories help systems analysts and developers fully understand business processes and user needs. This allows you to create information systems that truly meet business goals and requirements.

2. Improved communication: By describing user interactions with the system in the form of stories, business stories facilitate clearer and more understandable exchange of information between project participants, including the customer, developers and testers.

3. Iterative refinement of requirements: Business stories can be easily modified and expanded during the analysis and development process, allowing you to iteratively refine requirements and better match business needs.

How are business stories written?

When writing business stories, it is important to focus on key aspects of how users interact with the system. Every business story should include the following elements:

1. Title or title: A brief description of the situation or process that is described in the story.

2. User Roles: Defining the roles of users who interact with the system and their goals or objectives within a given story.

3. Scenario Description: A sequential description of the steps or actions that are performed by users as part of a business process.

4. Expected Result: A description of the expected result or goal that the system should achieve as a result of executing a given scenario.

Why do you need a self-test guide?

… you ask)

So I hope not)

So, let's start checking your business history step by step.

Step #1. The user story indicates a clear business benefit. Keyword “business”

“Explicit business benefit” means that the user story explicitly states what benefit or business benefit will be achieved by performing this task or function. This could be improving productivity, reducing costs, increasing revenue or improving the quality of service for customers.

Step #2. All necessary permissions (for objects and operations) have been added to the role matrix

Authority. Not roles. Authority can be given to any role, so the role is secondary here.

Step #3. Only one business story is covered in a business story

The key word is “one” – no more, no less)

In business history on creation there cannot be a card view. In the business history of the card view, editing cannot be done. There cannot be a list view in deletion. Etc. And so on.

If, during self-examination, it turns out that a business story covers several others, decompose it!

Step #4. The business history indicates whether it should be licensed and how the license is verified

Step #5. All necessary entities and attributes have been added to the domain model

** And the attributes indicate type, mandatory (mandatory) and plurality.

Step #6. The domain model is business, not physical (technical)

The database and UI are deceptive – we trust them, but we check them. They are not equal to the business domain model, because using the domain model we can design 100-500 different ERDs, and all of them will not contradict it.

Please do not limit yourself to physical (technical) implementation – abstract yourself! Then, if it changes, you won’t have to redo the blast furnace).

Step #7. The multiplicity of connections between entities does not contradict the multiplicity of attributes responsible for these connections

Example: If the Department attribute in the Position entity is marked as [1]then it would be strange to see the connection between the entities “Department” and “Position” [0..1] near the “Department” entity.

Step #8. There are no duplications of attributes in the domain model

1. If some attribute can be calculated by connection at runtime, then there is no need to add it to the entity where we can calculate it. Leave it in the entity where it is vital when creating its instance and where it cannot be calculated – only set directly.

2. If two entities are related, then the attribute providing the connection must be in the one where it is strictly necessary when creating its instance.

Step #9. Aggregations really are aggregations

IF

1. an instance of one entity is non-functional when it has no relationship with instances of another entity

   OR

2. this instance is “strange” for us when it has no connection with instances of another entity (“strange” = anomalous, abnormal, curious, interesting, attention-grabbing, clumsy, we want to fix it or “bang it”))

THEN Most likely, this entity aggregates the second one (white diamond).

Step #10. Combinations/compositions are indeed combinations/compositions

IF

1. When an instance of one entity is deleted, the associated instances of another entity are deleted

   OR

2. When you lose access to an instance of one entity, you also lose access to related instances of another entity

THEN Most likely this entity combines/composes the second one (black diamond).

Step #11. Not in the domain model ugly unaesthetic line intersections

up, down, left, right on connections to help.

Step #12. Changes have been made (IF NECESSARY) to the domain model of the operational layer with subdomains

Important! Updating the schema only after agreeing on the changes with the person responsible for the domain model of the operational layer.

Step #13. All new/changed entities and attributes of the domain model have grown into entity dictionaries

Otherwise out of sync! Out of sync leads to chaos! Everyone's a mess infuriates agrit)

Step #14. Entity dictionaries do not contradict the domain model

If they contradict, figure it out:

1. fix the domain model first

2. then the dictionary

Otherwise, see about out of sync above

Step #15. ERD does not contradict the domain model and entity dictionaries

If it contradicts, figure it out:

1. fix the domain first

2. then dictionaries

3. only later ERD

Otherwise, see about out of sync above

Step #16. ERD normalized to at least third normal form

If you don’t know/forgot the normal forms, welcome to the almighty Google)

Step #17. A business process diagram has both a back layer and a front layer.

Otherwise, we will not be able to catch places where server-side validation is needed.

Step #18. In any action that changes system data, the business process diagram has both client and server validation

** And they entail errors with which the user needs to do something.

Step #19. In any action on the back side there is an erroneous flow

We do not cover system errors with acceptance criteria, but we indicate this flow to understand risks and assumptions.

Step #20. If you have a sequence diagram, then all the “bars” are activated and deactivated in time

Otherwise, there will be confusion and unflattering expressions addressed to you from the system analysis lead)

Step #21. All acceptance criteria are grouped and the groups are named and highlighted to make them easier to read and understand.

Step #22. Each criterion, like a river, follows from the previous one and does not drag with it a many-kilometer tail of preconditions

Example: If in the first criterion you have a precondition for having rights, a form is shown, then in the next criterion associated with it, you do not need to mention the rights again – we immediately write “I ALREADY see the form.”

Step #23. The precondition lies in the precondition, the trigger lies in the trigger, and the result lies in the result

A trigger is an ACTION. The very last action, after which the engine compartment magic occurs

1. Not the result we will get in Magic

2. Not a spell that needs to be cast before hitting the hood with a magic wand.

3. And the blow of the magic wand on the hood itself

I hope my metaphor is clear))

Step #24. From each fork in the business process diagram (an alternative in a sequence or gateway “X” in BPMN), child criteria appeared, breaking the original one into fork preconditions

Step #25. From each “merging in ecstasy” on the business process diagram (gate “+” in BPMN or opt in sequence), a common criterion emerged for those parts of the blocks that ultimately turned out to be common, despite the forks. And from this general criterion, daughter ones appeared, covering each fork

The magic phrase in preconditioning “Regardless of:” to help

Step #26. There are no ORs in the “result” column – only AND

Step #27. I saw both AND and OR in preconditioners or triggers – I stopped, exhaled, thought and decided whether brackets were needed, and where, and why

Any doubts? Open Google and brush up on your knowledge of logical operators.

Step #28. Acceptance criteria are short, concise, easy to understand and businesslike

As in the case of the domain model, there is no need to drag the engine compartment solution into the criteria, otherwise you will have to rewrite them every time you replace the engine.

Step #29. All criteria that affect changes in data in the system have a link to the validation table

*And all possible errors taken into account are in it, not in the hundred-million criteria for errors!

Step #30. The validation table contains all possible business errors. System ones too, maybe, but the main thing is business ones

Server-side validation is foolproof. It is always there, it cannot but exist. There may not be a front. There may be a bug on the front. The front may be foreign. But there should always be foolproof protection on the server. Because the fool who called the API directly by looking at it in the browser may turn out to be very smart

1. Uniqueness is checked on the server

2. The maximum length check is still checked on the server even if there are limits on the front

3. Authorization check is duplicated on the server

4. All types of rassynhon are checked on the server – while you filled out the form, went off to get some coffee, and then returned to click on the “Save” button, everything could have changed on the server a long time ago

Step #31. Acceptance criteria do not contradict the domain model, entity dictionaries and business process diagram

If they contradict, figure it out:

1. fix the domain first

2. then dictionaries

3. then a business process diagram

4. then the acceptance criteria

Otherwise, see about out of sync above

Step #32. You thought about the testers and therefore all the names of columns, fields, their visibility, filterability, sortability, type of widget or element and other front-line crap in the design strictly coincide with what is specified in the user interface requirements

Yes, I also think that digging into such things is unworthy of an analyst’s attention, but the first thing testers will come to you with when testing your features is this very thing.

Step #33. The design does not contradict the domain model, entity dictionaries, business process diagram and acceptance criteria

If it contradicts, figure it out:

1. fix the domain first

2. then dictionaries

3. then a business process diagram

4. then acceptance criteria

5. design later

Otherwise, see about out of sync above

Step #34. API\Events do not contradict the domain, entity dictionaries, ERD, business process diagram and acceptance criteria

If it contradicts, figure it out:

1. fix the domain first

2. then dictionaries

3. then ERD

4. then a business process diagram

5. then acceptance criteria

6. only then API\Events

Otherwise, see about out of sync above

Step #35. The hierarchy of pages also tells a story, rather than blowing your mind

The very first one in the tree is the domain model, then ERD, then dictionaries, then general assumptions, then general risks, then business stories in some logical order, or at least in order of priority. We walked along the tree – something was already structured in our heads.

And not as it happens – first ERD, then stories, and at the very end of all epics, suddenly dictionaries, and after them – the domain model.

Now take your business story and analyze it using all these steps.

If all the answers to the previous points are “YES,” then you can exhale and drink a cup of aromatic coffee, and give your business history to the lead for grooming/re-checking

Conclusion

I hope this guide was useful and will help make your work with self-testing business stories easier.

Share in the comments what rules you follow when writing and checking business stories. It is very interesting to learn your experience and use it in practice!