aash.00
Badges: 4
Rep:
?
#1
Report Thread starter 3 years ago
#1
Hi guys, I was thinking of doing a database management system for a video game store where people could buy/sell games. I think python, sqlite and tkinter ( for GUI) will be enough for this but I am not sure. Any advice on it? and also how to start the project?
0
reply
winterscoming
Badges: 19
Rep:
?
#2
Report 3 years ago
#2
(Original post by aash.00)
Hi guys, I was thinking of doing a database management system for a video game store where people could buy/sell games. I think python, sqlite and tkinter ( for GUI) will be enough for this but I am not sure. Any advice on it? and also how to start the project?
That sounds reasonable for a python GUI app with a database.

In terms of getting started, you can't build a system until you know what it is that you're building, so always start out by looking at your requirements and aim to produce a specification describing the system from your users' point of view.

Here's a few things to consider:
  • Do some research on real world retail systems to see what kinds of capabilities they have and to gather ideas for your system. Retailers often use software known as Enterprise Resource Planning (ERP) Systems - you'd probably only need a small sub-set of the things a fully-blown ERP system can do, but it's a good place to start
  • Write a problem statement - i.e. a very high-level description of the problem(s) which need to be solved for the people who would be using the system, and then define the goals/objectives that the system needs to achieve to solve those problems.
  • Identify each of the types of users who would be using the system and use this to look at the problem from their point of view as a way of being able to define requirements which are relevant to those types of users. It could help to describe a bit about those users (e.g. a "persona") - who they are and what their role is, what they need the system to do and why.
  • Define a list of functional requirements by considering use cases for each of those users, For example the Manager might use the system for monitoring sales, whereas a Sales Assistant may only need to sell or refund items, and a customer might need to be able to browse items in stock or place a reservation, etc.
  • Define acceptance criteria for each of your functional requirements - i.e. a detailed set of descrptions or bullet points about how a user will actually use the system and what data they will need to use (either data to input or data they need to see). For example, what steps and data will a sales assistant need to sell an item? How will a manager generate an inventory report? Remember to keep the requirements user focused and don't describe the underlying implementation, e.g. don't include any detail about what may or may not be happening with the database or queries, or anything about the code or Tkinter controls - that kind of design/implementation detail should not be included here. Acceptance Criteria should make sense for a user who has no idea about databases or programming.
  • Draw some UI mockups for each screen in the system - this could be a bunch of pen+paper drawings, or a whiteboard photo, or using a drawing tool. Try to include as much detail as you can about what input fields exist, the data being displayed, buttons and what their purpose is for the user, any messages which might appear, what the users' workflow might look be, UI navigation, etc.
  • Also think about non-functional requirements - e.g. should it run on a desktop PC? should there be a separate front-end UI app which talks to a back-end service over a network?


Once you've done all of this you should be in a good position to start identifying the entities which exist in your system, their attributes and their relationships. It's useful to review all of your requirements at this point and identify any strong nouns which could potentially become Entities (tables in your database), as well as data which 'belongs to' (depends on) those entities.

Think about your requirements and how the Entities need to relate to each other in order to make sure you can satisfy those requirements - In particular, think about where you might have one-to-many or many-to-many relationships - If you're not sure what the relationships should look like, refer to your requirements and UI mockups to think about the kinds of queries you might need to get you need in and out of your GUI.

Getting the structure of your SQL database is important before you go ahead writing the Python code. The code you write will depend upon the data you read/write to/from the database, so its structure will affect that code, and hopefully make it easier to write that code if you get the structure right.

Always keep your users in mind - whenever you're not sure what to do, look at the program from their point of view and ask yourself whether something makes sense. Think of it like roleplaying in order to figure out how the system needs to work - Your user's "persona" is the best guide you've got for deciding whether some part of your system works in a way which makes sense and whether it would be usable - thinking about how that user would interact with the software can make it much eaiser to spot whether something is right or wrong.

Lastly, and most importantly, always keep your mark scheme in mind. Make sure that everything you're doing is working towards getting those marks. Remember that most of your marks will be from your report and write-up, so not only is it much easier to write the system after you've spent a lot of time thinking about the requirements and understanding how your user(s) will be using the app, but in doing this you'll be able to produce a lot of systems analysis artefacts which will help your report.

Good luck!
2
reply
aash.00
Badges: 4
Rep:
?
#3
Report Thread starter 3 years ago
#3
(Original post by winterscoming)
That sounds reasonable for a python GUI app with a database.

In terms of getting started, you can't build a system until you know what it is that you're building, so always start out by looking at your requirements and aim to produce a specification describing the system from your users' point of view.

Here's a few things to consider:
  • Do some research on real world retail systems to see what kinds of capabilities they have and to gather ideas for your system. Retailers often use software known as Enterprise Resource Planning (ERP) Systems - you'd probably only need a small sub-set of the things a fully-blown ERP system can do, but it's a good place to start
  • Write a problem statement - i.e. a very high-level description of the problem(s) which need to be solved for the people who would be using the system, and then define the goals/objectives that the system needs to achieve to solve those problems.
  • Identify each of the types of users who would be using the system and use this to look at the problem from their point of view as a way of being able to define requirements which are relevant to those types of users. It could help to describe a bit about those users (e.g. a "persona" - who they are and what their role is, what they need the system to do and why.
  • Define a list of functional requirements by considering use cases for each of those users, For example the Manager might use the system for monitoring sales, whereas a Sales Assistant may only need to sell or refund items, and a customer might need to be able to browse items in stock or place a reservation, etc.
  • Define acceptance criteria for each of your functional requirements - i.e. a detailed set of descrptions or bullet points about how a user will actually use the system and what data they will need to use (either data to input or data they need to see). For example, what steps and data will a sales assistant need to sell an item? How will a manager generate an inventory report? Remember to keep the requirements user focused and don't describe the underlying implementation, e.g. don't include any detail about what may or may not be happening with the database or queries, or anything about the code or Tkinter controls - that kind of design/implementation detail should not be included here. Acceptance Criteria should make sense for a user who has no idea about databases or programming.
  • Draw some UI mockups for each screen in the system - this could be a bunch of pen+paper drawings, or a whiteboard photo, or using a drawing tool. Try to include as much detail as you can about what input fields exist, the data being displayed, buttons and what their purpose is for the user, any messages which might appear, what the users' workflow might look be, UI navigation, etc.
  • Also think about non-functional requirements - e.g. should it run on a desktop PC? should there be a separate front-end UI app which talks to a back-end service over a network?


Once you've done all of this you should be in a good position to start identifying the entities which exist in your system, their attributes and their relationships. It's useful to review all of your requirements at this point and identify any strong nouns which could potentially become Entities (tables in your database), as well as data which 'belongs to' (depends on) those entities.

Think about your requirements and how the Entities need to relate to each other in order to make sure you can satisfy those requirements - In particular, think about where you might have one-to-many or many-to-many relationships - If you're not sure what the relationships should look like, refer to your requirements and UI mockups to think about the kinds of queries you might need to get you need in and out of your GUI.

Getting the structure of your SQL database is important before you go ahead writing the Python code. The code you write will depend upon the data you read/write to/from the database, so its structure will affect that code, and hopefully make it easier to write that code if you get the structure right.

Always keep your users in mind - whenever you're not sure what to do, look at the program from their point of view and ask yourself whether something makes sense. Think of it like roleplaying in order to figure out how the system needs to work - Your user's "persona" is the best guide you've got for deciding whether some part of your system works in a way which makes sense and whether it would be usable - thinking about how that user would interact with the software can make it much eaiser to spot whether something is right or wrong.

Lastly, and most importantly, always keep your mark scheme in mind. Make sure that everything you're doing is working towards getting those marks. Remember that most of your marks will be from your report and write-up, so not only is it much easier to write the system after you've spent a lot of time thinking about the requirements and understanding how your user(s) will be using the app, but in doing this you'll be able to produce a lot of systems analysis artefacts which will help your report.

Good luck!

Thank you. This has certainly helped me a lot.
0
reply
X

Quick Reply

Attached files
Write a reply...
Reply
new posts
Back
to top
Latest
My Feed

See more of what you like on
The Student Room

You can personalise what you see on TSR. Tell us a little about yourself to get started.

Personalise

Do you think mandatory Relationships and Sex Education in secondary schools is a good idea?

Yes (358)
84.04%
No (68)
15.96%

Watched Threads

View All