Informal Use Case

July 27, 2014

one comment

In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an “actor“) and a system, to achieve a goal. The actor can be a human or an external system. (by Wikipedia)

 

When we talk about steps;

1.     We are not talking about code, we are talking about actors and responsibilities.

2.     We are not talking about how to perform it, but how will do it.

3.     We are not talking about exception handling, but what are exceptions that we should be aware of.

So, it’s in between we should know who are the actors, but not the actors implementation. We need to understand the relationship between the actors, but not the network channeling and configuration.

We need to know and understand the System, but not the Software.

 

Use Case Card

 

USE CASE #

<Use Case Name>

Goal in Context

< What is the purpose of this Use Case. A UC should have one purpose, it is not a topic cases, but single flow, single case to describe >

Scope & Level

< The Scope that this UC take part of >

Preconditions

< What was the mandatory action that allowed this UC to invoke. Don’t tell a story here just the last action. Remember this is a recursive field. >

Success End Condition

< What is the state that indicate that the UC finished successfully, not what will be next phase. >

Failed End Condition

< What is the state that indicate that the UC finished with failure, not if can continue to the next phase. >

Primary,

Secondary Actors

Primary: < The primary actors >

Secondary: < The secondary actors >

Trigger

< What previous activity / ies came before it. Not button or link click, the activity >

DESCRIPTION

< The successful flow that will describe the UC steps, should be one flow not a tree >

Step

Action

1.

2.

3.

4.

EXTENSIONS

< The exceptions that may occur, per step (if exist) or several exceptions for the same step >

1.a

 

2.a

 

2.b

 

 It’s an atomic case, knows

1. What is the input

2. What is the output success

3. What is the output failure

 

In additional, not as a mandatory informative we can add the next table

RELATED INFORMATION

<Use Case Name>

Priority:

< High / Medium / Low >

Performance

< better to write value in milliseconds than write quick >

Frequency

< better to write the ratio calls/second >

Channels to actors

< Console / Service / Web API and so on >

OPEN ISSUES

< The existing O.I.s>

Due Date

< If known >

…any other management information…

Superordinates

Subordinates

 

As you can see the UC give high level of the component but low and accurate level of the system functionality.

Remember the UC is not about how to do, but What to do.

 

Amour Shmuel

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

one comment

  1. garciniaSeptember 27, 2015 ב 06:00

    It’s really a nice and helpful piece of info. I’m happy
    that you shared this useful info with us. Please stay us up
    to date like this. Thank you for sharing.

    Reply