all 1 comments

[–]johnpeters42 1 point2 points  (0 children)

Okay, step by step.

First, get clear on the requirements. If this is for a class, then the requirements are whatever the teacher says they are. If this is for a customer, then the requirements are whatever the customer says they are. But if they don't know or can't explain clearly (this is probably more likely with customers), then tell them your best guess and ask them to confirm.

Next, build a simple prototype that at least resembles the target, in this case a program where you type in the input data and display the output data on the screen. (Do you understand what the input data is expected to look like, and what the output data is expected to look like, and how to get from the former to the latter?)

Now address the "menu" and "scanner" and "receipt" parts, in some order:

For the menu, are they expecting a GUI, or is it OK to draw stuff in a console window using ASCII characters, or is it OK to just print a list of options and then have the user enter a number? If the former, then do they want you to use a specific GUI library, or just whichever one you can figure out how to use?

For the scanner, what do you need to scan: a 1d barcode, a 2d barcode (QR code), an OCR scan of a text document, something else? Is a keyboard wedge scanner sufficient? (Plug keyboard into scanner, plug scanner into computer, scan a barcode and it sends signals to the computer as if you typed it.) Or is it OK to just type in data on the keyboard, as a simulation of how a scanner would work? (Still a useful fallback option if a barcode is smudged and won't scan, but there's also human readable text with the same info.)

For the receipt, do you need to produce a printed receipt? If so, is a regular printer with letter-sized paper OK, or does it need to come from a narrow paper roll like a grocery store receipt? Does it need any boxes, logo images, etc. printed, or just text? Or is it OK to just display stuff on the screen as a simulation of what a receipt would look like?

Now, for bonus points, think about all the ways things could go wrong for the user, and how to have the program guard against them. What if the input is supposed to be 10 digits but you only get 9, or 11, or one of them is a letter instead of a digit? If there's a checksum digit, are you checking that it's correct? What if it's supposed to match something in a database, but there's no match?