Teaching Systems Analysis and Design:
Bringing the Real World into the Classroom

Brady Chen
xchen@fsc.edu
Department of Computer Science
Fitchburg State College
Fitchburg, Massachusetts  01420, USA
Abstract
The Systems Analysis and Design (SA&D) and Systems Design and Implementations (SD&I) are two capstone courses for students in the major of computer information systems in the department of computer science at Fitchburg State College (FSC). These two courses cover a core set of skills that students need to learn to develop systems. Along with the materials covered in the courses, there is a running project, sometimes called a case. Most likely, the running project is a simulated one and the data is made up. Students who take the courses are supposed to get training in the design and implementations of a system. The author has been teaching SA&D and SD&I for three consecutive years at the computer science department in FSC. In the first two years, the courses were taught with traditional approach, i.e., teaching the courses with simulated project. Last year, a new approach was tried. It combined the classroom teaching with a real project from the FSC IT department. In this paper, the author presents the experiences on teaching SA&D and SD&I with the real project and compares the new approach with the traditional one. Some issues related to the new approach are discussed.
Keywords: SDLC, systems analysis, SA&D, SD&I, CASE tool


1.  INTRODUCTION
Teaching the Systems Analysis and Design (SA&D) course is notably more difficult and challenging than teaching some other fields in computer science and computer information systems. Unlike many courses such as programming languages or computer hardware, many topics in SA&D are not clearly defined and sometimes difficult to practice in a classroom environment. Since the introduction of these courses, a lot of research papers have addressed the topic from different perspectives.
While many instructors believe that the traditional lecturing is thought to be the most common and yet the least effective (Griffiths, 2003 and Felder, 1992) some other research papers have focused on the traditional class lecturing with the help of tools and various technologies such as multimedia (Cybulski, 2000 and Griffiths, 1992 and 1998). Many also discussed the experiences of teaching the topics in various different class environments (Petkova, 2000 and Serva, 1998). In this paper, we present an experience on teaching SA&D and SD&I with a real project and compare the new approach with the traditional one.
The curriculum in the department of computer science at Fitchburg State College consists of a two-course specialization in systems analysis, design, and implementations. These two courses cover a comprehensive introduction into the world of systems analysis, systems development life cycles, system architectures and the use of traditional modeling methods (data flow diagrams, entity relationship diagrams, etc.). Besides the traditional approaches, the second course also introduces object oriented (OO) concepts and modeling tools and techniques.
The courses have been taught in Fitchburg State College for a long time. In our traditional approach, the first course, Systems Analysis and Design (SA&D) mainly covers the theoretic part. It was taught using traditional lecturing combined with homework, mini-case study and tests. SA&D covers the complete software development life cycle (SDLC), systems architectures, and traditional processing and data modeling methods with the help of case tools. The second course, Systems Design and Implementations (SD&I) consists of a running a simulated project or case. Typically students form groups of 3 to 5 and work on the project or case. The case is made up and designed to simulate real life situations. Students apply the knowledge from SA&D course, various analysis and design approaches, Computer-Aided Software Engineering (CASE) tools, and then reach possible solutions.
2.  TRADITIONAL APPROACH
Traditionally, the courses are taught through lecturing combined with a running project, sometimes called a case. Instructors teach the various phases such as planning, analysis, design, and implementation of information systems. Students are assigned the running project to simulate a real-world system in addition to traditional lecturing. This traditional approach has been used in the past and it has worked well. However there are some obvious disadvantages for the approach.
The simulated project or case was divided into several assignments based on the various phases in the SDLC. About every two weeks, each team presented their solution(s) to the assignment. It worked very well in many areas, particularly technical areas, like systems design and development. For example, once the use-case was determined, the processing and data modeling were well defined and students could practice them using any popular CASE tools. There were not many problems on the Data Flow Diagrams (DFDs) and Entity-Relationship Diagrams (ERDs) with simulated projects. Also students gained experiences on the following skills:
1)	Practice user interface design,
2)	Coordinate with their team member and pursue team work,
3)	Play the team leadership role.
However there are definitely some disadvantages with simulated project. Here are some of them:
1)	Since the running project is not a real one, there are still some techniques that students could not learn from it. One of such areas is project planning. With a simulated project, students don’t have the opportunity to get any real feedback during the feasibility study.
2)	Also with a simulated project, it is almost impossible to perform the interview technique which is very important in the requirements determination in project analysis phase.
3)	Due to the lack of real world and industry background for many simulated cases, an instructor may not be able to handle all the questions and issues the students may have in a particular business-related area.
4)	Most of all, any simulated project is just a class project to most of the students and they normally could not keep high morale throughout a semester. Students are mostly very enthusiastic at the project planning and analysis phases. Then things start to deteriorate and often they probably could not follow up the procedures during the design and implementation phases.
3.  LEARNING MATERIALS
There are many good teaching materials for both the SA&D and SD&I. I have used various different textbooks, each with its own advantages and disadvantages. The main learning materials for the courses were:
1)	Systems Analysis Design (Alan Dennis and Barbara Haley Wixom)
2)	Visible Analyst Student Edition by Visible Systems Corporation. Usually these materials are bound with the textbook.
3)	Microsoft Project 2002.
4.  TEACHING SA&D USING A REAL PROJECT
The new approach was motivated by the discussion with a director of IT department at Fitchburg State College. He was very supportive to the idea. We carefully discussed various different projects that the college currently needs and finally we selected a project that we believe to meet the requirements of the courses best, called the Inventory Tracking Systems. The system would be needed by the Fitchburg State College (FSC) Accounting and Materials Management Departments. Both departments need an automated system by which they can track and monitor the fixed assets in accordance with Massachusetts state law. The system would allow people to add, delete, and track the assets based on categories, departments, and locations. There would be three different levels of accounts depending on the access permission of the database. The project ran across several semesters. The students were grouped into two teams who were going to develop the project and the project staff was to consist of four staff, one from the IT department, two from the accounting department, and one from the materials management department (called “project staff” hereafter).
In order to coordinate with the project, I also made some changes in my class lecturing.
First, the students were told that they would be assigned a real project for the two courses at the beginning of the first class. They were also told that the project would be running across the semesters.
Second, since the project was running for two semesters, I spread the topics of the courses over two semesters as well. In our traditional approach, all the topics were covered in the first course; while the second course consisted of a simulated project. In the new approach, the first course covers mainly the systems planning, systems analysis, and part of the systems design in the SDLC and the second course covers the systems design, systems implementation, and other related issues. Students could apply the knowledge and skills that they learned from the lectures to the project.
Third, the project started at the beginning of the first course along with the class lecturing. About every two weeks, the students got a project assignment. Both teams worked on the same assignments and competed with each other. Then each team presented their work to the project staff and the peers.
Each project assignment was clearly defined and explained, and was to be consistent with the corresponding topics in the lecture. Depending on the topics covered in each presentation, the project staff might be invited to participate in the presentation for many of assignments and provide their feedback if necessary. For the whole academic year (two semesters) there were a total of twelve assignments. Table 3-1 in Appendices provides detailed information on each assignment. The textbook referred in the table is Systems Analysis Design by Dennis and Wixom (2003).
As standard procedures in the IT department in FSC, the Request for Proposal (RFP) is first provided by the IT department to the project staff in the class. It is a standard document that would be distributed to all potential software vendors who are interested in bidding for the project. The IT department treated the teams as any other vendors. The RFP describes the purpose of the project, proposal specifics and other information. In general, RFP is a document that is created at the systems design phase by the systems analysts and designers and is used to determine which design alternatives they are going to choose. However, in this project, it has already been created by the IT department, which means some of the planning and analysis phases have been done already.
Due to the situation, I asked my students to read and study the RFP instead of starting from the beginning and practicing the feasibility analysis based on the RFP. It was a little too late to do it and the result seemed to be obvious. However, it was still a very important part in the planning phase. I also asked the students to estimate the project size with either the Planning Phase Approach (PPA) or the Function Point Approach (FPA), create and manage a draft of work plan, and perform some risk assessment. Students were also required to start using the requirements-gathering techniques to define the requirements for the project. The RFP makes it a lot easier for the students to do it. Their main task was to determine the list of requirements they would like to include in the project and the list of requirements they could not address due to time constraints.
One of the major advantages of using the real project was that both teams could actually apply the requirements-gathering techniques, including interviews and document analysis. When students had questions or issues, they could usually get answers from the project staff. The IT department provided a Web conferencing system with various features such as live chat, mailing lists, email notification, spell checking, file attachments, and more. The Web conferencing system allows both students and project staff to communicate with each other. In particular, student used live chat and e-mails to perform many requirements-gathering techniques such as interviews.
The assignments 5, 6 and 7 are about processing modeling and data modeling. In my opinion, DFDs and ERDs are the most important skills that an analyst must have. Technically, the processing and data modeling are among the clearest and most well-defined topics in Systems Analysis courses. However, it is also a tough sell in class. The difficulty is persuading the students that these skills are necessary in systems design and development. Most students in my class never used DFDs and ERDs in their previous projects and they did not seem to believe that they actually need these skills. This is due to the fact that many projects they did before were relatively small. During their presentation, people in the project staff actually asked many questions on processes in their DFDs and data relationship in their ERDs, so they realized that the DFDs and ERDs were indeed required and were very important parts in the systems design. Eventually, I did extend two more weeks for the students to continue to modify the DFDs and ERDs.
One of the teams actually had a problem with DFDs as they used the student version of Visible CASE tool. The student version only allows people to create 9 modules. So they could not continue to use the Visible as their DFDs eventually became bigger. They finally used another tool to finish the DFDs.
5.  SUMMARY AND ISSUES
Teaching SA&D and SD&I with a real project provides students a new horizon that helps them learn the materials of the courses.
While working on a real project did help the students learn the materials, there are still some issues we need to improve or resolve. Some of them are known issues even with the traditional approaches and some are issues that arise with our new approach. The following are some issues we need to address in the future:
1)	The students’ role in the project needs to be defined. In our experience, the project staff treated students as one of the “software vendors” who were bidding for the projects, not as systems analysts. This is fine in general, however the students may not have opportunities to perform many of the processes in the systems planning phase. One such task is the feasibility analysis, where the students examine the technical, economic and organizational feasibility. When the project was assigned to the class, these parts had been done already. The first document presented to the students was the RFP which is standard document for potential vendors that bid for the project.
2)	Grading is always tough for SA&D and SD&I. Actually it is, in general, difficult to grade for courses with a group project. The first difficulty is the fairness. For a group project, there are always “good” students who contribute large amount for the project, while some others do not spend enough time and effort and let others do all the work. There is always a risk that a “bad” student may mess up the grade of an assignment for a whole team. One way to deal with the issue is to ask students to send a copy of each of their e-mail correspondences to me. The other good way to balance this is to use evaluation. For each assignment, I asked students to fill out three evaluation forms:
* Team leader evaluation form: This form is used by team members to evaluate the team leader. For each assignment, a group would select a team leader who is responsible for this particular assignment. Usually students take turns as the team leader.
* Team member evaluation form: This form is used by team leader to evaluate the team members in the group.
* Peer evaluation form: This form is used to evaluate the work of other teams. While one team was presenting an assignment, the project staff and students in the other team would act as audience and evaluate the work of that team.
3)	Selecting a project that is right for the courses turns out to be a difficult task. You have to make sure the project is tough and challenge enough so that students could apply their design and development techniques and skills. In the meantime it should be “easy” enough so students could finish it within reasonable time.
4)	Another issue is how to institutionalize this approach. As capstone courses for CIS major, you have to teach the courses in a consistent way, i.e., you have to make sure that all the related topics will be covered regardless of the project you select.
The feedback from the students was generally good. The majority agreed that the running project they were working on did greatly help them learn the topics for the two courses. During the semester, there were a couple of complaints about some students who did not actively participate in some assignments in the project work. I discussed the issues during class and told the students that this kind of thing actually happens in “the real world.” If such a thing happens in a company, the employee normally gets a bad evaluation from his/her manager. In general, each employee is evaluated based on his/her contribution to the team and the evaluation will actually be used as major criteria for a promotion, salary increase, or layoff and etc. We could not do exactly the same thing in class; however students could use three evaluation forms to evaluate each team member for his/her contribution to the project and the evaluation would impact the final grade.
6.  ACKNOWLEDGEMENTS
The author would like to thank the peers for very helpful comments and suggestion.
7.  REFERENCES
Dennis, A and B.H. Wixom (2003) Systems Analysis Design, 2nd Edition, John Wiley & Sons, Inc.
Chen, X, N. Kurtonina, S. Taylor (2004) “First Programming Languages Revisited.” College Teaching and Learning Conference, Orlando, Florida.
Griffiths, G., B.J. Oates (2003) “Lecture-free Teaching for Systems Analysis: An Action Research Study.” Proceedings of Informing Science and Information Technology Education Joint Conference, Pori, Finland.
Felder, R. (1992) “How about a quick one?” Chemical Engineering Education, 26(1), 18-19.
Cybulski, J. L. and T. Linden (2000) “Teaching Systems Analysis and Design Using Multimedia and Patterns.” Proc. 13th Conference on Software Engineering Education & Training CSEET 2000, Austin, Texas, U.S.A., 6-8 March 2000, pp 113-122. Selected for publication in IEEE Transactions on Education. Dumdum, U. Rex and William J. Tastle (1998) “Towards a Broader Competency-Based IS Education:  A proposed Improvement Package for Analysis of Case Studies.”  Proceedings of ISECON’98, October 15-18, pp. 28-33.
Petkova, O (2000) “Teaching Systems Analysis and Design to a Mixed Class of CS and BIS Majors.” Proceedings of the 15th Annual Conference of the International Academy for Information Management.
Serva, M.A (1998) “Teaching Systems Analysis and Design to Non-IS Majors: A Management Simulation.”  Decision Line, p 16-17.
Baskerville, R. L. and A. T. Wood-Harper (1996) “A critical perspective on action research as a method for information systems research.”  Journal of Information Technology, 11, 235-246.
Bonwell, C. C. and J. A. Eison (1991) “Active learning: Creating excitement in the classroom: ASHE-ERIC Higher Education Report No. 1.”  George Washington University.
Griffiths, G. (1998) The essence of structured systems analysis techniques.  London; New York: Prentice Hall.
Griffiths, G. and M. A. Lockyer (1992) “Structured methods and CASE tools.”  Video series, UK Department of Trade & Industry. IT&P (2001). Special issue on action research in information systems. Information Technology & People, 14(1).

Appendices
Table 3-1: Project Assignments and Information
Assign
ment
Assignment Given
Audience
Book Chapter
1
* Create an accurate organization chart for the IT department.
* List all the responsibilities of the IT department and all the routine jobs that IT is performing.
* List any possible challenges
Peer
NA
2
* Perform feasibility analysis including technical, economic, and organizational feasibilities. 
* Estimate the project size with either PPA or FPA.
* Create and manage a draft of workplan.
Top management
Finance committee
Technical committee
1,
2,
3
3
* Perform Risk assessment.
* Systems requirements
Technical committee, Project staff
3,
4
4
* Create use cases based on the requirements.
* Create an outline of the system proposal.
Technical committee, Project staff
5
5
* Create DFDs for the system.
Technical committee, Project staff
6
6
* Create ERDs for the system.
Technical committee, Project staff
7
7
* Revise DFDs and ERDs if necessary.
Technical committee, Project staff
6,
7
8
* Create physical DFDs.
* Create a architecture design.
Technical committee, Project staff
8,
9
9
* User Interface design:
Technical committee, Project staff
10
10
* Design and implement all the possible files.
* Design and implement the database.
* Create a prototype of the database.
Technical committee, Project staff
11
11
* Show actual code or pseudo- code.
* Develop a test plan,
Technical committee, Project staff
12,
13
12
* Continue to work on the system based on the feedback from the last presentation.
* Update the test plan and report the testing results.
* Supporting documents including procedures manual and references.
Technical committee, Project staff
14