How can I put in the design constraint into a user story?
The system to be developed will generate a invoice when a payment is made, and will send the invoice to xMail (an emailing tool) which will then email the invoice to the customer.
How should I put the information where the system will send the invoice to xMail?
Note: xMail is just a random name as I could not reveal the actual name
2
Consider what the key steps of the process are and when the value to the customer is derived. Try and capture that in the user story. Then use your acceptance criteria to flush out the requirements further. There is nothing wrong with putting a constraint in a story; not everything can/needs to be negotiable.
Example:
As the system I WANT TO generate & send an invoice to xMAIL SO THAT xMAIL can send the invoice to the customer.
- Validate invoices are generated & sent when a payment occurs
- Validate xMAIL receives the invoice
- Validate the customer receives the invoice via xMAIL (this may considered outside the scope of the story, since xMAIL is an external system. However it is still part of the business process and a QA candidate)
User stories are great for capturing functional requirements, but they don’t work that well for design constraints and non-functional requirements.
For design constraints and non-functional requirements, a more traditional formulation still works best.
As user stories tend to get more attention, it is a good idea to reference the relevant constraints and non-functional requirements in the description of the story and possibly in the acceptance criteria.
If it’s a requirement, put it in the story. Just be sure it’s an actual requirement and not an assumption you are making about the eventual implementation.
“As a user of the system, I want an invoice sent to xMail when I make a payment, so that we can support companies that exclusively support xMail”