Analysis and Design of Information Systems

Project Specification 2007-2008

Pieter De Leenheer
VUB [S.T.A.R.LAB]

19/02/2008

1 Introduction
All teams should deliver the analysis and design of an information system for
some application in the employment domain: examples are information systems
for the management of CVs, job vacancies, and course descriptions. The assign-
ments for the individual teams on this are given once the teams are formed.
This document summarises rather the requirements for the project concern-
ing deliverables, deadlines, and guidance. Please read this carefully and don’t
hesitate to pose further questions if necessary.

2 Overall Analysis Report

Your company uses many of the same methodologies and techniques that you
have learned in the course “Information Systems”. You will report back (in
written and oral form) to the client on the findings from analysis. You are
required to deliver one document, called the Overall Analysis Report. This
document gives an overview of your analysis and design. It should include (but
should not necessarily be limited to) the following items:

• System Analysis: You are working collaboratively on a very large project,

hence start by analysing the assignment and break it down into a num-
ber of smaller, more manageable and understandable components. This
permits different parts of the assignment to be analysed at independent
times and/or by different people.

• Team Planning: A Gantt chart in which you decide on the work plan
and task assignments for all members of the team. Be very precise when
eliciting this as the individual part of the marks for each member will be
based on his or her assigned tasks. The tasks naturally correspond to the
system breakdown you did before.

• System Design:
1. The business specification that describes the featured functionalities
in prose format. It is as short as possible yet accurate and com-
plete. Its focus is to provide the user who is not technical with a
document he or she can authorise. It is convenient to split up the

1
 description into subcomponents in a meaningful way (using the sys-
tem breakdown in the system analysis phase above). This guaran-
tees later that your description is complete and shows no gaps. The
most important part, however, is that you for each sub-component
use graphical representations to verify the accuracy. It is strongly
suggested that these graphical representations are conceptual process
and logic models. Optionally, you could also insert sample screens
and reports [3].
2. Apart from the functionalities, you should engineer the data model
that is implicitly present in the system. Hence, include the concep-
tual data model (in ORM) and its corresponding generated relational
database model (see [1] and [2]). The relational mapping should be
provided following the 7-step algorithm ([4]). An alternative is that
you comprehensively make use of a CASE-tool for the mapping. In
the report you then describe your experiences with the CASE tool.
3. Finally, you should provide cross-references, explaining how the en-
tities in your conceptual data model relate to the entities flowing in
and out your process models.
Formalisms for process and logic modelling, and methodologies for the opera-
tional analysis and support plan can be found in literature such as [3]. In the
first series of workshops we will be doing exercises on data flow modelling and
ORM in particular.

3 System Requirements
In normal systems analysis and design, during the analysis phase you must
collect information about the methods that are currently used at the client’s
company and how users would like to improve the current systems and organ-
isational operations. Interviewing is one of the primary ways analysts gather
information about an information systems project. Although you will find a
lot of information on the Web, We will be happy to answer further questions:
appointments can be made by sending an email to pdeleenh@vub.ac.be.
You should prepare thoroughly before the interview. Spend some time think-
ing what you need to find out and write down your questions. A good analyst
takes initiative to do some research on the topic/domain, and to use his/her
scientific inspiration in order to expand the system with interesting assets, au-
tomatisations,. . . make us happy with your ideas !

4 Time Schedule and Administrative Require-

ments
All criteria below hold for as well regular students as working students.

• Team construction: Teams of exactly 4 students each (if possible) have

to be compiled and emailed to pdeleenh@vub.ac.be before 26 February
2008. Caution, the next team call will be in July, so do not miss this hard
deadline.

2
 • Interviews with us Anytime before the presentation of the analysis. Set
up an appointment at least one week in advance with pdeleenh@vub.ac.be
first. Don’t wait too long!

• Deadline overall analysis report Monday 13 May 2008: paper ver-

sions to be dropped in the mailbox at STARLab (10G731). Part of the
final mark is given on this document based on the team planning.
• The presentation of your project to us: between 19 and 23 May
2008. During the presentation we give the collaborative part of the mark
for each member.
Deliverables are to be submitted in paper format in the mailbox at the door of
STARLab (room 10G731). Use Dutch or English as language, but not both.
Do not use any plastic binders, just staple the document and deliver it. We
ask you politely, though urgently to be ecological on this matter. Provide a title
page with at least
• the name of your team;
• names, email addresses, curriculum, and roll numbers of all members;

• institution, responsible tutors and current academic year.

Consult [5,6] for instructions on this.

5 Briefings
Further instructions may be given via the course mailing list. All questions are
to be addressed to the elvas mailing list for this course. Personal questions can
be directed to pdeleenh@vub.ac.be.

References
[1 ] Terry Halpin, Conceptual Schema and Relationale Database Design, 2nd
ed.; ISBN 0 13 355702 2, Prentice Hall, 1995.
[2 ] Terry Halpin, Information Modeling and Relational Databases, ISBN 1
55860 672 6, Academic Press, 2001.

[3 ] Jeffrey A. Hoffer, Joey F. George and Joseph S. Valacich, Modern Sys-

tems Analysis and Design, ISBN 0 8053 2499 2, The Bejamin/Cummings
Publishing Company, 1996.
[4 ] Pieter De Leenheer, RM Synthesis: applying the 7-step Algorithm, 2002.

[5 ] Helmut Kopka and Patrick W. Daly, A Guide to LATEX, 3rd ed., Addison
Wesley, 1999.
[6 ] Oetiker et al., The Not So Short Introduction to Latex2E – Or Latex2E
in 87 minutes. Print-outs available at Infogroep.