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?.

  • 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, 2019 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. Oct 30, 2019 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, 2019 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. Oct 31, 2019 at 0: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, 2019 at 8:46

1 Answer 1


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.

  • 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, 2019 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, 2019 at 22:47
  • 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, 2019 at 23:27
  • 1
    @MABC: Are you sure the design can't include an in-house signing provider running as a separate (micro-)service. Oct 31, 2019 at 10:29
  • 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. Oct 31, 2019 at 10:51

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.