BSCIMS_Thesis

CS400-Report 1
Balanced Scorecard Information
Management System (BSCIMS) Report
Document
Developers:
Jose Rego (140226)
Mzwandile Mamba (142765)
Supervisor: Dr. P. M. Mashwama
This project report is submitted to the department of Computer Science in partial fulfillment of
the requirements for the award of the Degree of Bachelor of Science of the University of
Swaziland.

CS400-Report 2
ACKNOWLEDGEMENTS
First and foremost, we thank the Lord, God Almighty who has been our anchor and strength
throughout the project. He helped us through all the difficulties and complexities we encountered
during the exercise. The Lord blessed us with a caring supervisor, Dr. P. M. Mashwama who
gave us the proper advice and guidance that made it possible for us to design and develop the
system.
Furthermore, we would like to thank the IT department of the Swaziland Electricity Company,
especially the Manager Mr. Melusi Malinga, who has been of great assistance in understanding
the Balanced Scorecard and it's implementation in the company. The IT department also allowed
us to use the company’s resources and was of great help in acquiring and understanding the
development tools and technology we needed for our project. We would also like to personally
appreciate Brian Sihlongonyane and Mlandvo Nxumalo in the department who helped us when
things were not going our way by sacrificing their valuable time in order to see this project
through.
Lastly, but certainly not least, we would like to thank our lecturers, colleagues, friends and
relatives who contributed in the development of our system. We thank our families for their
prayers and support even when we were too busy wrapped up in our work.

CS400-Report 3
ABSTRACT
Performance management among other things is essential in achieving high performance. Thus
having a well-designed performance management system is vital as far as performance is
concerned. Most organization have adapted the Balanced Scorecard concept in their performance
management. Too often than not, they implement this concept on a paper-based or spreadsheet
based performance management systems. This systems tend to be very strenuous and insufficient
and thus the objective of having the system is not properly met. Problems like communication
challenges, lack of evaluation tools, and lack of integration to count a few are accompanied by
the above mentioned systems. In this report, we shall design and develop a web-based
performance management system that implements the Balanced Scorecard.

CS400-Report 4
PROBLEM STATEMENT
Performance Management includes activities which ensure that goals are continuously being met
in an effective and efficient manner. A good performance management system is one that
ensures that an organization, department, employee or even the processes to build a product carry
out their work as per their objectives in a satisfactory manner. The Balanced Scorecard (BSC) is
a conceptual performance management system that translates an organization or employee’s
vision or strategy into a set of performance measures distributed among four perspectives:
financial, customer, internal business processes and learning and growth perspective.
Among other concepts, the Balanced Scorecard (BSC) concept is implemented in paper based
performance management systems. This has led to number of problems including the following:
 Multiple versions of data – There is no centralized data store and as a result data
redundancy and multiple versions of the company’s performance information will be a
characteristic of such systems. The multiple versions make it difficult to share the
performance data through all levels of the company.
 Lack of integration – Performance has to be approached from an integrated perspective.
Synergy has to be created between the performance management system and strategic
planning, human resource management processes, organizational culture and structure
and all other major organizational systems and processes. Individual, team and
organizational strategic objectives must be harmonized. This is very hard to achieve with
a paper-based system.
 Communication challenges – Users of the BSC must be able to communicate
professionally and developmentally during the process of conducting appraisals and when
communicating outcomes and feedback. It is not easily feasible to achieve efficient
communications with such systems since they require personal involvement of the
involved parties.
 Lack of evaluation–The reporting functionality with such systems tends to be tedious
and exhausting. Thus the evaluation process tend to be irregular. The identified problems
in an organization are not attended to early enough which is not desirable. Also the
overall evaluation of an organization is not easily done since the BSC does individual
evaluation of employees with no connection with the overall organizational performance.

CS400-Report 5
Contents
Chapter 1 – Project Description and Background.............................................................................6
1.0 Introduction............................................................................................................................6
1.1 The Balance Scorecard Defined .........................................................................................8
1.2 The Balance Scorecard Architecture .......................................................................................9
1.3 Problems Identified for this Project.......................................................................................11
1.4 Benefits of having the Software System.................................................................................12
1.5 Assumptions and Constraints ................................................................................................12
1.7 Report Layout.......................................................................................................................13
Chapter 2 – The Software Requirements Specifications..................................................................14
2.1 Introduction..........................................................................................................................14
2.2 General Description...............................................................................................................17
2.3. Specific Requirements ..........................................................................................................19
Chapter 3 – Design Specifications ...................................................................................................28
3.1 Introduction..........................................................................................................................28
3.2 References........................................................................................................................29
3.3 Decomposition Description....................................................................................................29
3.4 Dependency Description........................................................................................................37
3.5 Interface Description.............................................................................................................39
3.7 Traceability Matrix ...............................................................................................................45
Chapter 4 – Implementation and System Testing............................................................................48
4.1 Introduction..........................................................................................................................48
4.2 Implementation.....................................................................................................................49
4.3 Testing...................................................................................................................................49
Chapter 5 – Conclusion and Future Work......................................................................................57
5.1 Conclusion.............................................................................................................................57
5.2 Future Works........................................................................................................................57
Appendix ........................................................................................................................................58
References.......................................................................................................................................59

CS400-Report 6
Chapter 1 – Project Description and Background
1.0 Introduction
The performance of an organization, department, employee, product or student requires effective
assessment and proper strategies to ensure that accurate performance measurements are acquired.
To achieve high performance, among other things, a proper performance management is required
[3], [5]. Dr. Pulakos [4] defines performance management as a set of methods or processes used
to compare the achievements of an organization or individual to the anticipated objectives or
goals. Effective performance management is attributed by enhanced individual or group
productivity, improved communication between supervisors and employees, job descriptions and
expectations can be clearly clarified and employee behavior can be aligned to an organization’s
goals and priorities [3], [4], [5].
A good performance management system is one that assesses and ensures that employees carry
out their work as per their objectives in an effective and satisfactory manner [4]. It is worth
noting that there are a number of ways in which performance is managed within various
organizations across the world [5], [8], [9]. ISO9000 and Balanced Scorecards (BSC) are the
most prominent used models in the European Public Employment Services (PES), although the
nature of performance management practices differ especially with the Balanced Scorecard [11].
These concepts are recent. For this paper we will focus on the balance scorecard concept.
Since the balance scorecard concept has been recently introduced, in 1992 by Dr. R. Kaplan and
Dr. D. Norton, it is expected that it be implemented manually and that a few software systems be
built to implement it. In fact the software systems commonly, used as it would be expected, are
spreadsheets. It’s no surprise since spreadsheets are easily accessible and are simple to use. They
need little training. As a result, applications implementing the balance scorecard framework are
very few due to the fear of leaving this comfort zone [4], [6], [8]. According to Pujas D. (2010)
[10] the use of spreadsheets provides a multiple versions of the real performance of the
organization. He further supports his argument by explaining that this results from the fact that
there is no central storage of data thus it is hard to keep the various storages up to date with each
other.

CS400-Report 7
Dr. Robert Kaplan and Dr. David Norton (2013) argue that software applications come with
unnecessary costs. They give an example that a software application requires a server to run for
starters. This server will cost large amounts of money. It will also require a network where the
data will be shared on, which also has its own separate costs. He also mentions that in the case
that the application is bought from another company, rental costs will also be incurred. Now the
question to ask is - “Is the transition really worth it?”
Of course applications are worth their costs especially if properly built, managed and maintained.
According to [13] (A balance scorecard authority webpage), software application’s automation
adds a nice structure which simplifies implementing the balance scorecard concept. For example,
it helps transform disparate corporate data into information and knowledge, and helps
communicate performance information. Put in simple terms, automation enhances future
decision making because it offers quick access to actual performance data [6], [7].
Reviewing literature seems to show a lot of diverse support for the need of a Balanced Scorecard
Information Management System. Bloomfield C. (2002) explains how technology has evolved
such that almost everything is automated for simplicity. We agree with Mr. Bloomfield in that
there is the need for more applications that will automate the balance scorecard and provide a
central storage of the company’s performance data because it becomes much easier to work with
such data. This will also help in controlling data access and also simplify production of reports as
the company’s performance data will be centralized.
The Swaziland Electricity Company (SEC) has recently introduced the balance scorecard
concept as a way of managing its performance. The company uses spreadsheets to implement the
balance scorecard. With reference to the above context, it is anticipated that the above mentioned
problems will be associated with the company’s performance management system. Thus, this
project’s contribution focuses in the designing, developing and implementing of a Balance
Scorecard Information Management System (BSCIMS) for SEC.
8+

CS400-Report 8
1.1The Balance ScorecardDefined
According to Tony Virtanen (2009), a balanced scorecard is a strategic planning and
management system, that is, it enables organizations to specify their vision and objectives and
then translate them into practical and measurable goals. Bose S. and Thomas K. (2007) define
the balance scorecard as a concept that translates an organization’s mission and strategy into a
comprehensive set of performance perspectives that provides the framework for a strategic
measurement and management. Bose S. and Thomas K. (2007) further mention that it also
provides a method of aligning the organization’s business activities with that strategy. The
balance scorecard is also thought to improve the organization’s internal and external
communications, and allows the organization to monitor its performance against its strategic
goals [6], [7], [10]. It advocates that non-financial perspectives be used to motivate, measure and
evaluate company performance [5].
A very key question is “Why is it called a balanced scorecard?” According to Balance Scorecard
Australia[12], it is a ‘balanced scorecard’ because a central component of the methodology is a
management ‘scorecard’ that focuses on all of the important aspects of an organization’s
performance as well as its short term financial performance. The idea is that the organization’s
objectives and goals are key measurements to an employee’s daily work. At the end of it all, this
will add to the overall organizations financial and non-financial performance.
People have different definitions of the balance scorecard. The different meanings of ‘The
Balanced Scorecard’ are listed below:
 Murby L. and Gould S. (2005) defines the ‘Balanced Scorecard’ as a generic term which
refers to a management methodology that has been rapidly evolving for two decades, and
overtime has come to mean different things to different people.
 The Procurement Executives’ Association (PEA) elaborates that practically, there are
wide variations in understanding and implementation. In its most limited form, ‘the
Balanced Scorecard’ is frequently seen to be a simple management dashboard of
performance measures.
 While on the other hand Kaplan R. S. and Norton D. P. (2013) elaborate that the balance
scorecard, in its most developed form, is a comprehensive planning and management

CS400-Report 9
system designed to focus an organization on achieving its objectives as effectively as
possible.
Pujas D. (2010), defines a balanced scorecard as a conceptual performance management system
that translates an organization’s objectives into a set of performance measures distributed among
four perspectives: financial, customer, internal business processes and learning growth. Looking
at the definitions mentioned above, though they do not differ much, Pujas D. comes with a
simplified and clarified definition that combines all the above definitions. In this report, we shall
be referring to this definition when we talk of a balanced scorecard. Now that we have defined
the balance scorecard, it will be appropriate to look at its structure.
1.2 The Balance ScorecardArchitecture
Based on Pujas D.'s (2010) definition the structure of the balanced scorecard should consist of a
small number of financial and non-financial objectives related to the organization’s strategy. It
then looks at measures, setting targets for the measures and finally recording and monitoring
them on a regular basis to determine success or failure [1], [2], [9], Only when this is in place
can strategic projects be considered. According to PEA, it is in this area that the Balanced
Scorecard approach differs from other strategic methodologies. The idea is that organizations
should be able to think about how objectives can be measured first and then what initiatives can
be put in place to satisfy those objectives. The basis behind this is to avoid creating
initiatives/projects too early and measuring success based only on initiative/project completion
[2], [6], [8].
From above we can see that in order to come up with a proper balanced scorecard, there are two
aspects of activity that need to be considered. These are:
 Firstly we identify financial and non-financial objectives. These objectives are usually
few in number and are critical to the sustainability or growth of the organization. These
objectives are related to four major “perspectives” to ‘balance’ the scorecard.
 Secondly, the obtained objectives are translated to measurable measures, as it is very
important that each objective must be measurable. These measures are often referred to as
Key Performance Indicators (KPIs). They should include both leading and trailing
measures. The ‘balance’ that a Balanced Scorecard achieves is brought about by a focus
on financial and non-financial measure that can be attributed to four areas of an

CS400-Report 10
organization that are described as “perspectives”. As it has been alluded before, they are
namely: Financial, Customer, Internal Business Processes and Learning & Growth [2],
[8], [9], [11].
The strategy behind a Balanced Scorecard can be thought of as shown by the figure below.
Figure 1.1. The design of a BSC by the Procurement Executives’ Association
The four perspectives of the Balance Scorecard
Financial: This perspective focuses on the financial performance of the organization. It
provides managers with an efficient and effective way of monitoring the financial effects of
the company based on the preset goals of the company. It is much easier to monitor an
organization's progress if either its budget is being met or violated. The basic idea behind
this perspective is to create metrics that will play a vital role in evaluating if the company
has improved its profitability or not. [1], [3]

CS400-Report 11
Customer: Customer satisfaction is very important in a business. This perspective is
concerned with whether the company meets customer needs or not. The Balance Scorecard
forces managers to align their objectives with good quality goods and services, the
effectiveness of their delivery, and overall customer service and satisfaction. According to
Kaplan and Norton (1992), the core measures include customer satisfaction, retention, new
customer acquisition, customer profitability, market and account share, and building a
sustainable customer relationship [3],[13].
Internal Business Processes: This perspective focuses on the internal business activities
such that the company is able to achieve its financial goals and customer satisfaction. To
ensure that the company meets its organizational objectives and customer expectations, it
should identify the key business processes at which it must excel. These key processes are
then monitored to ensure that outcomes will be satisfactory. Internal business processes are
the mechanisms through which performance expectations are achieved [1], [5], [6].
Learning and Growth: This perspective looks at the ability of employees, the quality of
information systems, and the effects of organizational alignment in supporting
accomplishment of organizational goals. Processes will only succeed if adequately skilled
and motivated employees, supplied with accurate and timely information, are driving them
[5], [9].
1.3 Problems Identified for this Project
As mentioned in the introduction, currently SEC is implementing the Balance Scorecard.
The company is using a paper-based system. The fact that the company uses a spreadsheet as
to manage its performance information is the first and major problem. So there is a need to
build an application that will solve this.
Furthermore, as a result of the lack of a performance management system, there is no
centralized data of the company’s performance records. This leads to redundancy and
multiple versions of the company’s performance [12]. For example, an employee will have

CS400-Report 12
his own version based on his spreadsheet while the manager has his own. The multiple
versions and lack of centralized data makes it difficult to share the performance data through
all the levels of the company. This in turn makes it hard to evaluate the overall performance
of the company based on every single employee’s performance [2]. This is not desired.
Another problem is that of security. The lack of a software performance management system
and use spreadsheet has no restrictions over data ownership, user access rights and there is
no ability to connect to other data source [3].
1.4 Benefits of having the Software System
We have seen the downfall with the lack of a software system and the use of spreadsheets to
implement the Balance Scorecard. The question now is, “how will the presence of software
system solve these problems and make corporate life simpler?” Firstly, the performance data
of the company will be centralized. This provides a single version of the company’s
performance data with a web-based interface where it will be viewed. Also it will be much
easier to produce an overall performance of the company and share the performance data
through all the levels of the company. Access management to data is now possible and this
gives control over information flow. [7]
1.5 Assumptions and Constraints
During the project establishment and progression some assumptions were made. The project
also had some constraints. The assumptions and constraints for the project are briefly
described below.
1.5.1 Assumptions
The assumptions for this project are as follows: an in-depth knowledge and understanding of
the Balanced Scorecard and its implementation in a performance management system is
assumed. That is, it is assumed that it is well known how SEC’s performance management
system is. It is also assumed that the structure of the company is known. Lastly, it was
assumed that the company has well-functioning workstations that have a working network
connection.

CS400-Report 13
1.5.2 Constraints
Since the project was done during the second semester, time was not on our side because we
had to balance other courses with the project. The project required adequate time and the
allocated time to do the project was insufficient. Another constraint was the slow network
connection at school. Not only was the network slow, it also had a lot of restrictions that
hindered from acquiring the tools we needed for the smooth development of the system.
1.7 Report Layout
In this chapter, the background and description of the project was outlined. Chapter 2 covers the
requirements specifications outlining the user requirements, the external interface requirement of
the system and the tools used. The 3rd chapter covers a detailed design of the system, which
includes technical documentation, that is, the functional components and data flow diagrams to
model the functionality. Chapter 4 covers the implementation and testing of the system. It shows
all the test results and describes how testing was done. The conclusion, unfinished work and
future work are given in the last chapter which is followed by the appendices which contains the
user manual and references.

CS400-Report 14
Chapter 2 – The Software Requirements Specifications
2.1 Introduction
This is a Software Requirements Specification (SRS) document for the Balance Scorecard
Information Management System (BSCIMS). It aims to encompass the entire description of
the system and its relevance. It is specifically targeted for the performance management of the
Swaziland Electricity Company (SEC) by automating the Balance Scorecard (BSC). Currently
the management of performance in the company is implemented using the BSC on a paper-based
management and has the following problems:
 Lack of integration - Synergy has to be created between performance management
and strategic planning, human resource management processes, organizational
culture, structure and all other major organizational systems and processes.
 Inefficient Communication - Users of the BSC must be able to communicate
professionally and developmentally during the process of conducting performance
appraisals and when communicating outcomes and feedback. Communication is one
of the most critical success factors of the entire BSC.
 Lack of Evaluation - The evaluation process must be conducted at regular intervals to
enable the detection of problems at an early stage. This will ensure that prompt
corrective action is taken to address the identified problems in a department or an
organization.
 Multiple version of the truth – Each employee has his/her own spreadsheet which she
can modify anyone and whenever an update is made on the employee’s scorecard, it
has to be done on the different spreadsheets. There is a lack of a central pool of the
company’s performance data.
The BSCIMS SRS will tackle the ways in which this system will overcome the problems
mentioned above. The following are some of the solutions:
 BSCIMS will act as an automated balance scorecard that improves the overall
communication between manager/supervisor and employee.
 It will facilitate a cordial and harmonious relationship between an individual
employee and the supervisor based on trust and empowerment.
 It will ensure accountability of responsibilities in a cost effective way.

CS400-Report 15
 Security and safe keeping of sensitive employee performance records in a centralized
data store. This will also ensure that only the problem of multiple versions is
eliminated.
Overall, the BSCIMS will be a cloud storage platform for performance management of each
employee and then compute the overall organizational performance. Thus simplifying creation of
reports. It is also worth mentioning that the SRS document shows how the system will be,
ideally. Changes might be made during development.
2.1.1 Purpose
The main objective of this SRS is to document the means undertaken by BSCIMS in achieving
its goal of providing an efficient and effective performance management system that implements
a BSC.
2.1.2 Scope
BSCIMS will be used by the human resources department, departmental and divisional managers
and employees. Employees will use the system to record preset goals and milestones in their
performance which will then be approved by their supervisor(s) and in the event there is no
agreement between employee and manager the objective can be edited and approved. Once the
goals have been approved they cannot be edited. Approved objectives will then be evaluated at
the end of the financial year. Once every employee has been evaluated, then the overall
performance of the company can then be computed from each employee, cascading up the
structure of the company. Then reports can then be created from the system. They can be in
terms of graphs, tables, pie charts, bar charts etc.
2.1.3 Definitions, Acronyms, and Abbreviations
Any abbreviation and short hand notation that will be used in this document will be expressed
fully below:
SEC – Swaziland Electricity Company
BSC – Balanced Scorecard

CS400-Report 16
BSCIMS – Balance Scorecard Information Management System
DBMS – Database Management System
GUI – Graphical User Interface
UI – User Interface
UX – User Experience
OS – Operating System
IE – Internet Explorer
LAN – Local Area Network
LAMP – Linux Apache MySQL PHP/Python stack
MEAN – MongoDB, Express, Angular.js & Node.js stack
SRS – Software Requirements Specifications
WWW – World Wide Web
I/O – Input/output
IPO – Input Process Output
CRT – Cathode Ray Tube
CRUD – Create Read Update Delete
LED – Light Emitting Diode
HR – Human Resources
NoSQL – Not Only SQL
2.1.4 References
None
2.1.5 Overview
This SRS contains a user level description of the project in section 2, along with a detailed list of
prioritized requirements in section 3 and a brief description of the interactive capabilities of the
system with users thereafter.

CS400-Report 17
2.2 GeneralDescription
This section of the SRS describes the general factors that affect BSCIMS' requirements in detail.
2.2.1 Product Perspective
BSCIMS, as web based system, will be generally supported by most, if not all, web browsers. To
mention the common leading ones: IE, Google Chrome, Mozilla Firefox, Apple Safari, Opera
Mini, Midori, etc. The above, therefore, indicates that it is not expected that BSCIMS be affected
directly by the OS of the computer.
2.2.1.1 System Interfaces
BSCIMS will run on a MongoDB DBMS which will receive and send data to the GUI using
Node.js and JavaScript along with Angular.js (a popular JavaScript library).
2.2.1.2 Interfaces
BSCIMS is a web-based GUI which will primarily allow SEC to implement the BSC concept to
manage its performance. The idea is that an employee will be allowed to set objectives(KPA) at
the beginning of the financial year. The employee’s supervisor will be notified via email, which
he/she will, in turn, approve if objectives are satisfactory or edit unsatisfactory ones. The
supervisor is also allowed to set goals for the employee. Once the employee and supervisor have
agreed on the objectives, the supervisor approves them and these can never be edited until the
after evaluation at the end of the financial year. After evaluation, reports can therefore be
extracted from BSCIMS.
2.2.1.3 Hardware Interfaces
This system has no hardware interface requirements.
2.2.1.4 Software Interfaces
For the GUI, the system will require Twitter Bootstrap3 (a CSS framework) and Angular.js for
front-end interactivity. The GUI will not be limited to the size of the user's screen due to it being

CS400-Report 18
bootstrapped. Node.js will be the intermediate between the front-end (via Angular) and the back-
end, which will be purely JavaScript oriented. For the DB MongoDB will be used (a NoSQL
document oriented database written in JavaScript).
2.2.1.5 Communication Interfaces
None.
2.2.1.6 Memory Constraints
This mainly depends on the OS and web browser in use; however, the average memory
needed for low-end systems should be around 32 to 64 MB RAM.
2.2.2 Product Functions
BSCIMS, will be online 24 hours per day and 7 days a week. It will allow goals and objectives to
be set and employees’ performance to be stored under a central data store, for ease of reporting.
The displayed info will depend on the employee’s profile.
2.2.3 User Characteristics
There will be no expected skills from the user except for the general browsing skills. He/she is
expected to know the departmental goals for that financial year although this has nothing to do
with BSCIMS. In short, BSCIMS will be used by any internet friendly user, i.e. anyone who has
minimum skills on basic web browsing. Moreover, an employee of the company has to be
registered in the system.
2.2.4 General Constraints
As a web-based system, BSCIMS' primary constraint is the lack of a fully functional serve
dedicated to web-hosting. Although this will be overcome by a Node.js server built on the
Express lightweight framework and run on the development workstation. Also the low
bandwidth network used, along with proxy restrictions might be an expected constraint on the
overall system development. There are no other anticipated direct constraints.

CS400-Report 19
2.2.5 Assumptions and Dependencies
For the fundamental use of BSCIMS, access to a computer with internet connection and a
commonly used web-browser is assumed. No dependency on the OS is defined thus far.
However, English as a proficient language is very much assumed.
2.2.6 Apportioning of Requirements
1. There is always scope for usability improvement.
2. Enhancing the speed of usability of the UI.
2.3. Specific Requirements
2.3.1 External Interface
2.3.1.1 User Interfaces
All interactions with the user takes place through the web-based GUI. The user, however must
first log in using their user-name and password (which will be defined under the company's
LDAP server). The UX is enhanced by a simple menu based UI, which will have tabs for clear
distinction of the various modules to be used. All operational keys will be clearly labeled with
simple English, for instance ‘Submit’ or ‘Login’. Graphics will be kept to a minimum and
compatibility between color palettes will be maintained for an even better UX.
2.3.1.2 Hardware Interfaces
No specific hardware interface requirements are demanded for BSCIMS, other than the normal
workstation (which has basic I/O devices, e.g. mouse/touch pad, CRT/LED screens, and
keyboard/keypad).
2.3.1.3 Software Interfaces
Software interface requirements for BSCIMS are basic, that is an OS (UNIX based and
Windows) and a web-browser.
2.3.1.4 Communications Interfaces
BSCIMS, will be used mainly in one network protocol, LAN, due to an individual company's
confidentiality policy which restricts external access of an organization's sensitive information.

CS400-Report 20
2.3.2 Functional Requirements
In this part of the document, we will lay out all the functional features of the system and describe
the IPO of BSCIMS.
2.3.2.1 Registration
2.3.2.1.1 Introduction
This function will be used by the IT department to register new employees into the system. But
the idea is that once the system is integrated with other systems in the company, the employee
will be automatically a registered user once he is entered in the employees’ database.
2.3.2.1.2 Inputs
 Basic personal information like: name, gender, age.
 Contact details like: email address, mobile number.
 Work info like: position, department.
2.3.2.1.3 Processing
The processing will involve capturing the data from the fields via Angular.js and parsing it to
Node.js which will insert the data into the relevant document in the database after successful
connection.
2.3.2.1.4 Outputs
It will then display a notification message below the form to acknowledge successful entry.
2.3.2.1.5 Error Handling
In the event of erroneous data entry, the specified fields should indicate a red outline to alert
invalid entry and a pop up will display in the event of an unfilled input field which is mandatory.
2.3.2.2 Login
This function will verify and validate a user login before access to BSCIMS, is granted.
2.2.3.2.2.2 Inputs

CS400-Report 21
 There will be two fields for the login, i.e. Username and Password.
This part will read data from the login form and compare it with the data in the database to verify
user account existence and verify if the given info is correct.
2.3.2.2.4 Output
 After a successful login, the home page will be displayed to the user. Other info and
actions the user can do will depend on his/her profile.
 It should also have a mini profile at the top right corner displaying the user avatar and the
user name below it.
If the entered user info is incorrect, a prompt message will display below prompting the user to
re-enter the info, followed by a hyper-link with a ‘Request Password’ text which will email the
IT department in request for a password change.
2.3.2.3 Create Objective
This function will allow the user to create goals and assign those goals to metrics that will be
used to measure the employees’ performance by how well he/she achieved the objective. The set
objective should be measurable.
2.3.2.3.2 Input
The user will specify which perspective that objective belongs to, insert the objective
description, and metric for measuring the objective. The status and the date will be captured by
the system when the objective is submitted.
The processing will involve capturing the data from the fields via Angular.js and Node.js will
insert the data into the relevant document in the database.

CS400-Report 22
2.3.2.3.4 Output
For a successfully submitted objective, an alert message will be displayed on the screen below
the objectives form, notifying the user of a successful objective creation. An email should then
be sent to the employee’s supervisor alerting him/her of the created objective.
In the case important fields were not filled or were mis-entered, an error warning the user of such
will be displayed. The fields with the errors will be outlined with light red.
2.3.2.4 Edit Objective
This function will be used by either the employee or supervisor to make a change on an objective
he/she finds unsatisfactory. This will only be allowed to be done on pending objectives, one that
haven’t been approved.
2.3.2.4.2 Input
There is no specific input for this function except for the fields found in the create objective that
will be modified.
The data already in the database will be overwritten by the new data. The process is still the
same, capturing the data from the fields via Angular.js and Node.js will insert the data into the
relevant document in the database. The proper objective will be identified by its primary key.
2.3.2.4.4 Output
After a successful modification of an objective, an acknowledgement message will be displayed
on the screen.
In the event one is trying to modify an approved objective, an error message will be displayed
warning the user of such action.

CS400-Report 23
2.3.2.5 Approve Objective
The approve function will be used by supervisors to approve their subordinates’ objectives after
they have discussed them and agreed that they are proper. It is worth specifying that the
supervisor will only be able to approve objectives for individuals only under him.
2.3.2.5.2 Input
There is no input but just a button which modifies the status of the objective.
Once the approve button is pressed, that will be captured and the relevant objective(s) will have
their status modified from pending to approved. This objective(s) will then be locked and they
can no longer be modified.
2.3.2.5.4 Output
An acknowledgement message for a successful approval of message will be displayed on the
screen.
In the event an already approved objective is selected among many, the user will be warned of
such.
2.3.2.6 Create Report
This function will likely be the most used. It will allow the user to be able create a reports. This
will work for the HR department which is much more interested in how the company has
performed. This function will be usable once evaluation of employees in the company has been
done. Previous financial year performance data can also be available from the system.
2.3.2.6.2 Input

CS400-Report 24
The report being shall only be given a name. Otherwise, the user will select the info he/she wants
to be part of the report. Again, the employee’s profile will determine the info he/she can access.
The selected info will be queried in the database.
2.3.2.6.4 Output
It should display the requested info the way the user has selected it. The display may be in the
form of a table, graph, pie chart or bar chart depending what the user would want to use.
In the event the employee request for info he/she doesn’t access to, an error message warning the
user of such will be displayed.
2.3.2.7 View
This function will allow employee or supervisor to be able to view info from the system. For
instance the employee would like to view a list of his/her approved objectives.
2.3.2.7.2 Input
There is no specific inputs for this function.
The requested information will be queried from the database and returned to user.
2.3.2.7.4 Output
The info that the employee has asked for will be displayed. This info is most likely to be in the
form of a table.

CS400-Report 25
In the event the employee tries to view info he/she doesn’t access to, an error message warning
the user of such will be displayed.
2.3.3 Performance
BSCIMS being a web-based system running on the company's LAN, will be easily accessible so
long as there is a network connection. This then requires fast connections that have minimum
faults and preferably higher bandwidth due to the rich content entailed in the system.
2.3.4 Design Constraints
2.3.4.1 Standard Compliance
 All transactions made by a user to the system will be stored in the transaction relation.
 Only pending objectives can be edited. Once the objective is approved, it cannot be
edited. Objectives of an employee are approved by the supervisor of that employee.
 Contents viewed will depend on the user’s profile.
2.3.4.2 Hardware Limitations
BSCIMS, does not have specific hardware limitations, all that is required is a workstation with
internet access and fully operational I/O devices.
2.3.5 System Attributes
2.3.5.1 Availability
Due to the fact that BSCIMS will be running on LAN, availability will be round the clock
(provided the web servers are up and running). The system will be available all the time as long
as one is able to connect to the network. This is under the assumption that all other requirements
like the web-server and user workstations are working optimally.
2.3.5.2 Security
Employees of the company will have access to the systems content, therefore each and every
login will act as an authentication signature to all the sensitive details and modules. This will

CS400-Report 26
also act as a restriction to employees on the content that they can be able to view since the
contents will be linked to the employee’s profile.
2.3.5.3 Efficiency
BSCIMS will efficiently provide a suitable environment for the company to manage its
performance using the BSC. It is expected to be a pure BSC information system that will be
sufficient for the company in managing its performance data.
2.3.5.4 Maintainability
Due to the application being developed on the MEAN stack, comprising of new and growing
technologies which are all purely JavaScript oriented, it is made in such a way that it will be easy
to maintain and improve.

CS400-Report 27
2.3.6 Logical Database Requirements
The logical database structure in ER model for a typical relational model is given below:

CS400-Report 29
Typically, since a NoSQL database will be used, so it will not necessarily be relational. The
actual structure of the database is shown below:
Division: {DivNo, DivName, GM, Department {DepNum, DepName, DepManager, Section
{SecNum, SecName, SecHead, NumOfEmp, Employee {PfNo, EmpName, DOB, Gender,
Email_Addr, Position}}}}
Transaction: {TransID, TransDescr, TransType, TransTime, PfNo}
Document: {DocNum, DocName, Author, Perf_ID, PfNo}
Objective: {ObjID, ObjDescr, DateSet, Status, PfNo, SecNum, DepNum, DivNum}
Perf_Rating: {Perf_ID, Perspective, Measure_and_Target, Score, ObjID}
Chapter 3 – Design Specifications
3.1 Introduction
3.1.1 Purpose

CS400-Report 30
The purpose of this DSD is to complement the SRS in as far as designing the entire BSCIMS
system. This document will give a detailed design of the system from the UI to the database
structure and go further into the technologies implemented and the server design used.
3.1.2 Scope
The SDD will give all the design details required to fully implement the BSCIMS system as
specified by ISO International Standards. The document will cover the structure of the database
UI and how the modules work and are linked together from the server side to the client side.
3.1.3 Definitions, Acronyms, and Abbreviations
Any abbreviation and short hand notation that will be used in this document will be expressed
fully below:
SEC – Swaziland Electricity Company
ISO – International Standardization Organization
BSC – Balanced Scorecard
BSCIMS – Balance Scorecard Information Management System
DBMS – Database Management System
GUI – Graphical User Interface
UI – User Interface
UX – User Experience
OS – Operating System
IE – Internet Explorer
LAN – Local Area Network
LAMP – Linux Apache MySQL PHP/Python stack
MEAN – MongoDB, Express, Angular.js & Node.js stack
SRS – Software Requirements Specifications
DSD – Design Specifications Document
WWW – World Wide Web
I/O – Input/output
IPO – Input Process Output
CRT – Cathode Ray Tube
CRUD – Create Read Update Delete

CS400-Report 31
LED – Light Emitting Diode
HR – Human Resources
NoSQL – Not Only SQL
KPA – Key Performance Area
KPI – Key Performance Indicator
LDAP – Lightweight Directory Access Protocol
PF – Provident Fund
BCW – Broad Category Weightings
3.2 References
None
3.3 DecompositionDescription
3.3.1 Module decomposition
BSCIMS is a web-based GUI which will primarily allow SEC to implement the BSC concept to
manage its performance. The idea is that an employee will be allowed to set objectives (KPA) at
the beginning of the financial year. The employee’s supervisor will be notified via email, which
he/she will, in turn, approve if objectives are satisfactory or edit unsatisfactory ones. The
supervisor is also allowed to set goals for the employee. Once the employee and supervisor have
agreed on the objectives, the supervisor approves them and these can never be edited until the
after evaluation at the end of the financial year. After evaluation, reports can therefore be
extracted from BSCIMS. This reports can then be used by the Executive Committee to see the
overall performance of the company.
(Refer to the context diagram on Fig 3.4, Pg. 46)
Data Flow Diagram:
(Refer to the Data flow diagram on Fig 3.5, Pg.47)
3.3.1.1 Login Module Description
3.3.1.1.1 Type
3.3.1.1.2 Purpose

CS400-Report 32
Since the system will be integrated with the company's NOVELL LDAP system, which
will synchronize the user accounts along with their credentials, logins will be automatically
matched with internal user info. This is where the actual login will occur.
3.3.1.1.3 Input/Output
Input: User name and Password.
Output: Successful login or unsuccessful login.
3.3.1.1.4 Function
The login module is used for logging into the system.
3.3.1.2 Authenticate User Module Description
3.3.1.2.1 Type
3.3.1.2.2 Purpose
The Authenticate User module is for checking and authenticating employee login credentials
by cross-referencing it with the LDAP server.
Input: User name and Password.
Output: Successful login or unsuccessful login.
3.3.1.2.4 Function
Authenticate User module is used to validate if the user logging in is a staff member or if the
user name and password are inputted correctly. If the user is indeed an employee and his/her
details match those found in the NOVELL LDAP server.
3.3.1.3 Display Account Module Description
3.3.1.3.1 Type
3.3.1.3.2 Purpose
After a successful login, the employee’s account will be displayed under the 'My Account'
section in the top right corner of the UI. This will be done by the display account module.
Input: none.
Outputs: User’s basic Information.

CS400-Report 33
3.3.1.3.4 Functions
This module displays basic details about the logged in employee. For example, the logged in
user’s name and PF number.
3.3.1.4 Create Objective (KPA) Module Description
3.3.1.4.1 Type
3.3.1.4.2 Purpose
This module allows the logged employee to create a KPA, informally known as an “objective”
on which he will focus his work on and be evaluated on.
Input: an objective description, desired standard output and metrics along with definitions.
Output: none.
3.3.1.4.4 Function
The module’s function is to allow logged in employees to create and define their performance
objectives and performance metrics before submitting them to his supervisor for approval.
3.3.1.5 Submit Objective Module Description
3.3.1.5.1 Type
3.3.1.5.2 Purpose
The Submit Objective module allows employees that have created objectives to email them
to their respective supervisor for approval.
Input: An existing objective.
Output: An objective waiting for approval.
3.3.1.5.4 Function
The sole function of this module is to send an internal email (within an organization) to the
superior or project lead.
3.3.1.6 Approve Objective Module Description
3.3.1.6.1 Type
3.3.1.6.2 Purpose
This module is to be used by supervisors to approve submitted objectives. Supervisors will

CS400-Report 34
only be able to approve objectives of employees under them.
Input: Submitted objectives
Output: Approved Objectives
3.3.1.6.4 Function
To change the status of submitted objectives from pending to approved.
3.3.1.7 Compile Performance Contract Module Description
3.3.1.7.1 Type
3.3.1.7.2 Purpose
Once the submitted objectives have been approved by the employee's project lead, only then
can they be used to create a Performance Contract (Scorecard).
Input: Approved objectives.
Output: Scorecard.
3.3.1.7.4 Function
The convert all approved objectives into an official scorecard.
3.3.1.8 Evaluate Scorecard Module Description
3.3.1.8.1 Type
3.3.1.8.2 Purpose
After a scorecard's lifetime (duration defined to completion of tasks) has been exhausted, it
must be graded or evaluated by the team lead.
Input: Completed scorecard.
Output: Evaluated scorecard.
3.3.1.8.4 Function

CS400-Report 35
This module's function is simple, in that the team lead gets to input numerical values alongside
the objective that has been worked on (based on his/her discretion).
3.3.1.9 Calculate BCW Module Description
3.3.1.9.1 Type
3.3.1.9.2 Purpose
Since every scorecard has a 'Detailed Weightings' column, the BCW is basically the total of all
the weightings in a specific perspective/category.
3.3.1.9.3 Input/ Output
Input: Detailed Weightings
Output: Broad Category Weightings.
3.3.1.9.4 Function
Sum up all Detailed Weightings in a scorecard's category - in percentage (%).
3.3.1.10 View Dashboard Module Description
3.3.1.10.1 Type
3.3.1.10.2 Purpose
An information management system is not complete without a dashboard, therefore this
module will create the real-time graphical presentation of the organization's performance data.
Input: Performance data (KPIs, completed tasks, pending, etc).
Output: Graphical presentation in form of charts (pie, bar, etc).
3.3.1.10.4 Function
To give a real-time progress report of tasks an employee is accountable for.
3.3.1.11 Create Reports Module Description
3.3.1.11.1 Type
3.3.1.11.2 Purpose
To provide a clear reporting functionality to give recordable information on past performances.
Input: Performance data.

CS400-Report 36
Output: Performance information.
3.3.1.11.4 Function
The function of this module is to provide a simple reporting interface that will be able to
retrieve the required information from the database.
3.3.1.12 Logout Module Description
3.3.1.12.1 Type Session
3.3.1.12.2 Purpose
To terminate a running session of a logged employee.
Input: none.
Output: none.
3.3.1.12.4 Function
Logs the employee out of application by disconnecting session from database.
3.3.2 Data Decomposition
3.3.2.1. Employee Database Description
3.3.2.1.1. Type MongoDB
3.3.2.1.2. Purpose
This data store keeps all employee records and credentials.
3.3.2.1.3. Function
It stores information which includes (Employee name, Password, Position, Email, PFNumber
etc.) to be used during login and some of the information is to be displayed in the employee
profile.
3.3.2.2. Division Database Description
3.3.2.2.2. Purpose
This data store or “document” (MongoDB terminology) is where the company divisions will be
kept, such as: Finance, Customer Services, Operations. This is a decomposition of the company

CS400-Report 37
structure.
3.3.2.2.3. Function
It stores division information and records, such as: Division name, Number of Employees, and
the General Manager (GM) for that particular division.
3.3.2.3. Department Database Description
3.3.2.3.2. Purpose
This data store stores the departmental information (which in this case is a level below the
division.
3.3.2.3.3. Function
It stores records about the department name, its location, and the department manager.
3.3.2.4. Section Database Description
3.3.2.4.2. Purpose
This collection will store the next lower level below the department, that is the section – which is
the most refined level in the company.
3.3.2.4.3. Function
It stores the section name, number of employees in that section, as well as the section head.
3.3.2.5. Objective Database Description
3.2.5.2. Purpose
The purpose of this data store is to keep the actual objectives that an employee will create for
evaluation.
3.3.2.5.3. Function
This collection is the geest of the system, it will hold valuable information, such as the objective
description, the date set, the objective status (approved, pending, complete, etc), as well as the
duration of that objective.
3.3.2.6. Document Database Description

CS400-Report 38
3.3.2.6.2. Purpose
The purpose of this data store is to store information about relevant performance evidence, such
as call logs, reports, paper work, time sheets, etc.
3.3.2.5.3. Function
It will keep the document name, document author, as well as the document number or source.
3.3.2.7. Metric Database Description
3.3.2.7.2. Purpose
The performance of an employee has to be evaluated, based on a metric scale. This is the
collection that keeps the measures.
3.3.2.7.3. Function
It holds the details of the chosen perspective to be worked on, the rating, as well as the score
3.3.2.8. Transaction Database Description
3.3.2.8.2. Purpose
The transactions between a user and the application will be recorded and stored in this collection.
3.3.2.8.3. Function
It holds the transaction date, description and type.
3.4 DependencyDescription
3.4.1. Intermodule dependencies
3.4.1.1 Purpose
The purpose of this dependency is that modules defined in section 3.1.1 to section 3.1.11
must use updated data and must link together seamlessly.

CS400-Report 39
3.4.1.2 Dependencies
Dependencies amongst modules are described as follows: since the first and key module is the
login module, therefore every other module is dependent on this prerequisite module (3.1.1). The
next module is the authenticate module (3.1.2), which follows immediately after (3.1.1) in order
of execution. Only after authentication, can the display module (3.1.3) be functional. Modules
(3.1.4), (3.1.9) and (3.1.10) all depend on the authentication module, which are create objective,
dashboard, and report modules, respectively. Submit objective (3.1.5) relies on (3.1.4) since only
a created or existing objective can be available for submission. Compile scorecard (3.1.6)
follows (3.1.5), due to the fact that, once a submitted objective's status has changed to
“Approved” can a complete scorecard be drafted. Soon after, calculate BCW (3.1.8), based on
the scorecard's detailed weightings can be directly linked to (3.1.6). Then the evaluate module
(3.1.8), based on (3.1.7) and (3.1.9), can be executed. The dashboard module (3.1.10) and report
module (3.1.11), based on (3.1.2), as mentioned earlier, also depend on (3.1.5-7), since static
reports as well as dynamic ones will require the data from the listed modules. Finally, logout
(3.1.12) can only occur in the event (3.1.2) was successful, thus depending on authentication.
3.4.2. Data dependencies
3.4.2.1 Employee Database Dependency
3.4.2.1.1 Type
3.4.2.1.2 Purpose
This data store is used by modules defined in section 3.1.2 and 3.1.12; they can only be
operational once the employee information can be found in the employee database.
3.4.2.1.3 Dependencies
Modules in 3.1.2 and 3.1.12 use the employee data for an uninterrupted application session,
therefore a direct communication between those modules and this collection is paramount.
3.4.2.2 Section Data dependency
3.4.2.2.1 Type

CS400-Report 40
3.4.2.2.2 Purpose
The section data contents are used by module defined in 3.1.5, submit objective as well as
evaluate, defined in 3.1.8. This is solely because an employee submits to his manager or
supervisor, and this is defined in a section (since this is set to be the most refined, subatomic,
structure of a company).
Modules in section 3.1.5 and section 3.1.8 retrieve a user's manager and enlists them as an
email recipient for the objective submission.
3.4.2.3 Objective Data Dependency
3.4.2.3.1 Type
3.4.2.3.2 Purpose
This data collection is firstly updated by module in section 3.1.4, create module, and it gets used
by submit objective in 3.1.5 and compile objective in 3.1.7.
Modules in section 3.1.5 to 3.1.7 depend on the objective data store. Module 3.1.5 grabs the
selected objectives (retrieved from the collection) and operates on it. Likewise, 3.1.7 compiles a
scorecard based on the selected objectives from the same data store – provided they have a status
of “Approved”.
3.5 Interface Description
3.5.1 Module interface
3.5.1.1 Login Module
3.5.1.1.2 Function

CS400-Report 41
The Login module acts as a security portal or gateway into the BSCIMS system. It's intended
functionality is to retrieve employee credentials based on the synchronization between it's
employee collection and the company's NOVELL LDAP server, which is a centralized collection
of all employee data.
3.5.1.1.3 Interfaces
The module is designed to be simple and direct. All that is required is the employee username
(also defined as “sec<Pf Number>” - e.g sec904), followed by their NOVELL password.
The below diagram will show the functional login as well as the tip, informing the employee on
what info to use during login.
Fig 3.1 – BSCIMS prototype login
3.5.1.2. Create Objective Module
3.5.1.2.1 Function
This is the main activity module within BSCIMS, it allows the logged in employee to create an
objective and define its details.

CS400-Report 42
3.5.1.2.2 Interfaces
This module requires the employee to first select a perspective in which he/she wishes to create
an objective for. Next is the objective definition followed by the desired standard output (DSO)
which becomes the expected delivery in that employee's performance? Lastly, the employee
defines the metrics to be used during his evaluation; as seen below.
Fig 3.2 – Create objective module prototype
3.5.2. User Interface

CS400-Report 43
The below figure shows an overview of the entire application. As seen, the quick actions (gray
tabs with icons), will be the core of the application. Employees will use them in the order in
which they appear; 1. Create an Objective (KPA), 2. Submit Objectives, 3. Compile Scorecard.
The employee account details will be found in the top right corner under “My Account”.
The Dashboard tab in the menu section will take the user to the dashboard page, likewise with
the other tabs.
Fig 3.3 – Prototype UI
3.6 DetailedDesign

CS400-Report 44
3.6.1 Module detailed design
3.6.1.1 Login Module
Begin {module}
Capture data from user // “sec<pf>” and “password”
Validate user
End;
End {module};
3.6.1.2 Authenticate Module
Begin {module}
Query Novell LDAP Server's listed users and compare values with entered vales
If entered “sec” and pf number combination does not match, then
Show error message and reload login page
Else
Log in user by starting session with database and create cookies in browser
Direct to interface page
End;
End {module};
3.6.1.3 Display Account Module
Begin {module}
Retrieve data from NOVELL LDAP server
Embed MongoDB JSON results into Angular.js code and display
End {module};
3.6.1.4 Create Objective Module
Begin {module}
Upon perspective option change, display appropriate form
If form is “Finance Objective”

CS400-Report 45
Capture “FinanceDescription (KPA)”, “DSO (KPI)” and all 5 performance metrics
Else if form is “Customer Objective”
Capture “CustomerDescription (KPA)”, “DSO (KPI)” and all 5 performance metrics
Else if form is “Internal Business Objective”
Capture “InternalDescription (KPA)”, “DSO (KPI)” and all 5 performance metrics
Else if form is “Learning & Growth Objective”
Capture “Learning Description (KPA)”, “DSO (KPI)” and all 5 performance metrics
End;
Upon “Submit Objective”, Store data in Objectives collection (MongoDB)
End {module};
3.6.1.5 Submit Objective Module
Begin {module}
Retrieve data from Objective
On “selected” objectives, capture and embed in email template
From hierarchy of staff structure, attach manager's email address to recipient
On “Submit Objective”, email objectives to employee manager
End {module};
3.6.1.6 Compile Performance Contract Module
Begin {module}
Query Mongo and display Objectives with “Approved” status
Attach approved objectives to Scorecard template
End {module};
3.6.1.7 Evaluate Scorecard Module (Manager Module)
Begin {module}
Retrieve data from selected employee scorecards
Add “evaluate” and “comment” fields to end of scorecards

CS400-Report 46
End {module};
3.6.1.8 Calculate BCW Module
Begin {module}
For each perspective's objective field in scorecard, capture all detailed weightings
Add all objectives' detailed weightings in each perspective
Sum becomes BCW
End {module};
3.6.1.9 Dashboard Module
Begin {module}
Capture all data from data store required for dashboard: employee details, submitted
objectives and scorecard
For each objective and scorecard, check for status and group all “pending”, “approved” and
“completed”
Create graphic data representations for each
End {module};
3.6.1.10 Reports Module
Begin {module}
Capture all data from data store required for dashboard: employee details, submitted
objectives and scorecard
For each objective and scorecard, check for status and group all “pending”, “approved” and
“completed”
Create reports on all by inserting into table tags for tabulation of data
End {module};
3.6.1.11 Logout Module
Begin {module}
Upon “Logout”, end session with database and clear cookies.
Reload “Login page”

CS400-Report 47
End {module};
3.6.2. Data detailed design
This is similar to the one provided in the SRS. Refer to page 27.
3.7 TraceabilityMatrix
SRS
Section
Description SDD Description
2.3.2.2 Login Module 3.3.1.1 Used by users to log into the
system
Authenticate Module 3.3.1.2 Used to check logging in
user’s credentials.
Display Account Module 3.3.1.3 Displays the logged in user’s
details
2.3.2.3 Create Objective Module 3.1.4 Used by user to create
his/her objectives.
Submit Objectives Module 3.3.1.5 For submission of objectives
for approval by supervisor.
2.3.2.5 Approve Objective Module 3.3.1.6 Used by supervisor to
approve objectives.
Compile Performance
Contract(Scorecard)
Module
3.3.1.7 Used to compile the
scorecard for approved
objectives.
Evaluate Scorecard Module 3.3.1.8 Used by supervisors to
evaluate the employee’s
performance by input
numeric values.
Calculate BCW Module 3.3.1.9 Sums up all detailed
weightings in scorecard.
Dashboard Module 3.3.1.10 Displays real time reports
2.3.2.6 Create Reports 3.3.1.11 Information retrieval for
proper evaluation

CS400-Report 48
Logout Module 3.3.1.12 For termination of running
session.
Table 3.1 – Traceability matrix between the SRS and DSD
Context Diagram
Fig 3.4 - Context Diagram referenced on Section 3 Pg. 29

CS400-Report 49
Data Flow Diagram
Fig 3.5 - Data Flow diagram referenced in Section 3 Pg. 29

CS400-Report 50
Chapter 4 – Implementation and System Testing
4.1 Introduction
In this section, a brief description of the system implementation and testing will be highlighted.
The section will not get into detail of the system implementation. That is, the code will not be
attached. The tools used during the implementation and then the testing technics used will be
elaborated with their relevant results. It is worth mentioning that because of time the system was
limited to the creation of an objective for the project. A use-case diagram is shown below which
shows the general overview of the system. The highlighted part shows the core of the project. An
employee sets his/her objectives (KPA). He/she sends these to the supervisor for approval. The
supervisor can then edit and approve or discard the objectives. From the approved objectives the
employee can then compile his/her scorecard.
Fig 4.1 A use-case diagram highlighting the core of the project

CS400-Report 51
4.2 Implementation
As mentioned in the introduction that the code will not be attached here but only the tools used
will be listed. For the GUI, the system will require Twitter Bootstrap3 (a CSS framework) and
Angular.js for front-end interactivity. The GUI will not be limited to the size of the user's screen
due to it being bootstrapped. Node.js will be the intermediate between the front-end (via
Angular) and the back-end, which will be purely JavaScript oriented. For the DB MongoDB will
be used (a NoSQL document oriented database written in JavaScript).
4.3 Testing
The system was first tested dynamically where the code was inspected for any bugs. After that it
was tested dynamically by inserting data into the system and monitoring if the required results
are obtained. The results are shown below under the module that was tested.
4.3.1 Login
A user is automatically an employee. This shown by the figure below:
Fig 4.2 – Login Screen

CS400-Report 52
4.3.2 User Interface
Fig 4.3 – UI for employee

CS400-Report 53
4.3.3 Creating an Objective
Fig 4.4 – Creating an objective
After the objectives are created and submitted. The employee will then select those he/she want
send to the supervisor for approval. As shown on the next screen shot.

CS400-Report 54
Fig 4.5 – Submitting objectives
4.3.4 Supervisor and HR officer Login
Fig 4.6 – Supervisor and HR Login screen

CS400-Report 55
4.3.5 Supervisor and HR officer UI
Fig 4.7 Supervisor and HR officer Screen

CS400-Report 56
4.3.5 Approving Objectives
Fig 4.8 – Approving Objectives Screen

CS400-Report 57
4.3.6 Compile Scorecard
Fig 4.9 – Compiling a Scorecard Screen

CS400-Report 58
4.3.7 Compiled Scorecard
Fig 4.10 – Compile Scorecard
4.3.8 Logout

CS400-Report 59
Fig 4.11 – Logout
Chapter 5 – Conclusion and Future Work
5.1 Conclusion
The Balanced Scorecard Information Management System (BSCIMS) is a very sophisticated
performance management system that implements the Balanced Scorecard. BSCIMS obeys the

CS400-Report 60
rules in as far as the balanced scorecard concept is concerned. A scorecard can only be compiled
if it has objectives balanced in all the four perspectives: finance, customer, internal business
processes and learning and growth. BSCIMS also provides a communication between the
supervisor and employee through email. This is a professional and much more efficient manner
of communication compared to that provided by the paper-based system that was used. BSCIMS
is not accessible 24 hrs a days due to that it is web-based, it is also integrated with other systems
in the company. That is, data from other systems in company can be retrieved for use in
BSCIMS. That is, the culture and structure of an organization can be incorporated into BSCIMS.
Since BSCIMS was able to solve the problems with the current performance system in
Swaziland Electricity Company and BSCIMS is 70% complete, one can conclude that the project
was successfully done.
5.2 Future Works
Even though, the projects goals were met the software is not yet complete. There is still more
things to be done to improve BSCIMS’ functionality. The future works are listed below:
 Under “Create Objective”: the available metrics have to be fine-tuned and additional
types of metrics have to be added in to the system. The metric to be included is the date
and numerical metric.
 Under “HR module”: An HR individual should be able to add and remove and employee
from the system. This functionalities are yet to be added into the system. HR should be
able to view scorecard for all employees. This should be separated in years
 Overall Evaluation and Reporting Function: Self-evaluation function on the employee
level. Employee should be able to attach documents as evidence of evaluation. Supervisor
evaluation on the supervisor level. Company evaluation on the HR level. A reporting
function will also be added.
Appendix
User Manual (Not included in the draft report)
SYSTEM USER MANUAL

CS400-Report 61
1. LOGIN
The system is currently installed and running in a server situated in the MS2.1 computer
laboratory and can be accessed via the URL : “192.168.4.21:3002”. The application works
optimally on the Google Chrome web browser (due to this platform being fully supportive of the
technologies used in building the system, i.e: Angular.js and Node.js)
Once the system loads in the user's browser, a login page is encountered, which has three distinct
access levels; Employee, Supervisor and Human Resource.
1.1. EMPLOYEE LOGIN
Since this system is centered around employee performance, the default login (as seen in Fig 4.2)
is that of an employee. This is enforced by automatically checking or selecting the 'Employee'
check-box.
As an employee, provide your login details – as hinted in the blue notification bar – which are
the user-name (comprised of the characters 'sec' concatenated with your PF number), e.g sec904,
and the password being used for the company's NOVELL LDAP authentication. Once all the
information has been carefully entered, proceed to the login button.
1.2. SUPERVISOR LOGIN
As the next essential user of the system, the supervisor (who is also an employee) can either
choose to login as a supervisor – allowing him/her to view his subordinates' submissions – by
selecting the 'Supervisor' check-box, or simply login as an employee without any selection (as
the system checks the Employee field), Fig 4.6. Logging in as a supervisor is an elevated access
level in the application and security checks are done by cross referencing accounts in the
database, allowing only assigned supervisors to login.
1.3. HUMAN RESOURCES LOGIN
Finally, the human resource officer, as the company's employee regulator, gets an even higher
access level to that of a supervisor. This login is facilitated by the selection of the last check-box
'Human Resources' and gives access to a part of the system only the HR officer is allowed to
view, such as overall departmental performance (dissipatable to the single employee), Fig 4.6.

CS400-Report 62
2. CREATE AN OBJECTIVE (KPA)
To create an objective or KPA, click on the 'Create an Objective (KPA)' button, graphically
marked with a plus sign (+), Fig 4.4. This calls a modal to fade in, which contains the main
forms for creating an objective. A selection is available to pick the appropriate perspective in
which an objective is to be created for. Upon perspective selection, a form slides down with the
fields 'Objective (KPA)', 'Desired Standard Output (KPI)' and 'Performance Rating'. All fields
require to be filled before the action is done, in the event one of the fields is neglected, an error
message appears below the outstanding field; advising you to enter relevant data. Once all the
fields are filled, the 'Submit Objective' button is clicked to finalize the action. After which, the
user can close the modal by appropriately clicking on 'Close'.
3. SUBMIT OBJECTIVES
To submit objectives, click on the 'Submit Objectives' button, this will invoke a modal on to the
screen which will contain a perspective selection field and an empty table captioned 'Objectives
to be sent', Fig 4.5. First select a perspective, then a table containing the objectives recently
created for that perspective will appear. Next to each objective (on every row), there is a check-
box that is used to select a required value. Each objective selected will populate the empty table
until all objectives that are ready for submission, have been selected. Once the table is filled, the
supervisor's email is confirmed in the recipient's email textbox, then after clicking the 'Send
Objectives' button, an alert will slide down in green to confirm that an email has been sent to the
supervisor with a notification.
4. APPROVE OBJECTIVES
To approve objectives, (the supervisor) click on the supervisor tab to reveal the 'Employee KPAs
in your tray' system info which once clicked, a table containing the employees who sent
objectives drops down (as seen in Fig 4.8). Each employee name acts as a link and can be clicked
as well to invoke a modal containing that clicked employee's objectives. The form is initially

CS400-Report 63
locked to avoid unintentional tampering with the contents, but should the need to edit arise then
the 'Edit Objective' button is used to unlock the form. After editing the employee's objective,
click on the 'Lock Objective' (previously clicked to edit), then once the objective has been
approved, finalize the action by clicking the 'Approve Objective' button. A notification should
drop down once the action is completed successfully.
5. COMPILE SCORECARD
An objective, once approved, culminates as an element in a scorecard. By clicking on the
'Compile Scorecard' button, a modal with all the approved objectives in four tables (each for a
perspective) will slide down the screen, Fig 4.9. These objectives are then selected as elements
for the scorecard, all tables must have at least one objective selected (in the event one of the
tables has no selected row, an error message is displayed below the table). Proceed to the
'Compile' button to reveal the scorecard (performance contract), Fig 4.10.
6. SEARCH
The search functionality is available above every table. An input field is used to search the table
as a quick action. The search is on every key-up action, thus refining the results on every key
press.
7. LOGOUT
All running sessions in the application are terminated upon clicking the 'Logout' button, found
under the 'My Account' drop-down, Fig 4.11.
References
1. Bloomfield C. (2002), Bringing the Balanced Scorecard to Life: The Microsoft Balanced
Scorecard Framework, Insight formation, Inc.

CS400-Report 64
2. Bose S. and Thomas K. (2007), Applying the balanced scorecard for better performance of
intellectual capital, Journal of Intellectual Capital, Vol.8 No. 4, pp. 663-665
3. Dr. Alex Nunn, Centre for Applied Social Research Leeds Metropolitan University (In
collaboration with KF GHK and Budapest Institute
4. Dr. Pulakos E. D. (2004), Performance Management – a roadmap for developing,
implementing and evaluating performance management systems, SHRM Foundation, USA
5. Frost, B., Measuring Performance: Using the New Metrics to Deploy Strategy and Improve
PerformanceMeasurement International, Dallas, Texas, 2000.
6. Kaplan, R.S., and Norton, D.P. (1992), “The balanced scorecard-measures that drive
performance”, Harvard Business Review, Vol.70 January-February, pp. 71-90.
7. Kaplan, R.S., and Norton, D.P.(2013), Conceptual Foundations of the Balanced Scorecard
8. Murby L. and Gould S. (2005), Effective Performance Management with the Balanced
Scorecard, CIMA, Great Britain
9. Procurement Executives’ Association, Guide to a Balanced Scorecard Performance
management Methodology
10. Pujas D. (2010), Barriers to the Successful Implementation of the Balanced Scorecard – the
case of the Plava Laguna J.S.C.
11. Virtanen Tony (2009), Guidelines for Implementing Balanced Scorecard, QPR Software plc.
12. www.balancedscorecardaustralia.com Retrieved 7January 2015
13.http://balancedscorecard.org/Software/Balanced-Scorecard-Software , Retrieved 10 January
2015

BSCIMS_Thesis

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Similar to BSCIMS_Thesis

Similar to BSCIMS_Thesis (20)

BSCIMS_Thesis