Version (most recent first)




v1.3 2008-06-24 Jim Briggs Added discourse on units and cohorts
v1.2 2008-05-02 1438 Jim Briggs Signed off on changes
v1.1 2008-04-29 Andras Brey Refined requirements



Jim Briggs

First draft



SUMS-register is the part of the overall SUMS system that allows users to register and create a user account. It also allows them to do certain maintenance on their account such as change the password.

Key personnel

Responsible owner

Jim Briggs

Design authority

Jim Briggs

Development team


Future proofing

SUMS-register must integrate with the overall SUMS system.


Entities and attributes

Entity Attributes Relationships
  1. Key
  2. Forename
  3. Surname
  4. Username
  5. Password
  6. Timestamp account created
  7. Timestamp account confirmed
  8. Timestamp last logged in
  1. Set of email addresses
  2. Set of phone number
  3. Account suspension (many to one)
  4. If the user is a staff member, specifications he has to fill end there.
  1. Key
  2. Name
  1. The user will specify wether he is a student, a staff member or an external actor
  1. Key
  2. Title
  3. Register Start Date
  4. Register Stop Date
  5. Projects Start Date
  6. Projects Stop Date
  1. The user will choose the corresponding title of his current cohort
  1. Key
  2. Hemis number
  1. The user can be a student, in this case he will have to specify these attributes
  1. Key
  2. Name
  3. Postal Address
  4. Post code
  5. Activity description
  1. The user can be an external actor, in this case he will have to specify these attributes
  1. Key
  2. Email address
  1. Corresponds to an user
  1. Key
  2. Phone number
  1. Corresponds to an user
  1. Key
  2. Timestamp of suspension
  3. Reason for suspension (text)
  1. One user will suspend someone
  2. Another user will get suspended


1 Requirement Type Status Change request(s)
1 User (unauthenticated) can create a new user account M1    
1.1 User must specify :
  • forename
  • surname
  • choose a username
  • password
  • confirm password
  • at least one email address
  • choose a cohort from a list of active cohorts
  • their UserStatus

If UserStatus is "student"

  • student ID (HEMIS/Jupiter) number

If UserStatus is "external"

  • name of his organisation
  • postal address
  • post code
  • description of the activity of the organisation
User can optionally specify:
  • a set of contact points (e.g. phone numbers)
1.1.1 Validate user-specified data above M1    
1.2 When a new user account is created, an email is sent to all email addresses asking for confirmation. M2    
1.3 The user can't access to his account properties untill he confirms it by email M2    
1.3.1 The email contains a URL they can click on to confirm their account M2    
1.3.2 If the user is a student, it will be checked by his HEMIS number M2    
1.3.3 If the user is a staff member, the administrator will confirm that status M2    
2 User can modify their own details M2    
2.1 User can change their password M2    
2.2 User can change their forename and surname (consider validation issues with this) M2    
2.3 User can add or delete email addresses M2    
3 Cohort administrator or system administrator can do all the things that a user can M1    
3.1 Administrators and staff members will see registered users when they log in M1    
3.1.1 The administrator will see if the user has already activated his account or not and if it needs to be confirmed (staff members) M2    
3.2 The administrator can activate an account manually M2    
3.2.1 Any activation made by the administrator will be followed by an email to the corresponding user M2    

Authorised users (cohort administrator, system administrator) can suspend or unsuspend a user

4.1 In this context, suspension means that when they try to login, the user will get a message saying that their account has been suspended and that they should contact the person who set the suspension. M3    
4.2 To suspend or unsuspend someone, the user has to select the concerned user M3    
4.2.1 A reason has to be supplied for any suspension made M3    
4.3 If a user gets suspended or unsuspended, he will get notified by an email M3    
4.3.1 For the email notification of a suspension, a reason will be supplied M3    
5 Additional ranks can be alloted to staff members (moderator,...) M2    

Units and cohorts


Every project must be associated with a Unit.

Not all Units (across the department or university) will be represented in SUMS. Therefore SUMS needs to maintain a set of Units it is intended to manage. Eventually, as SUMS expands to manage many units, some students will be associated with several units in SUMS.

In Jupiter, there are entities which correspond to Units (abstract; related to unit name) and Unit Instance (the specifics related to the delivery of a unit in a specified academic year/semester).

If we know the student's identity (HEMIS number), we can look up to see which Unit [Instance] they are registered for in Jupiter. At present, this is not feasible, so SUMS needs to enable a student to associate themselves with a unit and for a cohort co-ordinator to amend/correct that if necessary.

The association between a student and their unit(s) is done AFTER registration, but must be completed AT OR BEFORE allocation.


A cohort is a set of cognate unit instances that run at the same time. An example would be that units PJE30 and PJS30 running from October to May in a particular academic year form the undergraduate project cohort.

It is likely that unit instances in a cohort share some of the same milestones. It is not yet known whether this is best represented by duplicating the milestones associated with unit A to unit B, or by having the units share the milestones.

It is likely that the milestones for a cohort will be similar from academic year to academic year


A milestone represents some requirement on a student to record their progress on a unit. Typically, a milestone could be: