:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions
* The person is authorized to create a UW ID.
* All existing ID records in the database are valid (meeting criteria in the vision doc).
* The number of collisions when creating ID is finite.
* There are at most 3 given names a person can have. (assumption of the webpage, also an exception of backend system)
* Family names and given names are all ascii characters. (assumption of the webpage, also an exception of backend system)
* Any family names or given names in a valid format can be used (e.g. no ethical check).
* WUIM does not have to validate that the identifying number (SIN, SN, EN, etc.) matches the person. (also an exception for auditing)
* Email alias can have arbitrary length.
* User is always able to answer questions accurately and completely so that the system can determine whether a the person owns the colliding ID.


Exceptions
* One may have no valid ID.
* The ID may be used by other person (e.g. accidentally).
* One may have multiple ID records, e.g. two records with the same name, but one has SN and the other one has EN. The system would not be able to confirm that when creating ID for such user.
* Too many users with the same first name and last name (e.g. >999,999 users with first name "F" and last name "L".
* Full real name is NOT in the format "FamilyName, List Of Given Names"'.
* Date of birth NOT in the format "MM/DD/YYYY".
* User may enter invalid date of birth (e.g. Feb 30th).
* User may enter unreasonable date of birth (e.g. Jan, 1, 1000)
* When creating IDs, the ID maker may be unable to connect to the backend services.
* While interacting with P to decide on a non-colliding alias or User ID, the site generates an alias or an ID but then there is loss of connection and the user gets kicked off the server (hence, the user does not know what their created ID or alias is).


Variations
* User ID is case insensitive.
* Instead of having P create his or her own user ID, we require that P submit all the required information and have IST or administration create userID for P, along with student ID and email if they have not already been created. In this case the required information could be: Full Name, Student ID (if already created), at least 3 pieces of ID from a provided list, SIN being one of them.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions
1.In the world there are at least one student, employee and visitor referred to as Users
2.Users are human beings
3.Users and admins can make mistakes
4.Students, employees and visitors can be Canadians
5.Canadians will have a SIN number
6.Students, employees and visitors can be international
7.International students, employees and visitors may not have a SIN number
8.Every user will have at least one First name and one Last name
9.Every user will have one birthday
10.All users will have access to a computer with internet
11.It is possible for multiple users to have the same first and last name
12.Every student is given a student number
13.Every Employee is given an employee number
14.A user can have both a student and a employee number
15.Users' names could eventually be expressed in the UTF-8 character set
16.Multiple users may access the service at the same time
17.The same user may access the service using different clients at the same time
18.Users can be forgetful about his information
19.A user cannot change his or her birthday
20.Every user will have and provide at least one official identifying number
21.A user may terminate a session without completing all required steps
22.There exists Admins who can view and manipulate data in the system

Exceptions
1.Server can go down
2.Server's connection with outside services (eg. email service) fails
3.Names that are not english may not have direct alphabet correlations
4.If too many name collisions occur, eventually we will run out of valid unique IDs (serial number)
5.Users may have a disability that prevents direct interaction with the service
6.A user may want to change his/her password
7.A user may forget his/her ID and/or password
8.A user may forget his/her ID and/or password and is unable to provide identification
9.A user may change his first or last name
10.A user may wish change information that has errors (e.g. birthday, SIN)
11.A user may obtain additional identifications (SIN etc.) 
12.A user applies for multiple IDs with different official identifying numbers. (e.g. SIN number and passport number)
13.A person may try using brute force to exploit the system to circumvent the intended functionality

Variations
1.WUIM should be able to handle names that are not part of the english alphabet
2.WUIM should be able to scale the number of unique IDs that can be generated if max collisions occur
3.WUIM should be able to be accessible to users with disabilities
4.Don't allow users to create any e-mail alias when the connection with email server is down
5.A user should be allowed to change information that is entered incorrectly 
6.Replicates for data and multiple instances for servers

Questions
1.Shall we revoke an ID after the owner leaves UW?
2.How do we prevent the case where a user applies for multiple IDs with different official identifying numbers?
3.How much accessibility does the service need to provide?
4.Is there a backup server provided?
5.How does WUIM scale the number of unique IDs generated if max collisions occur?
6.What does WUIM do if a user forgets his/her ID and/password and is unable to provide identification?
7.Is the service responsible for creating the email account for the user or simply assigning the address?
8.What should WUIM do if users' information are accidentally released?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions:
A1) We assume that no other software will partially or completely list the confidential information of P.
A2) We assume, the confidential data of P are stored with a hashing mechanism that is difficult to decipher.
A3) We assume the database does not contain any dupe.
A4) We assume the database does not allow competing queries to question the integrity of the data.
A5) We assume personal information, including username and password are secured and inaccessible to unauthorized users even in the code base.
A6) We assume each regular expression has been tested with a maximum length tolerance to avoid DDOS.
A7) We assume each request use timeout to prevent infinite cycle of loading.
A8) We assume P knows how to use a web application.
A9) We assume P is not acting maliciously, i.e not creating multiple IDs.
A10) We assume P has access to the Internet.
A11) We assume P chooses a secure password.
A12) We assume P doesnt use password autofill and do not store password in an unprotected file (electronic or physical)
A13) We assume each time P has finished using the system, P closes the session.
A14) We assume the security information and the password of P cannot be deduced on other websites or database.
A15) We assume the IST team and database owner is not acting maliciously, they will not edit information without prior security check.
A16) We assume when an IST team and database owners leave the company (fired/ retirement / etc.) he loses his privilege access.
A17) We assume the IST team and database owners are aware of security issues and use more challenging username and password.

Exceptions:
E1) The user must quickly use the software without official proof and the IST team approves the temporary assignment of the user.
E2) The information present in the system belong to the same user but it has to change post since, the data need to migrate.
E3) A maintenance takes place in a system related to our software.
E4) There is no more available name corresponding to the restriction of the id of the identifier.
E5) The system suspects several accounts that may correspond to the information entered by the user.
E6) There are duplicates in the database.
E7) The system finds an account corresponding to the identifiers enter but the user is unable to answer these secret questions.
E8) After contacting IST, the team is not able to find an account that meets the identification criteria.
E9) After contacting IST, the team finds more than one account that meets the identification criteria.
E10) There are SIN in the database that do not belong to the account owner because the authenticity check was not made.
E11) P comes back from a long vacant period, he has changed his name and does not remember his secret questions.
E12) P is not satisfied with the user name that was generated and complains.

Variations:
V1) P may suggest is desired username.
V2) P is login on another device, we provide him a new autorization token and reject the previous one.
V3) The system must allow P to migrate from one type of user to another type of user without clashing on personal numbers such as SIN.
V4) The system must allow P to be classified into several types of users or the system must allow to ignore the unique restrictions.
V5) The system must prevent to assign to P an username representing or containing a vulgar word or a derivation of that word or something that could sound like it.

Questions:
Q1) Ps ID creation assumes P has at least one given name.  What is the behavior when P has not given name?
Q2) Does P always have at least one piece of valid identifying information?
Q3) Is P guaranteed to be an authorized UWaterloo person?
Q4) On a collision of P seeking an ID, who already has an ID, the software is to ask questions to decide if P is the owner of the ID.  What questions are to be asked? When were the answers given? Where are the answers stored? How many questions are to be asked?
Q5) The email alias is specified to be a sequence of letters digits and at least one ..  Is there a length restriction on how long the alias can be?  Can the . be at the beginning and end?  How and where are these aliases stored?
Q6) In the case of IDs j9marlow and j9marloi, they both are truncated to j10marlo on the next collision. How are the new collisions handled in this case?
Q7) If there are too many IDs that collide, the 8-character limit will be overrun. i.e. a9999999 -> 10000000 -> .... -> 99999999 -> ???. How, if at all, is this case handled?
Q8) Will P need a password to go along with their ID?  Will this be shared with any other UW services or will this be separate?
Q9) We assume Ps name not to change.  What if P changes family name, forgets their previous ID and tries to create a new ID?
Q10) Is the database being always accessible while the program is in use?
Q11) Are operations in the database atomic?
Q12) Does the database confidential information on P is protected with a hashing method to prevent human being able to read a data dump?
Q13) When a request is rejected by another software, does an error code and explanation are provided?
Q14) Does P cannot be connected on multiple devices at the same time?
Q15) Does server use an existing mechanism to protect the system against brute force attack on a user?
Q16) Does storage have recovery mechanism to prevent malicious change like DROP TABLE?
Q17) How are diacritics characters in names handled? Are only plain text characters allowed?
Q18) Are cosmic rays flipping bits in the hardware considered out of scope?
Q19) What information is required by the interface so that P can create an ID?  The current website requires first name/last name, Waterloo ID and date of birth.
Q20) Will Ps browser be guaranteed to display the correct information? 
Q21) Will Ps browser be guaranteed to send the correct information to the database?
Q22) Does the IST database contain the WUIM information as well?  Does it store the created IDs, the answers to the retrieval questions and the email alias?  If not, what system is WUIM communicating with to store and retrieve this information?
Q23) How is that system authenticated? 
Q24) Does communication between software uses secure protocol? Does it avoid the exchange of raw information?
Q25) Can the system prefix with zeros to add capabilities to the number of available user names?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Annotations:
WUIM b WatIam User ID Maker web site
P b The person who is using WUIM
SIN b Social Insurance Number
UW b University of Waterloo
EN - Employee Number
SN - Student Number

Assumptions:
1. P is a UW student or employee.
2. P knows and can type English.
3. P knows his/her name, date of birth, and SIN (if any).
4. If P is a new student, P knows his/her SN. If P is an employee, P knows his/her EN.
5. P's name, date of birth, SN/EN are the same between Waterloo's system database, offer/employment letter, and user's memory.
6. P has not changed name or date of birth since such information is given to Waterloo. If P changed name or date of birth, he/she knows to use previous information to retrieve WatIam ID.
7. P's internet connection to WUIM is stable and secure enough to send information to the server and receive feedback.
8. Max number of Ps at the same time is reasonable and does not exceed server's capability.
9. P's personal information (name, date of birth, SIN, SN/EN) is not released to anyone other than P.
10. Waterloo ID / Employee ID are unique for each person. 
11. P's personal information can be written in English.
12. Database servers are consistently stable and available in any time.
13. Database cannot be accessed or changed by unauthorized personnels.
14. P will finish the whole WatIam process. 
15. P is mentally and physically healthy so that he/she can access WatIam service.

Exception:
1. As described in Assumption 1, someone who is actually not P may pretend to be P for malicious purposes.
1. As described in Assumption 2, if user receives/remembers wrong SN/EN, he/she cannot retrieve WatIam ID.
2. As described  in Assumption 6, if user changes name, his/her new name cannot be used to retrieve WatIam ID.
3. As described  in Assumption 7, if user's internet is unstable, server cannot receive or send information to P, which is an exception.
4. As described  in Assumption 8, if number of user at the same time exceeds our service's capability, additional users cannot use the service. 
5. As described  in Assumption 9, if an user's personal information is leaked, someone else may retrieve the ID by the forgot password functionality provided by WUIM. 
6. As described in Assumption 10,  two or more P's are given the same Student/Employee number by mistake.
7. As described in Assumption 11, P's personal information cannot be written in English such as special characters.
8. As described in Assumption 14, P is not able to finish the whole WatIam process due to some reasons like power failure, and all his/her inputs may be lost. 
9. As described in Assumption 15, if P has reading disability, WUIM cannot instruct him/her to select email Alias. 
10. If malicious user attack the WUIM server, the website will not be available to users. 

Variation:
1. As described in Exception 1 and 11, we may add more security features such as security questions to enhance data integrity.
2. As described in Exception 8, any characters that cannot be written in English, a similar character will be used.
3. As described in Exception 10, UW has students and employees with disability. So accessibility of the website should be added in the description.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
1.Assumption 	No symbols in the First,Middle, or Last names
2.Assumption 	There can not be more than 10 000 000 students with the same name
3.Assumption 	Everyone has access to the website
4.Assumption	They have a given first and last name 
5.Assumption	Has some type of Identification number, e.g.government issued or waterloo ID.
6.Assumption	All the information provided must be correct
7.Exception	If the site is not able to determine if person (P) is in fact the same person e.g.the government made a mistake and mixed them up, no way to distinguish them only from provided info.
8.Exception	If two people signed up at the same time, and there is no way to distinguish between them (ie. Same Names, Birthday, SIN, SN, and EN), who gets the identification number
9.Exception	Administrators make errors in inputting the information given by the student
10.Exception	The information provided to the student doesn't match what the administrator put into the system
11.Variation	If more than 10 000 000 students have the same name, the system should be able to realize it and add an extra letter, making the student ID 9 letters in total
12.Variation	When the max number of students is reached, an algorithm should be created to detect it and change the pattern of creating IDs (ie. full first name, 1 letter for middle name and 1 letter for last name)
13.Variation	Adding letters instead of numbers for duplicate names would yield in adding a character after 26 names where as with numbers it leads to extra character after 9 names
14.Variation	Student should be able to report problems with identification, in case there are issues during login
15.Variation	If an alumni does not wish to get email sent to them, another person with the same name can be offered the email address

Questions:

1.What happens if there is a social insurance number which is changed after the student gets the watcard?

2.What happens if the student decides to change his/her name after the student has gotten the watcard?

3.Will there be a crash on the website if there is too much traffic?

4.Does leap day count as a valid birthday?

5.Does every opposite of an assumption count as an exception?

6.Is the website supposed to be in this discussion when it is acting as an interface in this case?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions
1) User must be a student, guest or an employee
2) User must have a valid date of birth
3) User information should satisfy all mandatory arguments which include full real name, date of birth and an official identifying number  
4) Two users cannot own the same ID
5) One user cannot own more than one ID
Exceptions
1) A user can be both a student and employee at UW. For example, Teaching Assistants (TA) can have a Student Number and Employee Number (in the duration of their employment at UW). In this case, their UW ID would still remain the same.
2) UW will retain the information and User ID of all alumni. Information will also be retained for ex-employees and students.
Variations
1) A user can be both a student and employee at UW. In this case, their UW ID would still remain the same.
2) User IDs of alumni can be recycled and reused for future students who share the same name. In this case, the previous owner of the ID (alumni) will not have access to this user ID and the corresponding email.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
1. Assumptions
1.1. The user attempting to create an ID is either be a student, an employe, alumni, or a guest that has been permitted by the university to create an ID.
1.2. The user attempting to create an ID possesses some form of acceptable unique identification which they have submitted to put on records.
1.3. The user attempting to create an ID intends to use the ID generation tool as prescribed. (i.e. Not maliciously).
1.4. The user attempting to create an ID is in a state which allows them to complete the ID generation process. (i.e. Conscious and in reasonable health).
1.5. The user attempting to create an ID is in an environment conducive to the completion of the ID generation process. (i.e Stable internet connection, has electricity, reasonably peaceful surrounding). 
1.6. The user attempting to create an ID has access to a device which is capable of accessing the Web Portal interface.
1.7. The user attempting to create an ID has access to their own personal personal information that will be required to complete the ID generation process.
1.8. The device used to access the Web Portal interface is in working condition.
1.9. The device used to access the Web Portal interface is up to date and supports access to web sites through a browser.
1.10. The device used to access the Web Portal interface has the required peripheral input and output devices to facilitate interaction with the Web Portal interface.
1.11. The Web Portal interface provides a reasonably intuitive user interface such that potential users would not require external intervention to complete the ID generation process.
1.12. The Web Portal interface is implemented to support a reasonable array of supported devices and supported browsing environments to facilitate a broad scope of access.
1.13. The Web Portal interface provides reasonable functionality for users with disabilities to be able to complete the ID generation process. (e.g. The HTML includes sr tags which allow for screen readers to aid the visually impaired).
1.14. The IST database has been populated with the details of the user attempting to create and ID, prior to the user actually attempting to create an ID; These details are identical to those specified in the WUIM Project vision.
1.15. The IST database records are are without flaw.
1.16. The IST database is live at all times and is able to accept requests.
1.17. In the process of generating a user ID, the system serializes ID generation to prevent the possibility of a race condition which may generate non-unique IDs.
1.18. In the process of generating a user ID, the the space of all possible user IDs that could be generated is large enough to accommodate all new users during the lifetime of the university.
1.19. If a user successfully creates an ID, then that ID will be unique.
1.20. If a user successfully creates an ID, then that ID forms a one-to-one correspondence with the user.
1.21. If a user successfully creates an ID, then they will not be permitted to create any additional IDs in future.
1.22. If a user successfully creates an ID and subsequently forgets their ID, then no details of other users will be revealed in the ID recovery process.
1.23. If a user successfully creates an ID, then the system will automatically offer to allow the user to create an alias for the ID.
1.24. If a user successfully creates an ID alias, then that alias will be unique.
1.25. If a user successfully creates an ID alias, then that alias will form a one-to-one correspondence with the ID.
1.26. If a user successfully creates an ID alias and then decides to change it, then the system works with the user to find another unique alias.
1.27. If a user successfully creates an ID alias or opts not to create an alias, then the ID generation process is completed.
2. Exceptions

2.1. The user may not possess some form of acceptable unique identification (1.2), resulting in the user not being able generate an ID or perhaps recover an ID.
2.2. The user may not intend to use the ID generation tool as intended (1.3), in which case it is assumed that the system will not generate an ID for them.
2.3. The user may not be in a state in which they are able to complete the ID generation process (1.4).
2.4. The user may not be in an environment conducive to the completion of the ID generation process (1.5), or may not have access to a device capable of accessing the web portal (1.6) (1.8) (1.9) (1.12), or may not have access to a device with the proper input / output support (1.10) to complete the ID generation process.
2.5. The user may not have immediate access to hard to remember personal information (1.7) (i.e. Personal ID serial number). In this case the user may not be able to proceed with ID generation.
2.6. The user may find the user interface unintuitive (1.11), in which case they may not understand how to proceed with ID generation.
2.7. The user may have a handicap that makes the completion of the ID generation process difficult or impossible and cannot be reasonably handled by system functionality (1.13).
2.8. The user may change their name at some point, or change their user status, resulting in inconsistency when recovering an ID or may even result in security breach (1.22).
2.9. The user may become disassociated with the university (1.1), it is then assumed that the user can no longer access functionality such as alias generation, or ID recovery.
2.10. The IST database may not have complete information (1.14) (1.15), which may result in a failure to proceed with the ID generation process.
2.11. The IST database may not be available or does not accept requests as intended (1.16) resulting in a failure to proceed with the ID generation process.
2.12. A bug in the system during ID generation may result in: A race condition when generating new IDs, resulting in the violation of uniqueness requirements (1.17); Improper assignment of an ID, or duplication of an ID, or a user generating multiple IDs resulting in violation of uniqueness requirements (1.19) (1.20); The release of private user information to someone other than the intended user (1.22).
2.13. A freak pop cultural phenomena compels people to change their name to the same name, and then all apply for a user ID at the university in the same academic year,
possibly causing the possibility space for ID generation to be too small (1.18).
2.14. A bug in the system during alias generation may result in cases analogous to that in (2.12).
3. Variations
3.1. The naming convention for ID generation could change in future, allowing for more letters used from the first name, possibly expanding the space of available user IDs.
3.2. IST could collect the users e-mail, along with their other information, and utilize this in ID generation and / or ID recovery to streamline these processes.
3.3. The ID generation process could include a step to choose security questions and a password associated with the ID. This would enhance security for ID recovery and account access.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions
1. The owner is human and not an automated robot trying to break the database
2. The WUIM server is active & running and does not have a power outage
3. To use WUIM, the user interacts with a visual interface and operates the interface by providing input (may change to user is capable of interacting with visual user interface)
4. The owner must provide a SIN, SN, or an EN or any other available official identifying number that can be checked to be valid (using the WUIM ID validation system)
5. The user knows his/her given & family names and date of birth and inputs it into the WUIM system
6. The owner is able to search for and check the availability of aliases in the WUIM system until they can find and select a unique alias
7. The IST Admin personnel will not have malicious intentions with users private data

Exceptions
1. Assumption (2) is also an exception. If the WUIM system is offline, the user will not be able to interact with the system properly.
2. If the user is unable to provide a valid SIN, SN, EN or other identifying number then they will not be able to create an ID in WUIM.
 
Variations
1. If the user is accessing the WUIM system as an administrator, they are presented with an alternate interface, capabilities and privileges.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions

	1.	There exist less than 100 000 people with the same last name and first name initials registered at the university. This will allow the system to include the first name initials and at least one letter of the last name.
	2.	The date of birth cannot be greater than today.
	3.	Each person has at least one first name and a family name.
	4.	The user visits the webpage only to create an ID and/or an email alias.
	5.	There cannot exist two distinct users with the same ID.
	6.	The "other ID" option is only required when a user does not have a SIN or a student/employee ID.

Exceptions

	1.	If the user asks for an email alias that already exists (throw an error message saying that the email alias already exists).
	2.	The user's name contains non-alphabetic characters.
	3.	The user enters incorrect or empty data
	4.	If the user does not correctly complete any of the required fields, do not request to generate an ID. Rather, prompt user an error, asking to complete the input fields with all client-side validation rules.
	5.	The user already exists in the system (throw "user already exists" error).
	6.	The database is not reachable.
	7.	If the user leaves the session incomplete and closes, restarts or refreshes the session (next time she will be treated as a new individual with all fields empty).

Variations

	1.	When a user does have a middle name (only use her first name initial and last name to generate the ID).
	2.	When a user has one or more middle names (only use her first name initial, second name initial and last name to generate the ID).
	3.	When a user's ID matches an existing one (recursively increment the number on the ID).
	4.	When the user's ID increment pushes character length out of the limit (delete the last character of the ID)
	5.	When a user has a student ID, force the user to only use her student ID for identification.
	6.	When a user has a employee ID, force the user to only use her employee ID for identification.

Questions

	1.	What data - regarding a new user - is already provided in the database by the university?
	2.	How does the system prevent a user - who is already registered - by using one form of identification to register again using another form of identification?
	3.	Can an email alias begin or end with a period?
	4.	When creating a personalized email alias, how will the system interact with the user if it's already taken? Should it make some suggestions or just inform the user about the collision?
	5.	How do we prevent a person to use his username and password to login to the system and then create an ID for another person?
	6.	what should be the minimum age of a user, if any?
	7.	Is the "other ID" input (1) a two-input field or (2) one select and one input field?
	8.	Could we ask the user to type in their first and last names ind spare fields?
	9.	Can a name contain non-alphabetical characters or should the system restrict the input to only alphabetical (e.g., should we let the user to change from C6 to an o)?
	10.	Do we assume that the database has no information about the user generating her ID? In other words, does the system check if the information is correct or is this the first time that the data is provided?
	11.	The user logs in the first time using a student/employee number. How about a guest? Further, are the user prompted to fill in her number in the system once again using the frontend (or will it be acquired at the login)?
	12.	Are a user to enter several identification numbers and are the "other ID" only allowed if the other types are not available?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumption:
1. Each user has a unique SIN, SN, EN, or some other available official identifying number.
2. Each user's full real name can be represented in the format of "FamilyName, List Of Given Names". The family name and each given name has at least one alphabet character in it.
3. Each user's date of birth can be represented in the format of "MM/DD/YYYY".
4. The assignment of an ID to P occurs after the assignment of all IDs already in the database.
5. Two different persons' cannot have the same ID and one person cannot have more than one ID. ( this assumption is also an exception)
6. The ID for P is constructed from P's full real name by taking the the first letter of the first given name; the first letter of the second given name, if any; and then all the letters of the family name; with the restriction that the length of the entire ID is no longer than eight characters
7. A person can create an email alias for his/her ID.
8. The email alias is a sequence of letters, digits, and at least one period, ".". 
9. Each such alias must be assigned to at most one ID, and thus to at most one person.
Exception:
1. Two different persons' cannot have the same ID and one person cannot have more than one ID.
2. A person forgot his/her ID should be able to retrieve his/her ID with SIN, EN, SN and date of birth associated with the ID.
3. There are no more available IDs. Since user IDs are at most 8 characters in length, there are a finite number of user IDs available.
4. Each such alias must be assigned to at most one ID, and thus to at most one person.
5. This alias is a sequence of letters, digits, and at least one period, ".".
6. A person creates an ID with a wrong official identifying number, and later tries to seek another ID by entering the correct one
7. A person that already has an ID attempts to seek another ID, but when the site asks for his / her official identifying number, he / she accidently put the wrong one that is never in the database
Variation:
1. If the person's family name or given names have non-alphabetic characters (example of such names are Sara O'Donnell and Eyhab Al-Masri), these non-alphabetic characters will be stripped out for the purposes of generating an alphanumeric ID.
2. If all IDs has been taken by others and there is another user that want create a ID with exactly same full name, the restriction of the length of the ID shouldn't be followed anymore. 
3. There should be special cases for accounts that do not belong to any single, real person. For example, some courses have a WatIAM ID, such as cs136@uwaterloo.ca. Another example is hrhelp@uwaterloo.ca. These are actual WatIAM IDs according to http://watiam.uwaterloo.ca/search/app/authen but they do not belong to any one, real person. The system administrator should be able to manually create these type of special WatIAM IDs.
Question:
1. If someone forgets their user ID, what question or questions should the WUIM website ask them in order to recover their user ID?
2. For friendly email aliases, does WUIM give users a list of possible email aliases to choose from? Or are users able to type in an alias they want, and then WUIM will check if it's available? In the second case, what rules must be in place (ex. To prevent John Smith from requesting an alias like mary.kate@uwaterloo.ca which will be very confusing)
3. Since user IDs are at most 8 characters in length, there are a finite number of user IDs available, what will happen if all the ID has been taken? Should we extend the length of IDs?
4. What would happen if person that is seeking an ID forgets his / her official identifying number?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions:
The WUIM system generates IDs only using english characters
All names supplied to the system that use non-english characters can be easily romanized into only english characters
Users have at least both a first and last name
There are no users that are neither employee nor student
All users have some form of permanent government issued ID
Email aliases have some length limit
Data in the database is never deleted
IDs have an 8-character limit
IST Service maintain their service agreement contracts

Exceptions:
The system does not know what to do if a non-colliding email alias cannot be found
If no data is deleted, then as students and employees leave, their IDs will remain in the system and eventually the 8-character ID length space will be exhausted
If someone without permanent government ID is admitted to the school, the system will not be able to support them since it will be unable to return their ID in the case that they lose it

Variations:
If a user legally changes their name, they need to be able to update their ID (relinquish their old ID and request a new one)
If a student becomes an employee, they will need to either relinquish their student ID and get a new employee ID or transfer the status of their student ID to be an employee ID (Since an ID has a one to one relation to people involved with the school, one person cannot have two IDs simultaneously)
If a student applies one year and receives a certain ID, but then chooses to go to a different school, and later returns to register and finds that the old ID has been taken
The system for assigning email aliases should support some sort of censorship to prevent offensive aliases
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
1. Assumption
	1.1 Only people that have an affiliation with the university can use it i.e. those that have received a student or employee number
	1.2 ID assignment occurs after all previously created IDs are already in the database (proper concurrent access and storing)
	1.3 There is enough space to store all IDs 
	1.4 All people have an official identifying number to give to the system
	1.5 All official identifying numbers given are valid (not counterfeit) 
	1.6Students & staff have access to the internet
	1.7 Only the owner of an ID is able to answer the questions asked by the system, when working to verify the owner of an ID

2. Exception
	2.1 Person unaffiliated with the university uses a valid official identifying number to sign up with the system (Assumption 1.1) 
	2.2 Single person uses multiple sets of information to create multiple IDs. This violates the function of preventing a single person of having multiple IDs.
	2.3 There are more people wanting to create IDs than the number of distinct IDs the system can create
	2.4 More collisions with a certain ID pattern than 8 characters can create

3. Variation
	3.1.1 Official Identifying numbers
		3.1.1 SIN
		3.1.2 Student Number (SN)
		3.1.3 Employee Number (EN)
		3.1.4 Other
	3.2 People with only one name
	3.3 Symbols in a name that are not a part of the Roman alphabet 

Questions
- How do we identify if a person is affiliated with the university prior to them getting an identification? Using student and employee numbers?
- Do you want certain not safe for work alias filtered? 
- Are there any other methods to assign an ID for someone that does not have any Official Identifying Numbers?
- What form of verification is there to ensure the Official Identifying Numbers are not falsified?
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Group
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Assumptions
1. The user will have given names.
2. The user will have some identifying number that can be used if they don't have EN, SN, or SIN
3. The user will be using the latin alphabet
4. There will be enough identifying information in the database for a user to recover their account
5. Users will not reserve email addresses that shouldn't reasonably belong to them
6. Users will enter all the required information correctly when creating their account.
7. The user should enter correct identifying number and name when recovering their account.


Exceptions
1. A user, without any given name, tries to create an account
2. A user without any identifying serial number creates an account
3. A user not using the latin alphabet creates an account
4. A user does not have enough information in the database to recover their account.
5. Two users without an unique identifying ID, but with identical information, may both try to sign up. 
6. A user does not enter information correctly when creating or recovering their account.


Variations
1. The id creation algorithm will need to allow for the possibility that users with only one name may sign up
2. WUIM should not enforce that a user has an identifying number (EN, SN, SIN, etc)
3. WUIM should allow for non-latin characters or convert into english characters
4. WUIM should allow custom email addresses to be recycled after the user does not intend to use the email or after a certain years of inactivity.
5. WUIM should have another authentication factor, such as a cell phone or email address, in order to help with account recovery if the information in the database is not enough
6. As a final step, WUIM should allow the users to check the information they have entered and correct it before creating an account.
7. User email aliases should go through an audit process such that John Malkovich can't reserve an address that sounds like it's for somebody else (e.g. ben.stiller@uwaterloo.ca) in order to intercept mail meant for somebody else. 
8. For users without enough information to build an ID in the IST database, require that enough information for recovery and id generation is provided by the user to WUIM.