Project Bank
Development of a feature-rich, practical University enrollment system (UES)
Information:
Objective
These guidelines are for the student to adopt to make progress in the project.
Given below are the templates for the documents related to the project. These are just guidelines only. These can be improved by the team.
Requirements Specification (RS)
Following is a template for the RS document. Some example requirements are entered in to it to show how to use the template. Make sure that you enter even the smallest/most trivial requirements also. That would help in validating the system during testing.
No.
Requirement
Essentialor Desirable
Description of the Requirement
Remarks
RS1
The system should have a login
Essential
A login box should appear when the system is invoked.
The logins are assigned by the mail-admin
RS2
The system should have help screens
Essential
Help about the various features of the system should be provided in sufficient detail in a Q&A format.
The Admission policy should also be part of the help.
RS3
The system should ‘lock’ the login id if wrong password is entered 3 times in a row
Desirable
This feature will improve the robustness of the application
Since the application is going to be used only by the Student of the organization, this feature is not essential. However, if time is there, this will be implemented.
4
5
Database Fields Specification
Student Number/Registration Number is the Key of the database. The range of valid values entered below as examples need not be taken as such. They can be modified by the team.
No.
Field Name
Range of valid values for the field
Remarks
1
ST\tudent Number/Registration Number
1 to 1000
This is the key field of the database as it is unique for an student in the organization. This will also serve as the login for the system.
2
Name
Up to 15 characters in length.
Special characters like underscore are not allowed.
3
Role
4
Email Id
Up to 25 characters in length (including the domain name)
This field should also be unique for a person because no two employees in an organization can have the same email id.
5
1 to 1000
5
6
High Level/Detailed Design (HLD/DD)
Overview of the system
Provide a block diagram depicting where the database will be located, where the application will run etc. Also, provide details about the database server that is going to be used etc.
Design Components
Split the system into its design components. In this case, the components would be user-verification, mail notification, report generation, application, cancellation, approval etc. For each of the components, provide information in the following format. User-verification component is taken as the example.
Component one
User-verification
Purpose
This component will verify if the user who is trying to access the system is a valid user.
Pseudocode
Pseudocode is written to get more clarity on the component so that the actual implementation is made easier. For the user-verification component :
Bool verify_user (emp_no, password1)
{
% get the emp_no (which is the login) and the password from the user.
Get_login_and_password();
% verify if this is a valid login (ie, from 1 to 1000).
If login_id_valid(emp_no)
{
report_error(‘invalid login id’);
return false;
};
% access the database entry for this
if get_database_entry(emp_no, database_entry)
{
% get the encrypted password.
Get_encrypted_password(emp_no, password2);
% decrypt the password. The decrypted password is password3.
Decrypt_password(password2, password3);
% compare the passwords.
If compare_passwords (password1, password3)
{
% enter in to the system.
Enter_system();
}
else % password comparison failed.
Report_error(‘incorrect password. Try again.’);
}
else % unable to get the database entry
report_error (‘invalid login’);
}
Component two
Component three
..
Test-Plan (TP)
The test-plan is basically a list of testcases that need to be run on the system. Some of the testcases can be run independently for some components (report generation from the database, for example, can be tested independently) and some of the testcases require the whole system to be ready for their execution. It is better to test each component as and when it is ready before integrating the components.
It is important to note that the testcases cover all the aspects of the system (ie, all the requirements stated in the RS document).
No.
Testcase Title
Description
Expected Outcome
The requirement in RS that is being tested
Result
1
Successful User Verification
The login to the system should be tried with the login assigned by the admin and the correct password
Login should be successful and the user should enter in to the system
RS1
Passed
2
Unsuccessful User Verification due to wrong password
Login to the system with a wrong password
Login should fail with an error ‘Invalid Password’
RS1
Passed
3
Unsuccessful User Verification due to invalid login id
Login to the system with a invalid login id
Login should fail with an error ‘Invalid user id’
RS1
Passed
4
5