See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/264787158

Using Structured Analysis and Design Techniques for the Development of

Course Management System

Article · January 2011

CITATIONS READS

0 3,011

1 author:

Balsam Abdul Jabbar Mustafa

Universiti Malaysia Pahang
23 PUBLICATIONS   29 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

THE IMPACT OF PROGRESS FEEDBAK ON SELF REGULATED GOALS AND PERFORMANCE OF POSTGRADUATE RESEARCH STUDENTS View project

PhD final project View project

All content following this page was uploaded by Balsam Abdul Jabbar Mustafa on 17 August 2014.

The user has requested enhancement of the downloaded file.

 Using Structured Analysis and Design Techniques for the
Development of Course Management System

Balsam A. Mustafa
Faculty of Computer Systems and Software Eng., University Malaysia Pahang, Malaysia
balsam@ump.edu.my

Abstract

Today‟s organizations can not be operated or managed effectively without softwares that are built
using different techniques and tools to achieve business goals. Systems analysis and design techniques
usually focus on studying a business situation to see how it operates and whether improvement is
needed. This paper describes how structured analysis and design techniques were used to develop a
customised software for the PISO Business Unit at the University of Sunderland (UK). The business
was suffering a lack of course management control. It shows how these techniques were applied to
identify business problems, requirements, and design a computerized system to resolve these problems
and provide the information needed for better marketing and business management control.

Keywords: structured analysis, database design, DFD, E-R model, user involvement

1. The Business Background

PISO (Process Improvement for Strategic Objectives) is a unique method for improving business
processes, developed at the University of Sunderland (UK). It provides a rapid means of designing real
change in the work place. The PISO approach is easy to learn and intended to be used by the
employees who actually carry out the functions that are being reengineered.
PISO began early in 1997 (www.piso.org.uk) as an aid for business students learning systems analysis
techniques, but proved to be a successful practical approach to business improvement. Since 2001
many organizations such as British Telecom and the South Tyneside General Hospital have become
active users of this method and the University of Sunderland began applying PISO to a major
reorganization of its systems and processes. The PISO Business Unit was established to look after the
commercial aspects of PISO development and delivery.
The PISO Business Unit at the University of Sunderland gives accredited courses at different stages,
each one qualifying the participant to gain certification from the University of Sunderland. The old
system for managing their information is based on filing information regarding these courses manually.
As a result, staffs would have difficulty in determining how many delegates have attended courses
from a particular company and at what course level. As the number of companies attended courses has
grown staffs were also spending more and more time in doing basic administrative tasks such as
printing out feedback forms and attendance certificates. There was no dedicated PISO Administrator.

This paper looks at the analysis and the design of a course management system for the PISO Business
Unit. The paper is organized as follows, Sec.1 provides a background of the Business Unit in the
University of Sunderland and the problems in the old system, Sec.2 looks at the reasons behind the
choice of the development approach, Sec. 3 looks at the analysis and design of the new system, Sec. 4
discusses specific difficulties encountered in the analysis and design of the new system, Sec. 5
discusses the lessons learned from the development, and finally the paper concludes with Sec. 6.

2. Reasons for the Choice of Structured Analysis and Design Techniques

The choice has to be taken among two different approaches for the purpose of developing the new
system. The two approaches are the structured systems analysis and design approach and the object

1
oriented analysis and design approach. It was decided to choose the structured approach because it is
very powerful and more natural than the object oriented approach. Mittra (1988) pointed out that the
strength of structured method is that it completely specifies the logical system before going into the
physical system. The user is made completely aware of the exact functional capabilities of the proposed
system before the design actually starts, keeping the analysis and design phases strictly separated. In
the object oriented approach, Rumbaugh et al (1991) insisted on the iterative nature of the analysis
process and recognized that there is no well marked line between analysis and design. They also
indicated that in systems where process is the main concern, business managers and users likely would
understand better the models produced by structured analysis rather than object oriented analysis. In
object oriented analysis objects contain their own data and responsibilities. Communication between
these objects is achieved by sending messages between them requesting something be done. The
communication between objects by sending messages can be well represented in a new computerised
system, however, it is difficult to show the same idea in an existing non-computerised system (Lejk and
Deeks, 2002) such as the one that exists in the PISO business unit. Whereas the data flow diagrams in
the structured approach show clearly who is doing what. This gives a more logical view of the problem
area in the system.
Another reason is that the PISO unit management„s requirements was to use Microsoft Access in
developing the database as this software is installed on their computers. Structured systems analysis
method map much more directly with software such as Access than with the traditional programming
languages such as COBOL (Lejk and Deeks, 2002), particularly the use of their techniques such as
normalisation in creating tables of data which are used in the new database. As the implementation
solution assumes a relational database, the use of object oriented analysis and design would create a
significant gap between the design and its implementation because eventually the development reaches
the implementation stage, which requires transformation to a relational database.

3. Starting the Analysis

3.1 Requirements Investigation

Early emphasis on the users and their tasks was necessary to establish how the present system works
and how and where data flowed through it. This emphasis on the user‟s tasks was to understand their
work as well as the functions of the present system and to ascertain what problems they had
encountered with this system. The initial investigation was first conducted through formal interviews
with the assistant manager of the PISO Unit who gave a description of the present system and how the
staffs perform their tasks. Then outlined the expectations of the new system, from which a problems
and requirements list was produced and verified with the management. A summary of these problems
and requirements is shown in Fig.1.
Several interviews were conducted with the PISO Unit staffs in order to gain a better understanding of
how the present system functioned and to identify the problems associated with it, as well as their
expectations of the new system. In order to have further view of the current system all documents used
by the users have been reviewed. This include documents used in different areas of business processes,
for example, USE form in which all information about the companies who request PISO courses for
their employees and their requirements are recorded, PROJECT form which contains information about
every project (course) , BUDGET documents and INVOICES. These documents and the information
contained are discussed with the users to gain thorough understanding of the new system requirements.
The results of the initial investigation determined the aims of the new system and established the basis
for the choice of development approach.
The outcome of the initial investigation was used in analysing the current system. The results were
used to build the data flow diagrams (DFD) and entity models. During the building of the models,
problems with the current system and requirements of the new system were specified and verified with
the users. Against these models the system analyst can test his/her understanding by first constructing
the model and second by performing a structured walkthrough of the model with the users (Satzinger et
al, 2004). In this way the user can become totally involved with the data flow diagram and give high
level commitment to the accuracy of the diagram.

2
 PISO Unit Problems and Functional Requirements

1. Access to data is restricted as information is stored in various files on one person‟s desk.
2. Staffs have difficulty in determining how many delegates have attended courses from a particular
company and at what courses levels.
3. Staffs are spending much time in doing basic administration tasks (e.g. printing out of feedback
forms and certificates).
4. Staffs need to be able to access information quickly from their own desks.
5. It is required to know all information about companies who purchase courses (name, industry,
address, contact no., contact person, purchase order ID, date of paying invoice).
6. It is required to know all information about delegates (name, gender, age, company, contact no.,
course, duration, delivery place, assessment marks, number of attempts, trainer).
7. The system (database) should provide course information (code, name, start date, completion
date, delivery place whether in the PISO unit or on company site, trainer)
8. The database should store and print the PISO Unit operating meetings.
9. The database should be able to print the required reports by the management for decision making.

Fig.1 Summary of Requirements

Fig.2 Level 1 DFD (Current System)

3
3.2 Analysis of the Current System

The analysis of the current system included functional analysis, data analysis, and problems analysis.
The aim was to provide sufficient data to construct the data flow diagrams of the current system.
Functional analysis is useful in documenting how the current system operates. The documentation
comprises information on the documents received into the system and those produced by the system,
the sources and destinations of documents, the storage of documents whether manually or
computerised and the transformation which takes place on documents (see Fig.2). The movement of
documents represents data flow; the storage of documents is represented by data stores and the
transformation of documents by processes.

3.3 The Physical DFD of the Existing System

This data flow diagram reflects the system as it exists, and it is physical in that it reflects how the
system operates (Fig.2). The current physical data flow diagram modelled functions carried out by
three sections in the Business Unit which are the PISO team who conduct and administer the courses,
Business Unit Director and the Commercial Account or finance department. It showed clearly the
sources of data, the destinations, and users of data in the system. Document flows and data stores
represent current files in the system. The diagram revealed that most of the functions are carried out by
the PISO team section which is the core of the Business Unit. During the development of this diagram,
users have been consulted on the accuracy of the data flows and functions carried out currently in the
system to verify the accuracy of the diagram.

3.4 One Process per Functional Area

It was noted from level 1 physical data flow diagram that each section has more than one process box.
Therefore, the initial data flow diagram has been refined and redrawn so that each process represents
only one functional area (Fig. 3).

Fig. 3 Level 1 DFD (One Process per Functional Area)

4
3.5 Decomposition of the Data Flow Diagram
To gain more understanding of the functions carried out by the PISO staffs in the current system, it was
to decide how much detail has to be shown of the PISO team single process in Fig. 3. Level 1 data flow
diagram was expanded into level 2 data flow diagram to cover more details by separating the PISO
team process into sub processes (Fig.4). In level 2 data flow diagram the PISO team process becomes
the DFD boundary for the second level diagram. The consistency between level 1 and level 2 data flow
diagrams has been considered, that is all the data going into and out of each level 1 process box is also
going into and out of the level 2 expansion of that process (Yourdon, 1989).

Fig. 4 Level 2 DFD (Current System)

3.6. Current System Entity Model

The entity model of the current system would be helpful in identifying and rationalising duplicate data
to be sorted out at the data flow diagram logicalisation stage. The entity model results from analysing
the data. Data analysis provides a way of structuring data, removing inconsistencies and testing the use
of data before detailed design (Fleming, 1990).
To provide a view of the data and the relationships between data inside the system, all the entities
within the boundary of the system have been studied carefully (Fig. 5) to identify the entities which

5
represent a data group of interest to the system, and the attributes that need to be held in the system for
each entity. The E-R diagram for the current system (Fig. 6) was constructed after consulting the users
on the kind of relationships between entities within the boundary of the current system.

Fig. 5 Entity Model of Current System

3.7 Logicalising the Current System

The logical view of a system is useful because it simplifies the view of a system, and this is important
in order to build an efficient computer system (Lejk and Deeks, 2002). Therefore, it is important to see
the overall picture, which means what is really going on in the current system. For this purpose, a
logical data flow diagram is constructed for the current system which represents an abstract of the
system‟s functionality and a distinct from the physical data flow diagram which shows ‟ how ‟ the
system worked with all its physical constraints such as documents and people.
The procedures that have been followed to produce the logical data flow diagram for the current system
(Fig. 7) are first, by removing all physical references on the data flows so that it indicate data rather
than documents. This will ensure that when the new system is implemented all possible new physical
forms of the documents will be considered, in other words the design of the new system should not be
influenced by the current physical implementation. Second, all places and people have been removed
from processes and functions were renamed. Third, physical data stores were changed to logical data
stores with each entity being held in only one data store. The current logical data flow diagram shows
logical data flows, logical data stores and logical functions. This diagram forms the basis of the
required system.

6
 Fig.6 E-R Model of the Current System

Fig. 7 Level 1 Logical DFD for the Current System

7
3.8 Recommended Logical Diagram

The second stage of logicalisation is meant to reflect the requirements concluded from the previous
data flow diagrams and to provide solutions to the problems in the current system. The data flow
diagrams were used to document the logic of the required system, to indicate what the new system is
required to accomplish. The aim was to develop an efficient computer system to carry out the current
business, and to solve the problems associated with it, as this is the main objective of the system
analyst. The recommended logical diagram for the new system is shown in Fig. 8.

3.9 Required Entity Model

After discussing the current E-R model with the users some modification has been made to the current
entity-relationship model to satisfy the users requirements and to solve some problems which appeared
in the current entity diagram. For example some entities have been deleted because the users did not
want the new database to keep information about them. The E-R model for the new system is shown in
Fig. 9. Using Normalisation technique also implied adding new entities to the current model. The
many - many relationship between entities such as „delegate‟ and „course‟ in Fig.6 has been replaced
by two one to many relationships with a new entity called „enrolment‟ as a link entity which will
contain an entry for each actual entity from the original combination.

Fig. 8 Recommended Logical DFD for the Current System

3.10 Normalising the data in the Delegate Form

One of the most important requirements of the users is that the new system be able to produce a special
form to handle the delegate‟s information. By analysing the data needed to construct the delegate form
which holds all the information about the delegates and their courses (see appendix A), it was found
that there is duplication of data. Therefore, the selected data structure has been normalised to produce
third normal form data structure (see Fig.10). The result of normalisation was to create new relation
called “mode” (beginners, intermediate, advanced) as shown in the new system entity model in
addition to the entities „company‟ and „delegate‟ needed to construct the form (see appendix A). So,
the form will contain all the information about delegates and the details of their courses and
assessments as required by the PISO team.

8
 Fig. 9 E-R diagram for the new system

UN 1NF 2NF 3NF

Delegate code Delegate code Delegate code Delegate code

Delegate Name Delegate Name Delegate Name Delegate Name
Company code Company code Company code Company code 
Company Name Company Name Company Name
Company Address Company Address Company Address Company code
Company Tel. Company Tel. Company Tel. Company Name
Company Fax Company Fax Company Fax Company Address
Company Tel.
Company Fax
Course code Delegate code Course code
Course Name Course code Course Name
Mode code Course Name Mode code Course code
Mode Name Mode code Mode Name Course Name
Start Date Mode Name Start Date Start Date
Completion Date Start Date Completion Date Completion Date
Delivery place Completion Date Delivery place Delivery place
Trainer Delivery place Trainer Trainer
Assessment mark1 Trainer Mode code 
No. of attempt Assessment mark1
Assessment mark2 No. of attempt Delegate code Mode code
No. of attempt Assessment mark2 Course code Mode Name
No. of attempt Assessment mark1
No. of attempt Delegate code
Assessment mark2 Course code
No. of attempt Assessment 1 mark
No. of attempt
Assessment 2 mark
No. of attempt

Fig. 10 Normalization of Delegate form Data

9
4. Specific Difficulties Encountered

The aim of the entity model was to specify the manner of participation of entities in relationships. After
the entity and relationship sets are identified, the next step was to determine the attributes or properties
of entities. Many-Many relationship creates a problem concerning the storage of some attributes. For
example the relationship between the entities delegate and course in Fig. 6 was Many-Many and it was
required to show in the delegate form the assessment marks for each course. The problem is where
these marks should be stored. The solution for that was to replace the M-M relationship by two One-
Many relationships and the creation of a third entity “enrolment” to store the missing attribute
(assessment mark).
The main task carried out by the PISO team in the Business Unit was to conduct training courses on the
PISO method. These courses are conducted on different stages with different options in each stage and
different modes. Thus, there was a large amount of data duplication. This problem was resolved using
normalisation technique to produce interrelated entities to prevent the repeating of data.
Some of the employees in the Business Unit have shown a kind of reluctance to provide information
about the way they are doing their job or the relation with other sections in the work place or
information relevant to the companies which purchase courses from the Business Unit causing more
time to define the problems and collect the requirements. For the business analyst , this reflects the
necessity to possess interpersonal skills which will be discussed in the next section.
Employees sometimes found difficulty to identify their requirements during the interviews. Building
prototypes was an effective way to test and validate user‟s requirements.

5. Lessons Learned

The data flow diagram was a useful technique in providing a wide overview of the system and to model
process input and output, data stores and flow of information in the system. Data flow diagram
technique was used effectively to identify what and where functions are carried out in the existing
system. This helped in revealing missing tasks and understanding the problems and requirements for
improvement in the existing system. It also served in providing a kind of ongoing review of the
application. At the logical level it helped in understanding and reducing the complexity of the system.
DFDs enabled the analyst to describe the existing system and the proposed new system at a logical
level without considering the physical environment in which data flaws, such as telephone calls, email,
and so on or the physical environment in which data is stored such as file cabinet or electronic files.
The transition from the current logical data flow diagram to the required logical data flow diagram was
very important as between these two versions the transformation from the old system to the new system
takes place. The appearance of the required solution to the old system problems is the most important
objective of the analysis stage.
Although the system analyst works in technical area of designing and building computer- based
information system, he/she also works with all types of people. Therefore, the analyst should be able to
communicate clearly and effectively with system users. It is important for the analyst to posses
interpersonal skills and to establish a good, open working relationship with users early in the project
and maintain it throughout by trying to understand how people think, learn, and communicate.
The initial interviews carried out with the users to gather information were very beneficial. It revealed
that asking questions is only one part of the interview. Listening to the answers has the same
importance, if not more so. Careful listening helps in understanding the problem being investigated and
many times, the answers may lead to additional questions that were more revealing than the questions
have been prepared before the interview.
Data analysis method was an effective and efficient approach to identifying the basic units of
information which are of use in the system and the inter relationships between them. After getting the
logical picture of what data to be stored as a source for information, the details of the information or
how are they structured and organised would be shown in the form of tables. The skill involved in data
analysis is that of assigning each piece of information to the most appropriate table. To check the
already constructed entity model, the normalisation technique has been applied to examine lists of
attributes to minimise duplication, avoid redundancy and to resolve ambiguity. The general rule in the

10
 relational database analysis is that each attribute should not appear more than once for each entity,
otherwise this means there is duplication of data. Because duplication is a waste of space by holding
repeated data, it also leaves the database open to the possibility of inconsistency (Satzinger et al, 2004).

6. Conclusion

This paper discussed the analysis and design of a course administration computer system. It presents an
analyst‟s experience with a real world system. It indicates how selecting an appropriate development
approach is vital in developing a software system which fulfils the needs of its users and achieves the
business goals. It discusses how the investigation of system requirements was carried out and how the
techniques used in the structured analysis and design were employed to create models of the required
system. It is found that the more clearly the model is understood by all participants, the more likely the
analyst will be able to build a correct model and specify accurate requirements. User involvement is
essential in creating models that reflect their expectations of the new system.
It also discussed the difficulties encountered during the analysis and design and the solutions provided
to overcome these difficulties. Finally it concludes with the lessons learned from this project.

References

 Fleming, C. and Von Hall, B., (1990). An Overview of Logical Data Modelling, Data Resource
Management, Vol.1, No.1, pp 5-15
 Lejk, M and Deeks, D., (2002). Systems Analysis Techniques, 2nd ed., Pearson-Education, UK
 Mittra, Sitansu S., (1988). Structured techniques of System Analysis, Design and Implementation,
John Wiley & Sons, New York
 Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., (1991). Object Oriented
Modeling and Design, Prentice Hall, Englewood Cliffs, NJ
 Satzinger, J. , Jackson, R. , Burd, S, (2004). Systems analysis and Design in a changing world,
Thomson Learning Inc
 Yourdon, E., (1989). Managing the Structured Techniques, Englewood Cliffs, NJ, Prentice-Hall

Appendix A

11

View publication stats