Faculty: Commerce

Department: Business Management

Program: B.Com (Hon) Human Resource Management

Student Number : L013 0734M

Format : Block

Course : Management Information Systems

Course code : COHR 4103

Lecturer : Mr M Mabhena

Year: 4th Semester: 4.1

Assignment Question

Describe what is involved in each of the following stages of the system development life
cycle;

a. User Requirements Analysis

b. Analysis

c. Logical Design

d. Physical design

e. Testing [25 Marks]

Information systems are increasingly regarded as sources of competitive advantage for
today’s organisations. A paradigm shift from a product and service economy to a knowledge
economy is testimonial to this. In a knowledge economy, systems are invented, reinvented
and upgraded to respond to the evolving needs of customers. System development life cycle
is one of the ways in which these systems are developed or upgraded. It is an iterative process
which follows logical steps from system idea conception to the system review stage. As
demands and needs of customers’ changes, the existing system may fail to satisfy them hence
the need to upgrade, alter or reinvent the system to respond to such changes. The writer of
this essay will describe stages of the system development life cycle particularly the user
requirements analysis, analysis, logical design, physical design and testing.

a) User requirement analysis

This is the precise assessment of the needs of the user of the system. The system should
address the users’ needs so as to increase their efficiency and effectiveness (Shaw &
Zimmerman, 1989). According to Tutorial Point (2014) requirements analysis involves
understanding the goals, processes and the constraints of the system for which the
information system is being designed. It is a systematic and iterative process where
evaluation of present system and processes is done in order to create a more responsive and
effective system.

Stakeholder mapping is necessary to determine all relevant stakeholders who may influence
or be affected by the proposed system. The mapping will provide a list of all stakeholders.
For example let’s say Veterinary Department we want to develop a livestock registration and
tracking system, stakeholders will include Veterinary employees and management, stock
owners, police, village heads, local authorities, abattoirs, transporters, FAO representatives
and other donors with interest in livestock. Obviously their needs will not be the same hence
the need to precisely identify each stakeholder requirements. Interviews, questionnaires,
stakeholders meetings and surveys can be used to collect user requirements.

The needs of stakeholders will be listed in priority order where viability or desirability of
needs are assessed in terms of cost, time and performance factors (Lester, 2014). Involvement
of all stakeholder is expected to improve system quality by providing a more accurate
and complete assessment of user requirements (Cooper, 1988). User involvement will
produce realistic expectations of system capabilities and enhance system ownership and
commitment by the users. The users must be convinced that the proposed system is going to

2|Page
improve their performance and easy or simplify their decision making processes. Once
agreed, the requirements list becomes the “yardstick” used to measure project success. Now
that user requirements are identified, we can now draw a comprehensive document covering
all user requirements known as the User Requirement Specifications (URS). To make sure
that the needs of users are included in the URS, signing as an indication of agreement by the
users may be necessary. This will also enhance user buy-in to the system.

b) Analysis

Careful analysis is needed to identify the data that will be used to produce desired
information. According to Wessels, Grobbelaar, & McGee (2004) the success of every
system is strongly build upon thorough problem identification and understanding of user
requirements. The analysis phase involves analyzing end-user business requirements and
refining project goals into defined functions and operations of the intended system (Appendix
D, n/d). Observation of people at work, interviewing users, questionnaires and studying
procedure manuals maybe used to gather information about the existing system (Van Belle,
Eccles, & Nash, 2003).

A number of analysis tools can be used to investigate the existing system before a new
system is proposed and Critical Success Factor (CSF) is one of such methods. These are
critical factors that directly contribute to the organisation mission. They are key performance
indicators (KPI) which depicts organisation successes. Using our prior example of Veterinary
Department, KPIs may include reduction in stock theft, increased livestock production,
reduction of livestock diseases and outbreaks due to strict movement controls. CSF is used to
help analysing the present system to identify gaps which can be bridged by developing a new
or upgrading the current system. In the system management perspective, poor performance,
system breakdowns, system infiltrations due to poor system security as well as high system
errors may be indicators of system dysfunctional. Cooper (1988) identified large data
processing backlogs, project delays, and the failure of data processing to meet user
requirements as some of indicators that warrantee a system review. By doing this, we are
doing the system investigation.

After determining that the present system has problems, the analyst and the project team will
conduct the feasibility study as part of the analysis. A number of solutions may have been
proposed as remedial to the identified system problems. Feasibility study will enable the
project team to choose the best solution which is practically possible and cost effective.

3|Page
According to Wessels at al (2004), feasibility study can be done on three levels which are
technical, operational and economical feasibility. Technical feasibility is concerned with
determining whether the system deliverables are possible using the available hardware, soft-
wares and other peripheral items. In fact the question is; can the new system be delivered
using the existing infrastructure, software and human capabilities. If not, how much can be
acquired to enhance the existing technology?

Operational feasibility is assessment of whether the new system is compatible with the
existing business culture. The new system should not cause conflicts in the power and politics
base which include reporting relationships, chain of command and resources control. Such
analysis will reveal the willingness and ability of management and users to build and use the
proposed system. The system should be operationally workable. Economic feasibility is
usually done using the Cost Benefit Analysis. Here the question; does the benefits derived
from system worth the cost will be answered. Also important is the organisation ability to
finance such project. Most projects fail because the organisation could not manage to foot the
costs because of financial constraints.

However other authors include legal and schedule feasibility (Appendix D, n/d). Legal
feasibility is assessing if the new system does not infringe the legal rights as stated in legal
instruments where as schedule feasibility is assessing if the project deliverables can be
delivered well on time. This includes the ability to supply resources needed according to time
schedule. So we can see that time, corporate resources and core competencies are some of the
factors that need to be considered under feasibility study. A blue print of the desired and
feasible system is finally produced after a thorough analysis is done which will be the basis
for development of the system design. According to Van Belle at al (2003), the end result of
the analysis stage is the production of user requirement specification (URS) which is the
bases for creating the logical design.

c) Logical Design

Now that the User Requirement Specification has been done we move on to build the system
but this time in an abstract and conceptual rather than physical construct. The logical design
is like an engineering blueprint. This was supported by Sira (2011) that logical specification
consists of the system only existing on paper or in a computer as a blueprint. We are not
concerned about the tangible system deliverables here, but at least how to build them. It
shows all features of the system and how they relate to each other (Wessels at al 2004). For

4|Page
example in a house construction project, this can be the architecture’s plan. This would entail
drawing of a detailed plan of the house, specifying exactly how every part of the building is
constructed and defining dimensions, materials, construction techniques etc. In information
systems context, this will provide the detailed explanation on how sub systems are built and
interrelated to other sub systems. Modelling is term used by Appendix D (n/d) to denote the
activity of drawing a graphical representation of a design. Tools such as Graphical User
Interface, Data Models and Entity Relationship Diagram were further noted by Appendix D
(n/d) as tools for logical designing. Entity relationship diagram is a technique for
documenting the relationship between sub systems or modules to the system. Data Flow
Diagram was identified by Wessels at al (2004) as one such tool. Data Flow Diagrams use
graphical presentation of information flow, clearly showing the relationships of all data items.

d) Physical design

According to Sira (2011), the physical specification comprises the hardware and software
requirements needed to bring the system together in reality. The logical design is transformed
into units, which in turn can be decomposed further into programs and modules. This was
supported by Van Belle at al (2003) when they reiterated that if the logical model calls for the
production of pay cheques and the design does not produce pay cheques, or does not produce
them correctly, then the design is a failure. The physical design should cater for all
information needs presented on the design blue print.

For example, user interface design is concerned with how users add information to the system
as well as the feedback they get from the system. Data design is another sub-task which
depicts how the data is presented and stored within the system. Process design shows how
data moves through the system and how and where it is validated, secured and or transformed
as it flows into, through and out of the system (Dennis & Wixom, 2003).

The type of computers required, operating system software, the type and size of databases,
the size of the client server, how firewalls and routers are fitted for online systems, the
number of sub systems attached to the mainframe, the arrangement of these sub systems; are
some of the system specifications included in the physical design. The layout of the system
components should be congruent to the logical flow diagram. Cohesion refers to the manner
in which elements within a module are linked while “Coupling” is a measure of the
interconnection between modules (Shaw & Zimmerman, 1989). Physical design is the

5|Page
construct of the system with all the hardware and software supporting the function of the
system.

e) Testing

To be convinced that the new system satisfies all the required capabilities and functions,
evaluation of the system against the predefined requirements is necessary. It is important to
uncover “system hiccups” before it is operational because correction at this level is cheaper
as compared to correction when the system is now operational. Bender (2003, p. 21) had this
to say; “the cost difference between finding an error early in the requirements definition
versus once it is in production have been found to be as much as 270 to 1500 times as
expensive.” Therefore a test plan should cover areas such as programmes, system and user
acceptance.

Testing can be done at atomic level, modular level and system level. At atomic we test the
individual parts of the system independently while at modular we test the integrated units of
the system. A module testing is a linked collection of units that makes up a clearly delineated
aspect (module) of the overall system. We will be testing whether these modules can be
“synchronised” with other modules without any problems. Testing the system is about
assessing the whole system package to see if it satisfies the requirement of the users. This test
ascertain whether the sum of all units and modules result in the prescribed system. According
to Appendix D (n/d), testing can be done to the system application where verification is done
to show that all units of code work together and the total system satisfies all the functional
and operational requirements. Actually we will be trying to answer if the data can input,
process, storing and output provide the solution to the identified needs for a system.

Furthermore, according to Tutorial Point (2014) testing can be done on the internal logic of
the system where all statements include user requirement specification (URS) should be
tested; and on external functions, by conducting tests to find errors and ensuring that the
defined input will actually produce the required results. Recovery testing is another testing
which reveals how well the system is able to recover from system crashes, hardware failures
and other similar problems. At times the tester exposes the system to “stressing” conditions in
order to see if the system can withstand and recover from pressure. This was referred to as
‘forced failure’ by Appendix D (n/d). This may unearth some of the unforeseen problems.

6|Page
Finally before the users accept the system deliverables, a test-run to ascertain that their needs
have been taken care of is a prerequisite. According to Lester (2014) testing ensures that the
functional aspects expected by the user have been well addressed in the new system. It
ensures that the new system satisfies the prescribed quality standards. Initial user acceptance
testing called Alpha testing can be done by internal users where as Beta testing is the sending
of the product outside the development environment for real world exposure (Bender, 2003).
So testing can be done before commissioning the system for use and periodically to ascertain
if the system is still functioning within the accepted level of strength.

Conclusion

System development life cycle is an iterative process. The process should be continuously
assessed, updated, reviewed and tested. What is important is the delivery of the system that
caters for the needs of the users and other stakeholders. Project deliverables should be
precisely identified and logically build into an abstract system which is then translated into
physical and operation structures. We subscribe to the notion that there is more to an
information system than simply buying a computer!

7|Page
References
Appendix D. (n/d). The Systems Development Life Cycle Basics.
www.highered.mheducation.com.

Bender, R. (2003). Systems Development Lifecycle: Objectives and Requirements. New York:
Bender RBT Inc.

Cooper, R. B. (1988). Review of Management Information Systems Research; A

Management Support Emphasis. Information Processing Management Vol. 24 , 72-102.

Dennis, A., & Wixom, B. H. (2003). Systems Analysis and Design, 2nd Edition. New York:
John Wiley.

Lester, A. (2014). Project Management, Planning, and Control, 6th Ed. New York: Elsevier
Ltd.

Shaw, E. T., & Zimmerman, J. P. (1989). Detailed Requirements Analysis for a Management
Information System for the Department of Family Practice and Community Medicine at Silas
B. Hays Army Community Hospital, Fort Ord, CA. Monterey: Naval Postaaduate School.

Sira, W. A. (2011). Human Resource Informtion Systems: The Challenges of Conversion,

Research Papers. Paper 110. Southern Illinois University Carbondale.

Tutorial Point. (2014). MIS-Management Information System. New Delhi: Tutorials Point (I)
Pvt. Ltd.

Van Belle, J. P., Eccles, M. G., & Nash, J. M. (2003). Discovering Information Systems.
California: Creative Commons.

Wessels, P. L., Grobbelaar, E., & McGee, A. (2004). Information Systems in the South
African Business Environment, 2nd Ed. Durban: Lexis Nexis Butterworths.

8|Page