1

I have to sympathetically resolve a debate internally. Take this scenario, it's not perfect but bear with me.

As Arthur

I want to upload multiple lists of appointment data during the day

So that a SMS message is sent to the patient to check their emails.

The file is exported from a 3rd party system in .csv, we have no control over this, and Arthur currently continues in that format.

A colleague is adamant that the scenario should be:

As Arthur

I want to upload multiple lists of appointment data during the day in .csv format

So that a SMS message is sent to the patient to check their emails.

I feel that the file type is an acceptance criteria, not part of the scenario because Arthur could have saved it to xlsx for analysis on other tabs. We would need to fail that should the business insist we only support .csv upload. BDD is new to the company and I don't profess to be an expert, I am trying to get better fast, so any advice would be gratefully recieved.

3
  • 1
    Given that the csv format is currently (and in the foreseeable future) the only accepted format, I don't see any harm in explicitly mentioning it in the scenario. If in the future a requirement comes up to also support the xls format, then that could be a different scenario. Commented Oct 24, 2018 at 11:22
  • Thanks @BartvanIngenSchenau. In this situation the csv is an export from a third-party system. Arthur could chose to Save As into xlsx or leave it as it is. So part of my argument was the scenario is agnostic too it's inputs and formats and purely focussed on what the desired goal is. Perhaps that is too strict an approach?
    – K7Buoy
    Commented Oct 24, 2018 at 11:53
  • I going to edit my statement above slightly.
    – K7Buoy
    Commented Oct 24, 2018 at 11:58

1 Answer 1

1

Your requirement is to support whatever file format that third party system is able to generate (or at least one of those formats, if there is a choice). Then write that down.

As Arthur
I want to import multiple lists of appointment data during the day from {third party service}
So that a SMS message is sent to the patient to check their emails.

This is not inherently a CSV file, this just happens to be a CSV file. As such your hunch that it would be excessive to mention the CSV type in the scenario is largely correct.

In fact, your use case seems to be about synchronizing with the third party service. A manual export/import of data might be one way to solve this, but if the service provides an API that you can integrate, this might be a much better solution to this requirement. Possibly, the use case should be phrased like this:

As a patient,
I want to receive an SMS notification when my appointment status in {third party system} changes
So that I remember to check my email.

While this describes the value of the scenario better, it might be so high level that it's not actionable for you. So it depends a lot on context how this should be phrased. Maybe the first variant that describes the perspective of an immediate user of your system might be better.

1
  • I like this approach. Thank you. We are asking about API options for sure!
    – K7Buoy
    Commented Oct 25, 2018 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.