• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Part 2 Use cases

 
Ranch Hand
Posts: 198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

4 main use cases description only states customer not TA even though in UC diagram they have shown both TA/Customer using the same use case.

I feel some UCs should have some alternative flows for TA since I feel TA will have to do something more to fulfill the basic requirements like search customer (Unless TA is just acting like customer on swing side where one swing app will be analogous to web session and TA will not be able to handle multiple customers in one shot.)

What would be the safe approach.

1. Should I assume that same UC flow as given in assgn will be used by TA ?I feel this will be a crude but easy way.
2. Add alternative flow to use case to make TA more sophisticated.Not sure if this violates requirements.


Any views?
 
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ajai,
I would suggest go with your first option and document it.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic