Business rules integration to User Stories

Question

I have a set of User Stories and I have a set of business rules (primarily laws binding my requirements to be compliant). In Agile SDLC I'm not sure where these "rules" are attached to my user stories.

For example, a user story like:

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

And a rule like:

The following information must be entered in the record of each patient: (a) patient: (i) name and given name; (ii) address; (iii) date of birth; and (iv) sex;

These two clearly come together, but how can I link them? As test acceptance definitions in my user story? Another user story?

Gissing

I’m voting to close this question because it is not about programming – Rhymester

Answer 1

There are a few different ways I've seen this handled:

1. An artifact is created to hold the business rule and is stored in some central repository of all the rules so this is known throughout the development team and a storehouse of knowledge is maintained. This can get ugly as there can be hundreds of rules within just a few years of building out an application.

2. The rules may be put onto separate cards within the user story. Thus, while the user story is that one line, there may be 6-8 cards that make up all the tasks for that story to be completed. For example, there has to be a new patient form created, validation on the form, etc. Thus, it isn't hard to see this crop up down the line on a card as a way to track the requirement that way. This is the most natural to my mind though this isn't where the specific list is going to be 100% written down either as the card could be "ensure some fields on the form are mandatory."

3. There isn't an explicit link but rather the rule is something for QA or a BA to note for the user to verify that the form does enforce this rule. This is similar to one but the question is what is the responsibility of the developer in this. In this case, it is something for QA to track rather than developers possibly.

The user story is intended to start a discussion, not be a comprehensive list of the requirements. The rule is something that should come up when the developer discusses with the user what does it take to create a new patient file to my mind.

---

I like the idea of hanging on to cards for a few sprints after the story was done, but I do see the point that the cards will ultimately be destroyed. At the same time, there should be code somewhere that implements the rules in its proper area. To use the example you posted, it may be that in a few places the list of required fields would be noticed as there is the UI layer that has to show the fields and probably an error message but also there should be some Business Logic Layer that has this logic to see that some fields were specifically completed before trying to create a new patient file. The system being built will also house the rules in some form or other, too.

Beslobber

Ok, so if during the discussion I agree upon a few rules I can follow your (2) suggestion. I think that would be nice. The only problem is user stories are usually "self-destructive", i.e. I will discard it after the story is over. So the rules are also lost, or am I wrong? – Gissing

Answer 2

As acceptance criteria. After all these are rules that can be executed as tests. Definitely not new stories, that would just be wrong as there is no deliverable goal.

Sinkhole