- From: Joe Andrieu <joe@legreq.com>
- Date: Wed, 22 Sep 2021 09:36:28 -0700
- To: "Credentials Community Group" <public-credentials@w3.org>
- Message-Id: <0849229e-a2da-4150-aa38-c0c86ed79a99@www.fastmail.com>
On Wed, Sep 22, 2021, at 8:27 AM, Dmitri Zagidulin wrote: > Great job on the diagram! > > Is there a way to denote that a step is optional? (I spose one could put '(optional)' next to the text, in parens, but just curious what your design thoughts are.) Great question. I'm generally not a fan of diagramming optional flows because the complexity can get so out of hand you lose the essence of what needs to happen. Not that parts of the flow can't be optional (that'd be crazy), but in general, our (Legendary's) approach to requirements is to get concrete on a specific set of interactions and dig in to tease out what really happens for that particular experience. I do this in both the prose and diagrams like the sequence diagram. Rather than documenting all the options, I prefer to pick a protagonist and walk through exactly what they actually do. So if someone pays by credit card, I much prefer saying "Jill enters her Mastercard" even if on another day Jill might use a Visa card. Most of the time a competent engineer can see which points are extensible and adjustable. Although I just tried to add "optional" to that list and it didn't ring true. Unless we point it out as optional, it isn't going to be as obvious as swapping out Visa for Mastercard. So maybe "optional" is a good annotation. The tool we use has a couple options for doing that, but the easiest would just be to add "optional" to the message label itself. FWIW, we also tend to start diagrams like this in straightforward human english rather than trying to use message names that look like function names or API endpoints. Later on, we use VP to aggregate all of the incoming calls to an entity and at that stage, we will typically establish a naming convention and start adding the literal name or route for the message. That said, I've been in many discussions where when the prose just said "enters payment info" we forgot about the CVV code, and as soon as we got concrete and said "takes out their mastercard and types in the number" it immediately evoked the memory of adding the expiry and name, and having to turn the card over and get the CVV. A small victory, for sure, but those kinds of details can cause a lot of rework if you miss them early on. -j > > On Tue, Sep 21, 2021 at 4:02 PM Joe Andrieu <joe@legreq.com> wrote: >> __ >> Here's a rendering of the work flow from the supply chain folks (Erich Schuh and I sat down with Orie and Mike to tease this out). It advances the conversation from a non-chapi use case. >> >> Notably, some additional definitions >> >> XXX App = The server that instantiates the business rules that drive XXX behavior >> XXX Service = The service/software that provides the XXX specific functionality, driven by the XXX App. >> >> For example, in the USCIS Digital Green Card case >> *Issuer App* = the website run by USCIS that interfaces with beneficiaries and knows who gets a green card. It drives the Issuer Service. >> *Issuer Service *= the SaaS run by, e.g., Digital Bazaar, which provides VC issuance capability to clients >> >> We've started using this pattern across all three roles and are working through updating the CHAPI flow. >> >> -j >> >> -- >> Joe Andrieu, PMP joe@legreq.com >> LEGENDARY REQUIREMENTS +1(805)705-8651 >> Do what matters. http://legreq.com <http://www.legendaryrequirements.com/> >> >> -- Joe Andrieu, PMP joe@legreq.com LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>
Received on Wednesday, 22 September 2021 16:37:07 UTC