I have the following question , I am writing a use cases document were each use case consists of the following sections (pre-condition, detailed description, alternative flow, exception flow , post-condition)
I need to write use case/s for the approval process, where in my system a request will be send to the manager to either approve or reject a registration request , so I wrote the one use case were in the detailed description section I wrote the flow for approving the registration request and in the exception section I wrote the reject the registration request and in the alternative flow I wrote approving the registration request through the email,, so is this right or I should have wrote two use cases one for approving the request and another use case for rejecting the use case.
thanks
From your description, it sounds like one use case is the way to go since the registration process/activity is one process with multiple outcomes.
- Adrian
John:
You want to know how you should partition (i.e., divide up) your system. Only data flow diagrams actually guide you through a proper partitioning. Lack of partitioning guidance is a big hole in the UML (which includes Use Cases).
Tony
John
One use case is the right way to go here, however, is a use cas sufficient or even the best way to go? Would it be nicely augmented with a little swim lane diagram? Would a context diagram show the flow better?
Who is your audience? Developers? A system designer? What do they say works best for them?
I recently saw a similar case where the two outcomes of pass or fail were described as two separate reqirements statements. It doesn't make sense, not becasue it's one scenario with two outcomes, but because when it's implemented it will be one developer piece of work.
John-123,
Use cases need actors. I like to write the usecases from the actors perspective. Doing your requirement requires at least two actors (requestor, manager) each with a "goal" (seek registration and approve registration). Now Browncraig suggests that a process diagram (activity or BPMN diagram) with swimlanes could assists to give the reader (developer, manager) a context. Why? Because usecases are disjoint; and unless they are linked by some context (activity diagrams etc), they are hard to follow. I'd do a context and write two use cases.
warm regards,
K
brought to you by enabling practitioners & organizations to achieve their goals using: