Assignment Spm

8/8/2019 Assignment Spm

http://slidepdf.com/reader/full/assignment-spm 1/21



2

Table of Contents

1. INTRODUCTION....................................................................................................... 3

2. DOCUMENT SUMMARY ......................................................................................... 3

3. SCOPE OF THE SYSTEM ......................................................................................... 4

4. PRODUCT FUNCTIONS ........................................................................................... 4

Figure 1 Probable modules & sub-modules of the systemResume Management ........... 5

Resume Management .................................................................................................. 6

Job Management ......................................................................................................... 7

User Account Management ......................................................................................... 7

Report Generation ....................................................................................................... 8

Admin Management .................................................................................................... 8

5.PROJECT MANAGEMENT GANNT CHART ........................................................... 9

6. REQUIREMENTS ANALYSIS ................................................................................ 10

Requirements are a description of needs and desires for a product. The challenge is to

define the requirements unambiguously, so that the risks are identified and there are no

surprises when the product is finally delivered........................................................... 10

Part I ± Functional Requirements............................................................................... 10

Part II - System Workflow ......................................................................................... 14

Figure 2. Workflow of the system ................................................................................... 15Part III ± Non-Functional Requirements .................................................................... 16

Reliability ................................................................................................................. 17

Performance .............................................................................................................. 17

Supportability ............................................................................................................ 17

Security ..................................................................................................................... 18

User Interface and Usability Requirements ................................................................ 18

7. FIRST ITERATION REPORT AND SECOND ITERATION GOALS ..................... 18



3

1. INTRODUCTION

The effort we're undertaking is to explore design and implementation considerations for the online hiring system and to provide a basic look and feel prototype for it. It is

important to note that at an early stage like this, a very significant part of this project isthe investigation of what features and UI a fully completed Onlline hiring system might

have.

This project represents the first phase of a multiphase development process to create the

eventual system; as such our most important deliverable will be a report summarizing the

detailed requirement considerations. Additionally we will implement a prototype systemthat will demonstrate a conceptual view of the probable implementation.

2. DOCUMENT SUMMARY

This document serves three distinct purposes:

1. Increase the visibility of the project by communicating back our understanding of

user requirements.

2. Increase the visibility of the project by communicating our progress so far andfuture steps.

3. Serve as part of the documentation package for this project.



4

3. SCOPE OF THE SYSTEM

The scope of the current effort is directed towards detailed requirements gathering andanalysis. We draw a clear line of what the proposed system will provide and what should

not be expected. We propose a system that will provide an integrated online hiringmanagement facility to Elixir Technologies.

The system will be responsible for providing resume management (i.e. Creating an online

resume, tracing the resume statistics, searching resumes for job relevance, notifyingsuccessful candidates through e-mail automatically), job management (i.e. announcing,

posting and archiving jobs by employers, setting resume filter criteria, applicanttracking), user account management (i.e. allow online registration, provide customized

account management for employers and applicants), report generation (i.e. generatingmanagement reports and flexible ad-hoc query results) and admin management (i.e.

set custom system privileges, validating employers, blocking and deleting inactiveaccounts, add/ remove/ update records).

The end-product will be a fully-featured website which accomplishes the abovementioned goals.

4. PRODUCT FUNCTIONS

The system consists of the following main functions and sub-functions:

y Resume Manager

y Job Manager y User Account Manager

y Admin Manager

y Report Manager



5

Figure 1 Probable modules & sub-modules of the system

OnlineHiring

ResumeManager

Resume

Creation

Status

Tracking

Resume

Searching

Resume

Filtering

Auto mail

generation

JobManager

Job PostingJob Agent

CreationJob Archiving

Applicant

Tracking

Online

Application

User AccountManager

Account

Customizatio

n

Account

Creation

AdminManager

Account

Management

System

Management

ReportGenerato

Generate

Reports



6

Resume Management

This module provides complete online resume management. It has the following sub-

functions:

Online Resume Creation:

Allows creation of online resumes through forms. Resume is saved at the end of each session and user can return to complete the Resume at any time.

Resume Searching:

Supports searching of resumes based on different criteria.

Resume Status Tracking:

Resume status can be checked at any time for the following factors:

y Complete/Incomplete Resume

y Applied for <this much> jobs

y Pending/Called for test/Successful/Unsuccessful.

Resume Filtering:

Provides a number of filters to automatically make selections through resumes.

Auto Mail Generation:

Send automatic bulk or individual notifications to short listed and successfulapplicants for each test and interview.





8

specific system activities, for example. Posting of new jobs for a selected categorye.tc.

Report Generation

Generate Reports:

Generate customized reports. This feature makes the application very useful for themanagers.

Admin Management

Account Management:

Set custom system privileges, validating employers, blocking and deleting inactiveaccounts, add/ remove/ update records pertaining jobs, resumes, and user accounts inthe database. Assign, revoke user privileges.

System Management:

Add new job categories and job agents to the system. Run reports on demand. Set andchange criteria for resume evaluation. Post successful candidates.



9

5. PROJECT MANAGEMEN- GANTT CHART



10

6. REQUIREMENTS ANALYSIS

Requirements are a description of needs and desires for a product. The challengeis to define the requirements unambiguously, so that the risks are identified and there are no surprises when the product is finally delivered.

This iteration goes through eliciting all data, functional and behavioral requirements for the software. The software requirements are specified after detailed analysis of the

problem domain.

It includes an explanation of the problem domain, a set of functional requirements and

nonfunctional requirements. Non-functional requirements are requirements which impose

constraints on the design or implementation such as performance engineeringrequirements, quality standards, or design constraints.

Part I ± Functional Requirements

After looking very closely into the arising requirements, we found out some main entitiesof the system and decided to direct our effort by meeting requirements revolving each of

these entities one by one. The main entities come out to be rthe main users of the system.Focusing on requirements with each user group in mind helps to achieve functionality in

clear and distinct patches where each patch may be able to meet the needs of a certainuser group to a large extent. Also, dependency of the functions also becomes visible and

makes it easier to develop a design strategy where dependent functions are set in contextof the independent ones and also poses the challenge to decrease the dependency at

implementation level such that a whole sub-function may be able to be replaced by a

different sub-function.

Let us first look at the main requirements of the system and the business rules to be

followed:

1. Job Seeker:

f1.1 Should be able to register in the system as a member.

f1.2 Should be able to Login to the system.f1.3 Should be able to create a resume.

f1.4 Should be able to update all editable details of the resume.

f1.5 Should be able to identify what notifications he prefers to get.f1.6 Should be able to change the settings for notifications and applications.f1.7 Should be able to apply against posted jobs.

f1.8 Should be able to search jobs on different criteria.f1.9 Should be able to view job details.

f1.10 Should have a personalized workspace that contains information regarding hisapplications, resume and personal profile.



11

2. Job Agent:

f2.1 Should be able to register in the system as a member.f2.2 Should be able to Login to the system.

f2.3 Should be able to post a new job.

f2.4

Should be able to change any of the editable details for the job.f2.5 Should be able to identify what notifications he prefers to get.f2.6 Should be able to change the settings for notifications and applications.

f2.7 Should be able to receive applications against his posted jobs.f2.8 Should be able to view resume details.

f2.9 Should have a personalized workspace that contains information regarding his job posts, company and received applications/ resumes and personal profile.

f2.10 Should be able to accept/ reject resumes.

3. Admin:

f3.1 Should be able to register in the system as an admin.

f3.2 Should be able to Login to the system.f3.3 Should be able to create new admin users.

f3.4 Should be able to activate/inactivate users.f3.5 Should be able to verify Job Agents with their companies.

f3.6 Should be able to block/unblock users.f3.7 Should be able to delete a user along with all information from the user account

if required.f3.8 Should be able to view pre-defined reports.

4. Other Details (Business Rules):

Job:

f4.1.1 System generates a job ID sequentially. This is unique andcannot be changed later on.

f4.1.2 Date of job posting is the system date by default and cannot bechanged later on.

f4.1.3 The job posted is attached to the posting Job Agent by defaultand cannot be changed later on.

f4.1.4 The job post can belong to only the companies for which the job agent has the right to post the job for.

f4.1.5 Status of the Vacancy can be Open/Close. By default jobstatus will be open and is closed when the end date exceeds the

current date.f4.1.6 Job titles can be repeating across different companies as well as

among the same company. (like Java Developer)f4.1.7 Required description about the job is provided.



12

f4.1.8 Number of openings under that job post is provided (like 5numbers of Java Developers required).

f4.1.9 Date by which the job should be fulfilled/gets closed ± this can be left blank.

f4.1.10 Jobs will be posted against pre-defined job

categories/industries. The job categories will be defined by theadmin.f4.1.11 Job posting should be able to retrieve the posting company and

job agent¶s details if required.

Job Seeker:

f4.2.1 System generates a jobseeker ID sequentially. This is uniqueand cannot be changed later on.

f4.2.2

The job seeker can register himself on the site by providingrequired information. The user account is activated only after

activating the account using details from the provided email id.Default status of user account will be Inactive.

f4.2.3 Date of user account creation is the system date by default andcannot be changed later on.

f4.2.4 The job seeker can place only one resume.f4.2.5 The job seeker can provide detailed personal information at the

time of registration. This information is automatically used for the resume as well.

f4.2.6 The job seeker can apply the resume against any number of posts. Applying against the same post should be checked.

f4.2.7 The job seeker receives notifications for selected activities onhis provided email id.

Job Agent:

f4.3.1 System generates a jobagent ID sequentially. This is uniqueand cannot be changed later on.

f4.3.2 The job agent can register himself on the site by providingrequired information. The user account is activated only after

activating the account using details from the provided email idand verification from the Admin. Default status of user accountwill be Inactive.

f4.3.3 Date of user account creation is the system date by default andcannot be changed later on.

f4.3.4 The job agent can post any number of jobs for its parentcompany.



13

f4.3.5 A job agent account is associated to a single company at atime. A person may be registered as a job agent for multiple

companies under different accounts. The user accounts and allrelated transactions will remain completely independent of

each other.

f4.3.6

Deleting a job agent does not delete his job posts or companyinformation.f4.3.7 The job agent receives all resumes applied against his posted

jobs.f4.3.8 Deleting an application is not possible.

f4.3.9 The job agent can accept or reject the resumes. Notificationswill be sent to the job seekers as the status changes.

f4.3.10 Job agent should be able to retrieve the parent company and posted job¶s details if required.

Resume:

f4.4.1 System generates a resume ID sequentially. This is unique and

cannot be changed later on.f4.4.2 All information in the resume is editable by the job seeker

only.f4.4.3 A resume is unique for every job seeker. Thus, the resume is

able to retrieve the job seeker information as well.f4.4.4 The latest state of resume will be available for all applications

placed.f4.4.5 The resume can be posted against any number of jobs.

However, the same resume cannot be posted more than onceagainst the same job.

f4.4.6 A resume can have only one title and objective.f4.4.7 The resume should contain detailed information regarding the

job seeker¶s education, experience, skills, certifications andreferences.

f4.4.8 Personal information of the job seeker will be the same as provided at the time of registration.

f4.4.9 A job seeker may or may not have a resume. The job seeker account will virtually be useless without a resume. He cannot

apply against any job post without it.

Apply for Job:

f4.5.1 To apply for a job, the job seeker must be signed in. If not, the

system should request so.f4.5.2 It is not possible for users with a job agent or admin account to

apply against any job.



14

f4.5.3 The latest state of resume will be available for all applications placed. If changes are made to a resume after he applied for a

job, the updated resume will be available for the application.f4.5.4 Once Closed, a job can not be reopened.

f4.5.5 It is not possible to apply against a Closed job.

f4.5.6

Any number of applications can be placed against a job post.f4.5.7 A resume can be applied against any number of jobs.f4.5.8 The job applications can be filtered by the job agent on pre-

defined criteria.

Part II - System Workflow

A flowchart is a graphic and schematic representation of the logic or steps in a program

or system. It represents how a program or activity moves through various processes or program routines. It uses symbols to represent the activities, and uses arrows to represent

the direction of activity through the processes. Flowcharts can define the behavior of asingle program or a system (a combination of programs).



15

Figure 2 . Workflow of the system



16

Technical Issues

There are a number of technical issues that may hinder either our development process or

the usage of the system after it is developed.

Cross-browser compatibility will be a problem during development of the webapplication front-end due to our heavy JavaScript usage combined with notoriousJavaScript standards incompatibilities across browsers. We hope that we will be able to

minimize this problem and make the issue transparent to users by taking time to insurethat our application works for Internet Explorer at first priority as most of oyr sers are

likely to use it.

Although SQL Server Express is a very powerful database engine, yet it possess some

finite capacity and processing speed that may not function as expected under extreme

circumstances. Similarly, our web server can only satisfy a finite load of users and pagerequests.

Another issue that may arise is the problem of keeping our code base extensible. We needto constantly keep in mind the ideas of modularity and loose coupling and provide

interfaces between our code modules that allow a future user to swap an underlyingimplementation without having to modify dependencies in the software except the

interface implementation.

Part III ± Non-Functional Requirements

These requirements are attributes that are indirectly related to the desired functionality of

the system. They do not specifically outline technical behavior of the system, but more sothe nontechnical additions to the system that make this project a successful one.

Human Factors

y Most frequently required functions should be most easily accessible.

y System should be intuitive in use.

y Most suitable controls should be used for each function.

y Colors, icons, fonts should be visually pleasing as well as add meaning to thecontent.

y Unnecessary re-direction to other pages should be avoided.

y Dialogs, splash screens and modal pop-ups should be used wherever necessary.

y All pages should be easily reachable.

y Links should be available in the most logical grouping.

Help and Documentation

y Tool tips, error messages, warnings, and example and help text should be provided at any and all suitable occurrences.

y Task based quick start documentation should be provided with the system.



17

Reliability

The system must fulfill reliability requirements:

y Frequency of failureThe system should be able to handle most exceptions and errors even in the formof error messages instead of letting the system fail.

y RecoverabilityThe system should be able to recover from error or failed states.

System should rollback any uncommitted transactions incase of failure.

y PredictabilityThe system should behave in a predictable manner. Production of inadvertentsituations must be avoided.

Performance

y Response timesThe system must be able to respond within an average of 15-30 seconds even inhigh traffic times. Any delays beyond this limit must be indicated visually for e.g.

Progress bar or percentage pies etc.

y AccuracyThe system should be able to produce all results accurately and correctly. For

example, search results, key matching etc.

y AvailabilityThe system is web-based and is expected to be available 24x7. Unavailable

features should be explicitly mentioned to avoid disappointments.

y Resource usageOptimal resource usage routines should be used.

Supportability

y AdaptabilityThe system should be able to adapt to varying environments (e.g. browser

environments) and machine specifications.

y MaintainabilitySystem implementation should be maintainable such that coding is commentedand properly versioned. Changes should be documented as implemented through



18

iterations. Also, system size should not be increased to a manageable limit.

y Internationalization

The communication language, backend tools and user interface should all be

global in perspective and unbiased, inoffensive and non-derogatory in all possiblemanners.

Security

Secure mechanisms should be followed for access of the system.

User Interface and Usability Requirements

Our user interface is different for the three types of users that we allow, administrators,

job seekers and job agents. For all types of users, there will be a personal workspace thatwill include a welcome message, possible announcements, and links to all their accessible

features.

The pages that open for a user are all custom driven and will contain dynamic

information for each user.

Non-custom information/pages are kept static and are accessible even to a guest user in

the same way as to any of these three users, for example, about us, contacts us.

A general pattern will be adopted to ensure consistency across user domains and althoughinformation links and possible functions may be different for each set of users the over all

UI will still bear a taste of coherency with the other user sets.

A regular menu and a dynamic menu may be made part of each page. Dynamic

information displays seamlessly to the user.

7. FIRST ITERATION REPORT AND SECOND ITERATION GOALS

First Iteration Report

As part of our first iteration we accomplished three main tasks, the first was obtaining

information about the project from stakeholders, the second was the conceptualization of

an early prototype system, the last is significant visibility project, such as this report and presentation.



19

Prototype



20



21

Future Directions

In our next iteration, we expect to have a beta-level prototype highlighting system in

place backed by our database. This will allow us to solicit feedback about the basicfunctionality of the application without having to develop a fully refined interface. The

highlighting data will be collected by the client's browser and sent to the server, wherethe data will persist in the database. The data will be sent back to the client whenever a

new comment is loaded.

We also hope to have a good stable database schema during the next iteration.

Another significant task in the next iteration will be to have up and running ajax controls

wherever possible for client level authentications.

Documents

Assignment Spm