• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Contraddictory prepare use case requirements that must be addressed

 
antonio gallo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I'm starting working for the SCEA project and I have some doubts that I'd like to discuss with you.
If you look at the Prepare Itinerary Use Case Specification, there's a line:

"System responds with the selected flight priced and alternative flights if less than selected and within one hour of departure and return times."

This text is misleading for the following reasons:

1) If you look at the interview, FBN uses a flat price scheme per destination, so the price should not depend on the time you take the plane and so there should not be cheaper alternative flight as far as the source and destination airport are the same.
2)How can the system calculate the price of the flight (the word less than selected means that a price is calculated) if the price itinerary use case is executed only at the end, after the user has selected the seats (and so the class) ?

Moreover, the use case refers to a one way or round trip flight and not to an itinerary (I suppose that also the terms are misused in the use case).

If we want to find an explanation for point 1, given it for granted that two flights going from point A to point B will ALWAYS have the same fare, we have to suppose that the system displays alternative flights if a different route exists for an itinerary in a given time frame. We can go from A to B also passing from C or D and in this case the price wil be different being different the mileage's count.

However, point 2 is more complicated to address.

If you lock at the modern airline companies, for each source and destination airport, they usually show a list of itineraries including number of stops and the list of flights (which can be more than one when a lay over is to be performed). Each segment is priced and you have to choose the solution as whole. You can not choose a flight of a solution (considered as an itinerary) and a flight of an other one.
The price itinerary can than calculate the whole price, by summing the price of each flight, according to imposed taxes and selected fly classes.
In the light of these considerations, I down't know how to manage the alternative flights "less than the selected ones" (if the itinerary is to be priced at a later point) and I'm thinking of skipping this point because I don't know how to collocate it.
Moreover, returning alternative flights would require some cache mechanism on the client or on the business layer (in order to compare user choices with the total set of the possibilities that a Customer may have discarded.
Now, since all these doubts and misunderstandings can impact the design of the system in any way... are there any thoughts?
 
Santiago Urrizola
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


I totally in agreement with you, this is the way operate the companys, it gives you a collection of "itinerary alternatives" with the flights of each segment of each of the itinerarys (you cant change this).
So user must pic up one itinerary (with all the flights) and then the system respone whith alternatives to depart and retun flight (1hr fligths alternatives).
This is the real world (or the companies where i buy tickets here)

But the question here is if you can change the use case to that?
i preraring the part II in this momento and have problems with this point to.

opinions ?
[ May 30, 2006: Message edited by: Santiago Urrizola ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic