Online "Book Flights" facility for an airline

As we begin Part 5 , we have:

Rule Statements

RS8. Each flight booking request must specify exactly one departure date.
RS9. Each flight booking request for a return journey must specify exactly one return date.
RS11.  A flight booking request for a one-way journey must not specify a return date.
RS12.  Each flight booking request must specify exactly one origin city.
RS13.  Each flight booking request must specify exactly one destination city.
RS14.  Each flight booking request must specify exactly one number of passengers.
RS15.  Each flight booking request must specify at most one frequent flier membership.
RS16.  Each flight booking confirmation must specify at least one passenger name.
RS17.  Each flight booking confirmation must specify exactly one payment arrangement.
RS19.  The departure date specified by each flight booking request must be no earlier than today.
RS20.  The return date (if any) specified by each flight booking request must be no earlier than the departure date specified by that flight booking request.
RS21.  The origin city specified by each flight booking request must be one of the cities served by the airline.
RS22.  The destination city specified by each flight booking request must be one of the cities served by the airline.
RS23.  The destination city specified by each flight booking request must be different to the origin city specified by that flight booking request.
RS24.  The number of passengers specified by each flight booking request must be no less than one.
RS25. The number of passenger names specified by each flight booking confirmation must be equal to the number of passengers specified by the flight booking request that gives rise to that flight booking confirmation.
 

Note that "number of" is styled as part of the term number of passengers in rule statements RS24 and RS25 but also as a keyword (as number of passenger names) in RS25.  While number of passengers is a defined term for a data item that is used in a flight booking request transaction, passenger name also refers to a data item which appears more than once in a flight booking confirmation transaction, but there is no "number of passenger names" data item as such.  In other words "number of" in number of passenger names is a set function referring to the cardinality of a data item rather than a data item itself.

RS26. Each flight booking request must specify whether or not the passengers must travel on the specified dates.
RS27. Each flight booking confirmation must specify whether or not the paying party wishes to include a CO2 offset payment.
RS28. Each flight booking request must specify whether it is for a return journey, a one-way journey or a multi-stop journey.
RS29. Each flight booking confirmation must specify whether the payment is a credit card payment or an electronic transfer payment.
RS30. Each flight booking confirmation must specify a mobile phone number, an e-mail address or both.
RS31. Each flight booking confirmation must specify a credit card or an electronic transfer payment receipt but not both.
RS32. Each flight booking confirmation must specify exactly one of the following: a postal address, an e-mail address or a fax number.
RS34. Each flight booking confirmation must specify exactly one of the following:
• a mobile phone number; or
• an origin city daytime phone number and
   an origin city evening phone number.
RS35. Each flight booking confirmation must specify exactly one of the following:
• a mobile phone number; or
• an origin city daytime phone number and
   an origin city evening phone number and
   a destination city daytime phone number and
   a destination city evening phone number.

Fact Types

FT1.  flight booking request specifies departure date
FT2.  flight booking request is for journey
FT3.  return journey is a category of journey
FT4.  flight booking request specifies return date
FT5.  one-way journey is a category of journey
FT6.  flight booking request is for return journey
  (derived from fact types FT2 and FT3)
FT7.  flight booking request is for one-way journey
  (derived from fact types FT2 and FT5)
FT8.  flight booking request specifies origin city
FT9.  flight booking request specifies destination city
FT10.  flight booking request specifies number of passengers
FT11. flight booking request specifies frequent flier membership
FT12.  flight booking confirmation specifies passenger name
FT13.  flight booking confirmation specifies payment arrangement
FT14.  airline serves city
FT15.  flight booking request gives rise to flight booking confirmation
FT16. passenger must travel on the specified dates
FT17. paying party wishes to include a CO2 offset payment
FT18. flight booking request is for return journey
FT19. flight booking request is for one-way journey
FT20. flight booking request is for multi-stop journey
FT21. payment is for flight booking request
FT22. credit card payment is a category of payment
FT23. electronic transfer payment is a category of payment
FT24. flight booking confirmation specifies mobile phone number
FT25. flight booking confirmation specifies e-mail address
FT26. flight booking confirmation specifies credit card
FT27. flight booking confirmation specifies electronic transfer payment receipt
FT28. flight booking confirmation specifies postal address
FT29. flight booking confirmation specifies fax number
FT30. flight booking confirmation specifies origin city daytime phone number
FT31. flight booking confirmation specifies origin city evening phone number
FT32. flight booking confirmation specifies destination city daytime phone number
FT33. flight booking confirmation specifies destination city evening phone number

Rule Statement Templates

RT1.  Each <term 1> {<qualifying clause>|}
must <verb phrase>
<cardinality> <term 2>.
  (from which rule statements RS8, RS9, and RS12 to RS17 inclusive can be generated)
RT2.  {A|An} <term 1> {<qualifying clause>|}
must not <verb phrase>
{a|an} <term 2>.
  (from which rule statement RS11 can be generated)
RT3.  The <term 1> that <verb phrase> each <term 2>
must be
<predicate>.
  (from which rule statements RS19 to RS24 inclusive can be generated)
RT4.  The <set function> of {the|} <term 1> that <verb phrase> each <term 2>
must be
<predicate>.
  (from which rule statement RS25 can be generated)
RT5. Each <term> {<qualifying clause>|}
must specify whether
{{or not|}{it|the <term 1>} <verb phrase> {<article> <term 2>|}|
    {it|the <term 3>} <verb phrase> <or-list>}.
  (from which rule statements RS26 to RS29 inclusive can be generated)
RT6. Each <term 1> {<qualifying clause>|}
must <verb phrase>
{a|an} <term 2>, {a|an} <term 3> or both.
  (from which rule statement RS30 can be generated)
RT7. Each <term 1> {<qualifying clause>|}
must <verb phrase>
{a|an} <term 2> or {a|an} <term 3> but not both.
  (from which rule statement RS31 can be generated)
RT8. Each <term 1> {<qualifying clause>|}
must <verb phrase>
<cardinality> of the following: <or-list>.
  (from which rule statements RS32, RS34, and RS35 can be generated)

Rule Statement Sub-templates

ST1. <cardinality> ::=
  {exactly|at {least|most}|at least <positive integer> and at most} <positive integer>
ST8.  <predicate> ::=
  {<value set predicate>|<match predicate>|<range predicate>|<equality predicate>}
ST3.  <value set predicate> ::=
  one of the <term> {<qualifying clause>|}
  (used in rule statements RS21 and RS22)
ST4.  <match predicate> ::=
  {the same as|different to} the <term> {<qualifying clause>|}
  (used in rule statement RS23)
ST5.  <range predicate> ::=
  {no|} {greater|less|later|earlier} than {<literal>|the <term> {<qualifying clause>|}}
  (used in rule statements RS19, RS20, and RS24)
ST9.  <equality predicate> ::=
  {not|} equal to {<literal>|the <term> {<qualifying clause>|}}
  (used in rule statement RS25)
ST6.  <qualifying clause> ::=
  that <verb phrase> {a|an|each|that|the} <term>
{<qualifying clause>|}
ST7.  <set function> ::=
  {number|total|maximum|minimum|
        average|mean|median|mode}
ST11. <article> ::= {a|an|the}
ST15. <or-list> ::= {<simple or-list>|<complex or-list>}
ST12. <simple or-list> ::=
  {<article> <term 1> or <article> <term 2>|
    <article> <term 3>, <simple or-list>}
ST14. <complex or-list> ::=
  • <article> <term 1>|<simple and-list>}; or
    {• <article> <term 1>|<simple and-list>}|<complex or-list>}
ST13. <simple and-list> ::=
  {<article> <term 1> and <article> <term 2>|
    <article> <term 3>, <simple and-list>}


Note

The font and colour conventions used in these rule statements, fact types, and templates reflect those in the SBVR, namely:  underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.