Full Terms & Conditions of access and use can be found at
http://www.tandfonline.com/action/journalInformation?journalCode=vjeb20
Journal of Education for Business
ISSN: 0883-2323 (Print) 1940-3356 (Online) Journal homepage: http://www.tandfonline.com/loi/vjeb20
Essential Entry-Level Skills for Systems Analysts
Sarbani Banerjee & William Lin
To cite this article: Sarbani Banerjee & William Lin (2006) Essential Entry-Level Skills for Systems Analysts, Journal of Education for Business, 81:5, 282-286, DOI: 10.3200/ JOEB.81.5.282-286
To link to this article: http://dx.doi.org/10.3200/JOEB.81.5.282-286
Published online: 07 Aug 2010.
Submit your article to this journal
Article views: 42
View related articles
ABSTRACT. In this study, the authors
provide some details about a variety of
entry-level skills that are vitally important
to systems analysts. They gathered the data
from information technology practitioners,
who related their experiences with
real-world systems development projects. Such
empirical evidence may be useful to faculty
as they decide which development practices
to emphasize in information systems
curric-ula, as they attempt to align educational
programs with industry practices, and as
they advise students.
Copyright © 2006 Heldref Publications
Essential Entry-Level Skills for
Systems Analysts
SARBANI BANERJEE WILLIAM LIN
BUFFALO STATE COLLEGE BUFFALO, NEW YORK
nformation systems (IS) educators are often faced with difficult deci-sions during curricular deliberations. Should the focus be on cutting-edge, state-of-the-art trends, regardless of their mainstream adoption in industry? Should a program provide an education and hands-on training with state-of-the-practice tools and methods that will enable graduates to step right into many local businesses? Academic programs that provide a broad IS perspective may not adequately prepare graduates for local and regional organizations, yet a tightly focused training program may constrain graduates in the larger market-place. One is often faced with legitimate justification for either of the above directions.
All types of software development projects, ranging from those developed in-house to those which are completely outsourced, include requirements such as gathering, design, development or coding, quality reviews, and testing. Educators are charged with educating and training future professionals. These new entrants into the field need to be exposed to technologies, methodolo-gies, and business practices, yet it is usually difficult to predict how and where many of these new graduates will practice their trade.
Our purpose in this study was to iden-tify important skills that entry-level sys-tems professionals, especially syssys-tems
analysts, should possess. We targeted many early activities essential to any sys-tems development project. The early stages of systems projects are very important because this is the time when much crucial information is gathered and many critical decisions are made. Our study relies heavily on data we gathered from practitioners in a particular geo-graphical area. The IS practitioners in any region must deal with various chal-lenges and pressures. They are the best source of information about tools, tech-niques, and methodologies as applied to real-world systems development pro-jects.
Significance of Study
The information presented here is important to educators, to students, and to professionals in the field, as well as to recent college graduates. According to Ehie (2002), “A large number of gradu-ates with MIS [management of informa-tion systems] degrees most likely would find jobs as systems analysts” (p. 152). Aligning educational programs with industry practices is a constant and con-tinuing theme. Industry perceptions of academic preparation are not necessarily positive. “Ask CIO’s to give the nation’s colleges and universities a report card on how they are preparing the next genera-tion of IT [informagenera-tion technology] pro-fessionals, and they’d respond with a pretty dismal grade” (sic, Hoffman,
I
2003, p. 1). As far back as 1993, Trauth, Farwell, and Lee talked about “an expectation gap between industry needs and academic preparation” (p. 293) and about the need for working together to alleviate the problem. Lippert and Anan-darajan (2004) partially blamed the divi-sion between academics and practition-ers for “numerous systems problems, including visible and invisible applica-tion backlogs, development errors, neglected or missed deadlines, and excessive project costs” (p. 91). Given that “the pipeline for skilled workers typically comes from academic institu-tions employing IS and computer sci-ence curricula” (Lippert & Anandarajan, p. 91), this is a critical and current sub-ject. All the curricular areas that com-pose the “supply pipeline” (e.g., IS; computer science [CS]; computer infor-mation systems [CIS]; MIS; IT) are still not expected to alleviate the shortage of trained professionals in the near future (Ehie; Lippert & Anandarajan).
There are many different approaches to systems analysis, and systems profes-sionals use a variety of methodologies and tools. It is imperative that systems analysis and design courses expose stu-dents to emerging practices and tech-nologies, yet one should also be cog-nizant of long-standing practices and more traditional methodologies. Our particular focus on the initial stages of systems projects underscores the view that a strong early investigation and a clear definition of requirements provide a foundation that is essential to eventual success and acceptance of systems pro-jects. “Current systems development practices are concerned with the idea that increased efforts early in the stages of development will result in a better product” (Jerva, 2001, p. 13). Most issues and questions addressed in this study are relevant whether systems are ultimately developed in-house by com-pany employees, or by contractors, pur-chased from vendors, or approached in some hybrid fashion using a mix of available development alternatives.
Systems analysis and design method-ologies have been around for decades. They are meant to be used as guides and to provide a methodical, disciplined structure to a long and complex activity. In his examination of the strengths and
weaknesses of various methods and tools, Jerva (2001) found no one partic-ular approach provided an ideal solution to all problem domains. Nevertheless, as analysts and developers strive to improve system quality, few would argue against the use of systematic methodologies and techniques. As Jerva stated, “The question of whether methodologies in general should contin-ue to be used has already been answered in the resounding popularity and prolif-eration of component aspects of design methodologies. Essentially, life-cycle methods, object-oriented methods, and prototyping methods have borrowed from one another to create new transfor-mational paradigms” (p. 19). A compre-hensive study by Jones (2003) about software development practices identi-fied a tremendous variety of approaches to virtually all phases of development, but no uniformity to the handling of generic activities. Jones stated, “After examining 12,000 projects, we can cate-gorically state that no single develop-ment method is universally deployed . . . we noted over 40 methods for gathering requirements, over 50 variations in han-dling software design, over 700 pro-gramming languages, and over 30 forms of testing” (p. 25). Jones went on to report that requirements collection was done via traditional methods of inter-viewing and surveys by some organiza-tions, whereas others used more modern methods of joint application design (JAD) or prototyping.
The above review of entry-level job skills and systems analysis practices underscores the complexity of the chal-lenge. Educators have to consider local and regional practices, along with poten-tially wider trends. Our objective was to gather and analyze some additional data from field practitioners about current and evolving practices that are important to many constituencies.
METHOD
We developed a questionnaire and administered it to high-level IT practi-tioners in a variety of industries. These professionals have managerial and supervisory responsibilities within their organizations while being intricately involved in detailed systems activities.
These practitioners were all from the western New York state geographical area. We mailed a total of 42 surveys and follow-up reminders during the sec-ond half of 2003. Respsec-ondents complet-ed the questionnaires anonymously.
The questionnaire provided the par-ticipants with a lengthy list of detailed items categorized as methods, tools, and techniques. The list consisted of a com-bined 23 items for these three cate-gories. We included many items about analysis and design commonly found in popular textbooks (Dennis, Wixon, & Tegarden, 2002; Hoffer, George, & Valacich, 2002; Kendall & Kendall, 2002; Whitten, Bentley, & Dittman, 2004). We modified this list on the basis of our experience and objectives. Ques-tions listing specified tools, methods, and techniques led to more focused responses, as opposed to using broader (but sometimes more vague) concepts, such as “structured analysis and design.” Given that it is almost impossible to pre-sent a complete set of detailed items in any survey, we accepted additional entries by respondents in virtually all areas under inquiry. Because our study centered on the early activities of sys-tems development projects, we did not include detailed questions about other tasks integral to any project (e.g., pro-gramming, training, implementation). In addition, we did include a series of questions pertaining to the demograph-ics of users, projects, and developers.
RESULTS
We received a total of 23 responses, for a response rate of 55%. The high response rate may have been partly attributable to the researchers’ familiarity with some of the participants via prior professional interactions. Although 23 is not a high number, and generalization of our results is not possible, the respon-dents are professionally accomplished, and they represent many industries and IT departments. Table 1 shows the break-down of represented industries, by job title designation and by IT department size. Thus, this report is a case study of activities and issues faced by experi-enced professionals from a wide variety of IT departments and organizations in a particular geographical area.
The largest number of respondents was from financial organizations, fol-lowed by a variety of other industries. The respondents held numerous job titles that were grouped into three categories. These categories are artificial delin-eations denoting what we deemed to be (a) departmental leadership ties, (b) project leadership responsibili-ties, and (c) systems specializations. Sample titles in the first category are Chief Technology Officer, Director of Decision Support Systems, and Execu-tive Director. Sample titles in the second category are Manager of Database Administration, Project Manager, and Senior Project Manager. Sample titles in the third category are Systems Consul-tant, Systems Architect, and Systems Specialist. Although it is impossible to deduce precise job responsibilities and functions from titles, the group as a whole was composed of professionals with a high degree of responsibility and familiarity with their companies’ prac-tices and priorities. These professionals also represented IT departments of vari-ous sizes that we categorized as (a) small if they had 15 or fewer employees (30.4%), (b) midsize if they had l6–50
employees (30.4%), (c) large if they had 50–100 employees (26.1%), and (d) very large if they had over 100 employees (13%).
A key objective of our study was to determine what skill sets were deemed to be important for entry-level technical employees, from the perspective of experienced practitioners. Our statement was that “entry-level technical employ-ees should be familiar with [a list was provided],” then we asked the respon-dents to indicate their level of agreement or disagreement with the statements.
Data in Table 2 suggest that labor-intensive methods, such as document analysis, observations, and interviews, are continuing to be viewed by develop-ers as very important skills, just as they have been from the early days of the dis-cipline. Prototyping, and to some extent JAD, both of which are more heavily reliant on hardware and software devel-opments, are also viewed as important skills to possess if one is a new entrant into the field. Table 3 shows the tech-niques respondents’ believe are impor-tant for new professionals to know. Only one item (use-case modeling) came in below 50% in the highest importance column. Table 4 lists the most common software categories with which entry-level employees are expect-ed to be familiar (e.g., word processors, spreadsheets, databases). Software tools for diagramming and project manage-ment are also rated very high as impor-tant skills for new professionals. It should be noted particularly that none of the listed items in the three tables was dismissed as unimportant for entry-level professionals. Respondents indicated a pattern of neutrality in their responses toward a number of items rather than dismissing them outright. The most extreme example here is Computer-Aided Systems Engineering or Comput-er-Aided Software Engineering (CASE) with a 75% neutralresponse.
DISCUSSION
Our major objective in this study was to identify important skills that entry-level systems professionals should pos-sess. We placed particular emphasis on
TABLE 1. Characteristics of Respondents to Systems Analyst Questionnaire
Characteristic n %
Industry represented
Financial 9 39.1
Manufacturing 2 8.7
Health care 2 8.7
Distribution 2 8.7
Sales 2 8.7
Consulting 2 8.7
Information systems (IS) or software development 2 8.7
Education 1 4.3
Utilities 1 4.3
Job title designation
Departmental leadership responsibilitiesa 8 34.8 Project leadership responsiblitiesb 10 43.5
Systems specializationsc 5 21.7
Information technology (IT) department size
< 15 7 30.4
16–50 7 30.4
51–100 6 26.1
> 100 3 13.0
aIncludes job titles such as Chief Technology Officer, Director of Decision Support Systems, and
Executive Director. bIncludes job titles such as Manager of Database Administration, Project Man-ager, and Senior Project Manager. cIncludes job titles such as Systems Consultant, Systems Archi-tect, and Systems Specialist.
TABLE 2. Methods With Which Respondents Believe Entry-Level Systems Analysts Should Be Familiar, by Level of Agreement
Level of agreement (%)
Agree or Disagree or Method strongly agree Neutral strongly disagree
Document analysis 82.6 13.0 4.3
Observation 68.2 27.3 4.3
Individual interview 60.8 26.1 13.0
Prototyping 60.8 26.1 13.0
Group interview 34.8 47.8 17.3
Joint application design 31.8 54.5 13.6 Questionnaires or survey 18.2 59.1 22.7
the business. Nevertheless, these same professionals are also aware of broader developments and new approaches in the discipline. Their answers to ques-tions about entry-level skills were gen-erally consistent. Graduates from IS and related programs should be well-round-ed and knowlwell-round-edgeable in many areas, with a clear emphasis on traditional practices and methodologies. At the same time, these new professionals should not ignore newer developments, such as object-oriented practices, the usage of which is expected to continue rising. CASE tools are very rarely used, and it is probably not worth expending resources on this once highly touted approach.
Conclusions and Implications
IS programs in business schools must continually review content areas to meet the changing needs of their constituen-cies. Skills, such as interviewing, docu-ment analysis, data-flow diagramming, flow-charting, entity-relationship cre-ation, and other proven techniques, should be taught along with newer object-oriented analysis and design methods. A longitudinal perspective evolving from a number of studies by Misic and Graf (2004) points to the ana-lytical skills that are a constant finding in every study. However, systems proj-ects do not exist in a vacuum.
Along with specific systems and technology skills, entry-level systems professionals must also understand their function as a part of the broader picture, the context of business sys-tems. There would be no systems devel-opment without involvement of top management and operational users, thus interpersonal and business skills were important in 1990 (Leitheiser, 1992) and are just as essential today. In analyzing systems managers’ percep-tions of various job skills, Richards, Yellen, Kappelman, and Guynes (1998) found “that the items with the highest ratings have a business or people skills orientation” (p. 54). Similar findings were noted by Van Slyke et al. (1998), who showed that nontechnical skills, such as teamwork and communications skills, were more important than specif-ic technspecif-ical skills. Nord and Nord’s the early activities essential to any
sys-tems development project. The early stages are very important because the information gathered and decisions made during this time have a critical impact on eventual system quality and acceptance.
The survey results provided informa-tion about activities and practices in the western New York state geographical area. Although the number of partici-pants does not permit a generalization of results, many of our findings are sup-ported by the results of other studies. A number of studies point to various reser-vations slowing the adoption of object-oriented practices (Johnson & Hard-grave, 1999; Sim & Wright, 2001). The usage of CASE tools has been dropping steadily and consistently (Glass, 1999; Misic & Graf, 2004; Tesch, Klien, & Sobol, 1995; Van Slyke, Kittner, &
Cheney, 1998). This region, like many other parts of the country, has faced many economic challenges, some of which include a loss of its manufactur-ing base, population flight, and insuffi-cient opportunities for young people. Many governmental and private organi-zations are working to diversify the economy and transform the labor force. The experienced IS professionals who participated in the study are certainly aware of the situation and understand their organizational environments. Proj-ects have to be completed. Users and customers have to be satisfied. Older legacy systems have to be supported. Traditional life-cycle approaches, regu-larly criticized as inherently slow and cumbersome, often enable faster progress toward a desirable solution when used by seasoned professionals experienced with technology and with
TABLE 3. Development Techniques With Which Respondents Believe Entry-Level Systems Analysts Should Be Familiar, by Level of Agreement
Level of agreement (%) Agree or Disagree or
strongly strongly Type of development technique agree Neutral disagree
Structured
Flow charts 95.6 0.0 4.3
Data flow diagrams 78.2 21.7 0.0
Entity relationship diagrams 69.6 30.4 0.0
Structure charts 68.2 31.8 0.0
Decision tables or trees 65.2 30.4 4.3 Structured English or pseudo-code 60.8 39.1 0.0 Object-oriented
Object-oriented modeling 52.2 34.8 13.0
Use-case modeling 38.1 47.6 14.3
TABLE 4. Software Tools With Which Respondents Believe Entry-Level Systems Analysts Should Be Familiar, by Level of Agreement
Level of agreement (%)
Agree or Disagree or Software tool strongly agree Neutral strongly disagree
Word processing 100.0 0.0 0.0
Spreadsheet 100.0 0.0 0.0
Database 91.3 8.7 0.0
Diagramming 82.6 17.4 0.0
Project management 65.2 26.1 8.7
Visual development 47.6 47.6 4.8
Group collaboration 45.5 40.9 13.6
CASE 5.0 75.0 20.0
(1995) findings noted the “overall high importance level of all management-related skills” (p. 50). A broad range of technical, business, and personal skills and qualities are clearly important for future success in the field.
Recommendations for Additional Research
A case study of educational needs based on professional activities in one geographical area is limited. Some of our findings may in fact underscore common trends and themes in other regions, but a broader sample would permit more delineated analysis and subsequent generalization. Our final suggestion for further research revolves around the theme of collaboration. Col-laborations may take many different forms. Student internships, faculty internships, industry advisory boards, the integration of actual company proj-ects into course assignments, guest pre-sentations by practitioners in classes, and research presentations by faculty members to practitioners are all exam-ples of partnerships. Another form of partnership, seemingly relatively rare, is collaboration between academic depart-ments. Systems professionals come from various disciplines. Departments, such as IS, CS, CIS, and MIS, represent
clusters of academic expertise and spe-cialization. At the same time this seg-mentation should not overlook some common, overlapping interests and cur-ricular content. A close relationship between academic departments is bound to strengthen the academic expe-rience of all involved.
NOTE
Correspondence concerning this article should be addressed to William Lin, Buffalo State Col-lege, Chase Hall 222, 1300 Elmwood Avenue, Buffalo, NY 14222.
E-mail: Linw@Buffalostate.edu
REFERENCES
Dennis, A., Wixon, B. H., & Tegarden, D. (2002).
Systems analysis and design, an object-oriented approach with UML. New York: Wiley. Ehie, I. C. (2002). Developing a management
information systems (MIS) curriculum: Per-spectives from MIS practitioners. Journal of Education for Business, 77, 151–158. Glass, R. L. (1999). A snapshot of systems
devel-opment practice. IEEE Software, 16(3),
110–112.
Hoffer, J. A., George, J. F., & Valacich, J. S.
(2002). Modern systems analysis and design.
Upper Saddle River, NJ: Pearson Education. Hoffman, T. (2003, August 25). Job skills:
Prepar-ing generation Z. Computer World. Retrieved
March 5, 2004, from http://www.computerworld. com/printthis/2003/0,4814,84295,00.html Jerva, M. (2001). Systems analysis and design
methodologies: Practicalities and use in today’s information systems development efforts. Top-ics in Health Information Management, 21(4), 13–20.
Johnson, R. A., & Hardgrave, W. C. (1999).
Object-oriented methods: Current practices and attitudes. The Journal of Systems and Software, 48(1), 5–12.
Jones, C. (2003). Variations in software develop-ment practices. IEEE Software, 20(6), 22–27. Kendall, J. E., & Kendall, K. E. (2002). Systems
analysis and design. Upper Saddle River, NJ: Pearson Education.
Leitheiser, R. L. (1992). MIS skills for the 1990s: A survey of MIS managers’ perceptions. Jour-nal of Management Information Systems, 9(1), 69–92.
Lippert, S. K., & Anandarajan, M. (2004). Acade-mic vs. practitioner systems planning and analy-sis. Communications of the ACM, 47(9), 91–92. Misic, M. M., & Graf, D. K. (2004). Systems ana-lyst activities and skills in the new millennium.
The Journal of Systems and Software, 71, 31–36. Nord, G. D., & Nord, J. H (1995). Knowledge and skill requirements important for success as a systems analyst. Journal of Information Tech-nology Management, 6(3), 47–52.
Richards, T., Yellen, R., Kappelman, L., & Guynes, S. (1998). Information systems man-agers’ perceptions of IS job skills. Journal of Computer Information Systems, 38(3), 53–57. Sim, E. R., & Wright, G. (2001). The difficulties
of learning object-oriented analysis and design:
An exploratory study. Journal of Computer
Information Systems, 42(2), 95–100.
Tesch, D. B., Klien, G., & Sobol, M. G. (1995). Information systems professionals’ attitudes:
Development tools and concepts. The Journal
of Systems and Software, 28, 39–47.
Trauth, E. M., Farwell, D. W., & Lee, D. (1993). The IS expectation gap: Industry expectation
versus academic preparation. MIS Quarterly,
17, 293–307.
Van Slyke, C., Kittner, M., & Cheney, P. (1998). Skills requirements for entry-level IS gradu-ates: A report from industry. Journal of Infor-mation Systems Education, 9(4), 7–11. Whitten, J. L., Bentley, L. D., & Dittman, K. C.
(2004). Systems analysis and design methods. New York: McGraw-Hill.
