help me please

[joan matos]

Use cases are the first devices to keep in mind when designing a system?

Why??

[RoyC]

Can you explain why you are asking the question? What is the problem you are trying to address? (And therein lies a clue to the answer you are seeking!).

[qwerty]

Because use cases tell why a system is needed at all. Without a use case there is no need for a system. Though many systems seem to be designed without a use case.

q.

[joan matos]

Can you explain why you are asking the question? What is the problem you are trying to address? (And therein lies a clue to the answer you are seeking!).

That's a question worth 10 points

[joan matos]

Because use cases tell why a system is needed at all. Without a use case there is no need for a system. Though many systems seem to be designed without a use case.

q.

Thank you

[g.makulik]

I'd start even earlier with collecting requirements 1st and provide detailed use case descriptions to fulfill these ...

Just my 0.02 EUR
Günther

[Sunshine]

I'd start even earlier with collecting requirements 1st and provide detailed use case descriptions to fulfill these ...

Just my 0.02 EUR
Günther

I'd start even earlier than that by asking why is there a need for change. I'd use a motivation model to map stakeholders, drivers, assessments of those drives and then derive goals and high level requirements/features. From that the use cases can be identified and worked through in detail showing what the system is going to be used for.
Well thats my two cents worth  

[qwerty]

Hen and egg? I could ask: why on earth do we need all that stuff? Wouldn't it be better to go back into the water. We never should have left it, I guess.  

But then, a lot of systems were designed (?) and implemented without use cases. So actually there isn't always a need for requirements, use cases and all that stuff as long as someone pays the bill.

q.

[manfredw]

I look at it hat way:

Use cases are essentially stories that the customer tells you.
They describe who triggers a functionality of the system and how.

Requirements tell what the customer needs. they describe what the system shall be able to fulfil.
Functional requirements may resemble use cases, so sometimes customers mix both and its up to you to separate them.

In my experience it depends on the customer what comes first.
Some may start with use cases and tell you
"in my future calendar system a user can log in to check his appointments" that'd be translatable to a use case "Check Appointment" with an <<include>> connector to another use case "LoginCalendar"

Other customers could start to give you a list of the requirements
"The Calendar must be secured by a login procedure" and
"The Calendar must be able to hold appointments" etc...

In either case you'll have to find the missing part so that you can connect the requirements to the use cases and build your model from there (domain model, activities, states etc.)

HTH,
cheers
Manfred

[g.makulik]

In either case you'll have to find the missing part so that you can connect the requirements to the use cases and build your model from there (domain model, activities, states etc.)

Good point! For my actual environment (but also experienced in other domains) customers or even product management department don't tell you very much about their requirements or use cases in advance for a new product (or variant). They'll always complain after the 1st release is done   ...

[manfredw]

They'll always complain after the 1st release is done...

I feel your pain  

[AndyJ]

I've fallen into a method where the domain model is created while building the use cases.

For example: the customer has to log in. (Use Case: Log In)

The Customer fills in their Log in Details

Suddenly you have a need for a class on the domain model which explains what Log in Details are.

e.g. Class: LogInDetails
Attribute: UserName
Attribute: Password

 

Wherever details like that are needed, they appear in the domain model, and relevant parts of the domain model are included in the printed form of the use case.

Andy

[AndyJ]

I'd also suggest that use cases may be appropriate when designing other systems (i.e. non-ICT systems).

Examples:
TV Dinner
The cook selects a package from the freezer
The cook places the package into the microwave
...

Hmm... if this is the most common "use case" for the microwave, maybe it should be located near the freezer?

Washing
Laundry basket is placed near the washing machine
Washing is selected by colour and fabric to make up a "load"
Load is placed into washing machine
...

Hmm... maybe there should be a place for the washing basket, and a benchtop (or some other facility) near the washing machine to facilitate sorting of loads?

 

Andy

[qwerty]

I've fallen into a method where the domain model is created while building the use cases.

For example: the customer has to log in. (Use Case: Log In)

The Customer fills in their Log in Details

Suddenly you have a need for a class on the domain model which explains what Log in Details are.

e.g. Class: LogInDetails
Attribute: UserName
Attribute: Password

 

Wherever details like that are needed, they appear in the domain model, and relevant parts of the domain model are included in the printed form of the use case.

Andy

Isn't that obvious? When you synthesize UCs you step on with defining collaborations realizing the UCs. And these show how the single classes of the domain model collaborate. That will automatically force you to complete the domain model. Vice versa the domain model influences the way you layout your UCs.

q.

[AndyJ]

It seems obvious to me, but I've seen many examples where the details are crammed into the scenario steps, and no domain model is built.

Andy