search

AaravShaurya / COMP350-Team-Infinity

Repository for development of web app that allows the university to securely and seamlessly conduct student council elections
0 stars 0 forks source link

Need to have a detailed description of the process end to end #4

Open srikumarks opened 3 days ago

srikumarks commented 3 days ago

Your system design needs to be clarified as a sequence of steps starting from a student signing in to the final point when the student's vote gets registered in the system. You'll have to be as detailed as possible in this description and break down the steps into sufficiently "atomic" units of activity. By that, what I mean is if a student does some action purely within the user agent (i.e. the browser), that can all be lumped into a single step, but the moment data crosses over to the server, that would need to be broken into a separate step and you'll have to describe what all data moves from client to server (or vice versa). Similarly, within the server environment, you have your "backend process" and the database.

Once you make this detailed picture based on your current understanding, you'll have to critically look at it and ask "what assumptions are we making about this step in articulating it this way and how could those assumptions be broken?". Then you'll have to put in adequate mechanisms to protect against the process breaking due to those broken assumptions.

For example, you described the student "signing in" by giving their email address which results in a link being sent to their email after validation of the email address. There are many steps here that need to be broken down -

  1. Student supplies email address and clicks "sign in". A few possibilities here - a) student is not a voter, b) student is a voter but has not voted yet, c) student is a voter and has already voted. What happens in each of these scenarios?
  2. (Take scenario 1b) Email ID is validated against permitted pattern.
  3. Email ID is checked against voter list.
  4. Construct and send out validation link. A few possibilities - a) Sending succeeds, b) Sending fails, c) Sending succeeds, but lands in spam and student proceeds to signin again,
  5. (Take scenario 4a) Student clicks on validation link. A few possibilities - a) Student clicks link once, b) Student clicks same link multiple times without voting, c) Student forwards email to another student and asks them to vote, d) Student accidentally deletes validation email, e) Student has suddenly been banned from voting. .... and so on.

I will be weighting this analysis fairly significantly since this is the crux of your application.

srikumarks commented 3 days ago

One way to go about this is to first consider what is called the "happy path" - where everything is well. Then you critically look at all the things that can go wrong either inadvertently or deliberately and address those and iterate.

When describing a step, do not labour on details that are expected to be broadly known. For example, it is sufficient to say "the server sets a cookie on the client with XYZ information" without detailing it like "the service handler uses the Set-Cookie header with XYZ info as value in its HTTPS response which the browser stores in its local cookie store associated with the app's origin".