Re: [specificationbyexample] Digest for specificationbyexample@googlegroups.com - 2 updates in 1 topic

[Mohamed Fakihi]

Hi Orsolya,

Building on what Frauke said, I would rather walk back from the end. The question that I would ask is: How will the subsystem you’re building be tested and validated? Will the QA use the subsystem UI, will they use the higher global system UI or will they test the subsystem APIs? I believe that beyond the functional and non-functional requirements, the examples using the input/output that a tester will use makes it easier to grasp the expected results and would involve the QA team in the conversation upstream rather than having back-and-forth after the code has been written.

I hope this helps, and let us know if we correctly understood your situation.

Best,

M

On 16 May 2025, at 9:52, specificati...@googlegroups.com wrote:

specificati...@googlegroups.com

Google Groups

Topic digest
View all topics

• Subsystem specifications for a medical device - 2 Updates

Subsystem specifications for a medical device

Orsolya Megyik <ome...@gmail.com>: May 15 06:04AM -0700 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 <juju...@gmail.com>: May 15 07:58AM -0700 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)

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to specificationbyex...@googlegroups.com.