Subsystem specifications for a medical device

[Orsolya Megyik]

Hi,

I have a question about the focus of the SbE when it is used to describe a subsystem within a larger system that communicates with other subsystems via some kind of interface.

I work as a Software Systems Engineer for a medical device company, we had the SbE workshop a month ago to start using Specification by Example to write specifications for our app. This will be used to verify our software requirements. We have separate system requirements that will be verified with system tests, that is outside of the scope of SbE.

When we describe the scenarios, the most intuitive way is to discuss what will happen with another subsystem and what effect that has in our subsystem. But by following this you would get a system specification and that is not our job here.

If we follow the less intuitive way and describe the data exchange on the interface we get to the *HOW*, get very technical and we lose the point of having easy to follow discussions with our whole team. But we get very clear and precise specifications.

What is your advice here? Should we keep the discussions high level and describe what is happening in other subsystems too, or should we move to a lower level description specifying the data exchange at the subsystem interface?

Looking forward to your input! Thank you in advance.

Best regards,

Orsolya

[Frauke Quik]

Hi Orsolya,

I am not sure if you are asking Gojko directly, or asking the community. When I read your question, I got excited and wanted to share my experiences and insights. So I'm not writing this to say: it's like this or that, but to share a perspective, that may or may not be useful to you.

You say the purpose of the session is to verify the software requirements. Now to me, that can mean a lot of things. Sometimes software requirements are really bad and actually, an SbE session would be to clarify the software requirements themselves, because they're not clear enough and it's important to create shared reality.

Personally, I really liked edge cases test driven development.

I would look into who is going to be doing the verifying and what do they actually need from you, to be able to do the verifying? That will help define your end product.

Btw, it can also be that I use a session for multiple purposes. E.g.I want to use the same session for establishing shared reality on the overall plan and the natural flow that makes sense. That way, we know there is more trust that we're starting of on the same page. In addtion, I find it is a good way to practice getting into this really collaborative way of communicating, a sort of improv yes and atitude can be helpful, as well as later on, a what about this and that lens (edge cases). I like to make it fun as well,

Because such sessions can be both about developing a process of more creating more clarity, coherence, mutual understanding on this topic, as well as creating end products that are useful for the people who will be using it. Sometimes it needs to serve multiple groups, so it's important to find a way that communicates clearly to all.

Btw, often if something is less intuitive now, I've found that with practice, it is likely to become more intuitive over time. If not, it's better to shift to creating something that makes more sense.

Hope this is useful!

Frauke

(reposting because I misstyped Gojko's name)

Op donderdag 15 mei 2025 om 16:06:06 UTC+2 schreef ome...@gmail.com:

[Orsolya Megyik]

Hi again,

Thank you for your insights, Frauke! The question was targeted towards both the community and Gojko, I am very happy for all your inputs :)

Soo are you suggesting to (1) keep the team discussions system focused to discover edge cases, and then (2) describe the data exchange on the interface in the finalised scenarios?

Best regards,

Orsolya

[Gojko Adzic]

Hi Orsoloya,

When I interviewed people for the Spec by Example book there were a few cases with teams building specific components that can't really deliver value on their own, and a potentially useful pattern in that case was to describe examples for a higher level, but then automate it with two different types of automation layers. One was broader, system level; the other was just focused on the subsystem and abstracted away the technical implementation of the components before and after the one under test in the pipeline. The automation layer was responsible for generating the appropriate messages going in, and checking the appropriate messages going out (the data exchange), which is consistent with the idea of keeping the "how" in the automation. This might be a useful first step if you've never done such things before.

A common second step for such work is to then separate out the data interchange (technical specs) and your subsystem logic (business specs), and implement something based on ports-and-adapters or hexagonal architecture, which would let you define and test the interchange with other components with integration and unit tests (usually technical), leading to some internal domain translation of those things for your subsystem. the business specs would then work with the internal domain concepts and be focused on what your subsystem needs to do in the terms of that specific domain. That would allow you to be specific both about the data interchange with other components (how/technical/translating between external and internal domains) and the domain logic of your subsystem (what/business/in your internal domain). 

gojko

[Orsolya Megyik]

Hi Gojko,

Thank you for your quick response.

Just to make sure I get your point:

Are you suggesting to start with keeping the description high-level, and later, when we are more experienced in this method, add a second layer of Given-When-Then to the same scenarios that specifies the data exchange at the interface?

Best regards,

Orsolya

[Gojko Adzic]

I think the interface data exchange should be covered by technical tests (integration or unit). I was more thinking about switching the automation layer for given-when-then; you can initially automate the same scenario wider, involving other components, then later when you get a chance to understand how things work and make it reliable, reduce the automation to just your segment/subsystem and simulate the inputs/verify component outputs for the larger scenario. then potentially start designing scenarios that involve only your subsystem in your subsystem domain language.

--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.
To unsubscribe from this group and stop receiving emails from it, send an email to specificationbyex...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/specificationbyexample/d161d636-0479-42de-9bd5-9bc83fa90547n%40googlegroups.com.