(S.2) Functionality

[mosser]

This is the bulk of the System book, describing elements of functionality (behaviors). This chapter corresponds to the traditional view of requirements as defining "what the system does**”. It is organized as one section, S.2.n, for each of the components identified in <>, describing the corresponding behaviors (functional and non-functional properties)

[mosser]

We might want to refine the requirements, as the instructions allow for more space: write up to four functional requirements per component, and two non-functional requirements (1-2 sentence per requirement)

[mosser]

• Awesome to have identified requirements!
• Maybe we should go for a bullet list or table layout to save space and make the document more readable.
• S2.1 / Patron manager
  • We might need something related to patron adminsitration (for staff). this might have higfher priority than password recovery.
  • NF: sufficient storage/capacity based on the expected number of patrons? Security/privacy of patrons private info (what to store, how to protect it)
  • 2.1.6 looks related to "accessibility". Should we mention it (bigger goal, compliance with SAS-like standards)?
• S2.2 / Menu provider:
  • Is menu related to the complete menu, or only to the meal boxes
• S2.3 / Order Manager
  • Is 232 part of our scope? Is ATCO sending orders to kitchen (as we have an assumption that we are not integrating with the firebird internal system)?
  • Not sure 236 is a nun-functional requirement
• S2.4 / Billing:
  • We should limit to 4 according to instructions
  • 241: are we providing the interface, or are we redirecting to the payment gateway?
  • 242: same. As this is an internal stuff from Mac, it might be more "artisanal"
  • 243: still unclear who is the main actor here. Admin Staff, or Restaurant one?
  • 244: still unsure this is in scope
  • NF: maybe security should be a goood candidate here for NF

[t-chiang]

Use either List or Table formatting for requirements

[mosser]

S21 Patron Manager

• Functional:
  • F212: copy of S211
  • F213: without losing and points -> ~and~ ?
  • F215: login information -> credentials ?
• Non-functional:
  • Replace NF_211 with something related to security (password must be encrypted?, communicaiton?)
  • Merge NF_212 and NF_212 into something related to accessibility?

S22 Menu Provider

• Functional:
  • global: make explicit we're only talking about Meal boxes and not regular food offer from The Firebird ?
  • F224: is this a responsbility of Menu, or of Order?

S23 Order Manager

• Functional:
  • F232: this should only be the case for meal boxes, right?
  • F233: This willl ...: 2 requirements in one, breaking up atomicity.
• Non-functional:
  • NF_231: what if user uses web app?
  • NF_232: too fuzzy. I'd replace it with something related to compliance with accounting rules for internal payments at Mac.

S24 Billing

• Functional:
  • F243: Is "using department num,ber and faulty" part of billing or part of ordering?
• Non-functional:
  • NF_211: sounds functional (and optional) to me
  • Maybe we should add something related to the security of communication for payment info (e.g., encryption)

Instructions asks for 4 functional requirements (main ones). We have 6. I'd merge F_241, F_242 and F_243 into one single.

[t-chiang]

S21 Patron Manager Functional: F212: copy of S211 -> Removed F213: without losing and points -> and ? and -> any F215: login information -> credentials ? updated Non-functional: Replace NF_211 with something related to security (password must be encrypted?, communicaiton?) Merge NF_212 and NF_212 into something related to accessibility? - Not sure which requirements to merge for accesibility here? Edit: Decided to merge readability into menu manager to make space for more security requirements

[t-chiang]

F224: is this a responsbility of Menu, or of Order?

Decided that it is the responsibility of Menu to transition to Order

[t-chiang]

S23 Order Manager Functional:

• F232: this should only be the case for meal boxes, right? -> Updated with condition
• F233: This willl ...: 2 requirements in one, breaking up atomicity. -> Split up requirements. Second requirement is about when food is ready for pick up instead of cooking complete in the event student selects pre-made mealbox

Non-functional: NF_231: what if user uses web app? -> no push notification unless they have account with phone? Or do we want to enable email alerts as well? NF_232: too fuzzy. I'd replace it with something related to compliance with accounting rules for internal payments at Mac. -> Set to comply with accounting regulations set by McMaster University, the Ontario Government, and the Government of Canada (Tax stuff)

[t-chiang]

S24 Billing Functional:

• F243: Is "using department num,ber and faulty" part of billing or part of ordering?

Non-functional:

• NF_211: sounds functional (and optional) to me -> Removed
• Maybe we should add something related to the security of communication for payment info (e.g., encryption) -> Added compliance with tax regulations

Instructions asks for 4 functional requirements (main ones). We have 6. I'd merge F_241, F_242 and F_243 into one single. -> payment processing is very different for customers vs. restaurant manager. I think they should be two different requirements

[mosser]

• rewrote NF221 as accessibility (which actually conflicts with NF222, interesting case)
• rewrote NF241 as secured communication with payment partners.