Integrating Business Rules with User Stories

Question

I have a set of user stories, and I have a set of business rules (primarily laws that link my requirements with requirements). In Agile SDLC, I'm not sure where these “rules” are tied to my user stories.

For example, a user story like:

As a doctor, I want to add patient information to create a new patient file.

And a rule like:

The following information should be included in each patient’s record: (patient: (i) name and first name; (ii) address; (iii) date of birth; and (iv) gender;

These two are clearly combined, but how can I connect them? How are test acceptance definitions in my user history? Another user story?

Answer 1

There are several different ways I have seen this:

• The artifact was created to conduct a business rule and is stored in some central repository of all rules, so this is known throughout the development team and the repository of knowledge is stored. This can become ugly, because there can be hundreds of rules within a few years of creating an application.

• Rules can be placed on separate cards in the user's history. Thus, although the user's story is one line, there may be 6-8 cards that make up all the tasks for this story that will be completed. For example, a new patient form must be created, validation on the form, etc. Thus, it is easy to see that this origin occurs along the line on the map as a way of tracking this requirement. This is the most natural for me, although this is not the case when a particular list will be written at 100%, since the map can be "guarantee that some fields in the form are required."

• There is no explicit link, but a rule is something for QA or BA to mark for the user to make sure the form provides this rule. This seems like one thing, but the question is what is the responsibility of the developer. In this case, most likely, the QA can track, not the developers.

User history is intended to start a discussion, not a complete list of requirements. A rule is what should happen when a developer discusses with the user what is needed to create a new patient file.

---

I like the idea of ​​hanging cards on several sprints after the story has been made, but I see that the cards will eventually be destroyed. At the same time, there should be code that implements the rules in their field. To use the example you cited, it may be that a list of required fields will be marked in several places, since there is a user interface layer that should show the fields and probably an error message, but there must also be some level of business logic that has this logic to make sure that some fields have been specially completed before trying to create a new patient file. The system under construction will also contain rules in one form or another.

Answer 2

As eligibility criteria. After all, these are rules that can be executed as tests. Definitely not new stories, that would be wrong, because the goal is not attainable.