0

Using RUP methodolgy, when doing "finding actors and use cases" and "specification of use cases" activities, we are recommended not to think about how we are going to build the system (take design decisions).

But later when doing the design discipline activities sometimes we find some design decisions lead to changes in the scope of the system, normally including secondary actors and new paths in some use case specification.

For example:

We are building a system that send documents to signers when a primary actor requests that. During the design phase, when thinking about how to build the system, we found it is a good idea to use some existing signer provider.

Now the system we are building is going to send the document to the signer provider and the signer provider will manage the sign process with the signer.

So responsibility is moved to this new secondary actor. Then we need to specify the interaction between this secondary actor and the system we are building, as specifying what happens when the signer provider fails communicating our system some event etc. Should we update the requirements artifacts and show them to the users and client? Is this situation common?.

geocodezip
  • 378
  • 3
  • 5
  • 10
MABC
  • 205
  • 1
  • 7
  • 2
    I don't understand why this is a requirements change. Is this changing what the user needs? Requirements don't specify how, just what the system does. The system is still providing, as far as I can tell, the same functions. – Thomas Owens Oct 30 '19 at 22:13
  • 3
    Not entirely sure why this question had two down-votes. I would think questions about business and functional requirements would be on topic, especially since there are no close votes. – Greg Burghardt Oct 30 '19 at 22:22
  • Is the signer provider a secondary actor as it is defined (secondary Actors are actors that the system needs assistance from to achieve the primary actor's goal)?. If so, should this secondary actor be added to the use case diagram? Also, now we have a signer provider, whe think about this new situation: if the signer provider dont send our system the signed document, we should notify the user with an error (this situation didnt happen before as our system was the one managing the signing process) – MABC Oct 30 '19 at 22:26
  • In a use-case, you want to capture *what* actors (usually people, users) want to do and *why*, from the business point of view, not what tools, components, or existing systems *you (and/or others)* are considering to make use of in the *implementation*. Essentially, you want to capture their motivation, roughly outline the steps, and understand how the use case fits into the overall business process. Now if there's a business rule that mandates that some external system must be used (e.g., there's a law that enforces it), it makes sense to model that as an actor. – Filip Milovanović Oct 31 '19 at 00:04
  • @FilipMilovanović so if the client demand to use this external system (needed to achieve primary actor goals) we can model it as a secondary actor as it is a requirement, otherwise it is included in design artifacts as it is a design decission but not in the use case diagram or the use case specification. But using a third system made us to think about new kind of errors and think about the interaction between the system and the primary actor when this kind of errors occurs. This interaction lead to a change in the use case specification right? – MABC Oct 31 '19 at 08:46
  • Think of it like this - with use cases, you are not so much trying to create a representation (a model) of the system you are going to build, but you are more interested in understanding the business processes that the system will help with. You don't go to a use case to see how to implement something. It's not "if an IndexOutOfRangeException is thrown, log the error, show error screen", but rather "in case of error, abort the operation". That said, there is some wiggle room in terms of the level of detail - you're the one doing the modeling, so it's up to you to make a judgement call. – Filip Milovanović Oct 31 '19 at 17:54
  • You don't want to go too much into detail and create a complicated mess, but, if including something helps you understand the use cases (usage scenarios) better, include it. In the real world, worrying too much about it leads to analysis-paralysis; you'll get better at it over time. The goal is making software, and making the right software, not the collection of use case diagrams - they are a tool, a means to an end. – Filip Milovanović Oct 31 '19 at 17:54
  • Note that this is done in an agile, iterative setting, so you absolutely can go back and revise the use cases if your need to do so. You can and should add detail to them over time. You may even throw some away. Also, you are supposed to discuss the use cases with the stakeholders to check if what is described makes sense to them, from the business point of view - so you shouldn't express the use cases in technical jargon, but use the language of the domain. – Filip Milovanović Oct 31 '19 at 17:55

1 Answers1

4

The basic business requirement is that documents should be signed electronically. The fact you have decided to use a third party solution does not change the business requirement. At the end of the interaction you have a signed document, thus satisfying the business requirement.

This changes your functional design for sure, but no changes need to be made for the business requirements.

Your use case diagrams would need to be updated. Utilizing a third party provider for signing documents will affect scope, but I would think it should not increase scope. I would assume using the third party provider solves more problems than it introduces, so it should decrease scope. If using this solution is an increase in scope then either the initial estimate of scope was way off or you should roll your own solution for digitally signing documents, because this other solution is costing you more.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • Using a third party solution means maybe there are more kind of errors when doing the use case that ends with the document not being signed. Also it means moving the responsability of our system to the third party, is not this a change in the scope of the system? Should the clients and the users not be aware of this when we agree with them the scope of the system? – MABC Oct 30 '19 at 22:31
  • @MABC: a change in scope does not necessarily mean there is a change in requirements. It's a change in scope. – Greg Burghardt Oct 30 '19 at 22:38
  • The requirements are the agreement with the users and client about what the system is supposed to do (not how it does). Moving the responsability of the system to a third party, is not a change in the requirements? Is not the scope of the system part of the requirements? How the client will be aware the responsability of our system has been moved to a third party, or do you think the client should not be aware of this? – MABC Oct 30 '19 at 22:41
  • @MABC: elaborated on my answer. – Greg Burghardt Oct 30 '19 at 22:44
  • 1
    @MABC Phrase this another way. Does moving the responsibility for signing the document from the Document class into the DocumentSigner class change requirements? *No* Does it change implementation? *Yes*. Will you need to update the requirements? *No*. Should you update the solution overview? *Yes*. The same for a Service that the end user does not themselves engage with. On the other hand, if the customer is demanding that you use this service, then it is a requirement. – Kain0_0 Oct 30 '19 at 22:46
  • 1
    @MABC It seems like your definition of "system" may be far too narrow. I'd look at that. The system may not just be the thing you build, but also include some of the integration points as well. Effectively, the third-party signing service is part of the system that provides user value. It's all about defining boundaries. – Thomas Owens Oct 30 '19 at 22:47
  • @Kain0_0: even then it still isn't a requirement. It's a non negotiable implementation detail. The requirement might be that the client wants to utilize an existing single enterprise-wide system to digitally sign documents. – Greg Burghardt Oct 30 '19 at 22:52
  • @GregBurghardt but if using a a external system as a third party provider introduces new paths of errors when performin the use case, thinking and agreing with the users and client how the interaction between the system under construction and the users will be in this cases (for instance the system will notify about this kind of errors to the user) is part of the requirements. I guess updating the specification of the use case is affordable in this kind of situations. – MABC Oct 30 '19 at 22:57
  • @Kain0_0 answer is in my last comment – MABC Oct 30 '19 at 22:59
  • 1
    @MABC what can the user do about those errors? Beyond some high level categorical errors like: Timed out, not authorised, failed to sign. What else could you possibly communicate to the user that they could then reasonably respond to? – Kain0_0 Oct 30 '19 at 23:27
  • @Kain0_0 maybe it can invoke again the use case or it can contact directly with the signer provider – MABC Oct 31 '19 at 08:53
  • @MABC, that is no different if the signing is provided in-house and considered part of the system you are building. – Bart van Ingen Schenau Oct 31 '19 at 09:16
  • @BartvanIngenSchenau if the signing is provided in-house we dont notify the primary actor about errors like "could not contact with the signer provider", cause there is not any signer provider involved. – MABC Oct 31 '19 at 09:49
  • 1
    @MABC: Are you sure the design can't include an in-house signing provider running as a separate (micro-)service. – Bart van Ingen Schenau Oct 31 '19 at 10:29
  • @BartvanIngenSchenau we can design the system as it has to manage the sign process (wether it is a separate service or not) or we can use an existing provider. We choose to use an existing provider cause good reasons and realize we have to think about new scenarios because this design decisión, and how this scenarios impact in how the system interact with the users. – MABC Oct 31 '19 at 10:44
  • 1
    @MABC, my point is that your choice for an external service provider does not change the error scenarios that could occur, because the same kinds of errors can occur with an equivalent design where the service is provided by a component within the system boundary. – Bart van Ingen Schenau Oct 31 '19 at 10:51