Exercise 2: Models and role descriptions for the fictitious
organization
Organization:
Deadline:
Delivery:
Score:
Version:
The exercise is carried out in groups.
Tuesday 14.02.2006, 12:00
Electronically as one PDF file1 per group in the MEIS system
(http://www.meis.idi.ntnu.no). Mark the delivery with name and group number.
0-5 points
English version 1 (24.01.2006)
Introduction
This exercise is a continuation (extension) of exercise 1. You should here continue your preparations
for the customer role you will play in the interview- and requirement workshop exercise. Use the
comments you have been given by the course staff to prepare the description of your fictitious
organization. This description, except the role descriptions, should then be delivered to the group
you should work together with for the rest of the semester (the teaching assistants will let you know
which group this is).
In addition the following additions should be done (do not deliver this to the other group):
Exercise
The description of your organization should be extended with the following items:
(PS: Read carefully the guidelines further down in the text.)
 An extended and more specific description of the existing information system, work processes
that is included in this and what kind of information that is treated. This description can contain
different various elements:
o Possible paper schemas that are used, in the degree the existing system is manually.
o Examples of screen shots, in the degree that some parts of the system are already
automated.
o Models of work processes and work processes that is treated, both superior
processes and detailed processes where the four particular roles specifically cooperates.
Guidelines for the creation of the models
You shall create models of all the three types of DFD models, UML activity diagrams and ER
diagrams.
All diagram models shall be given a thoroughly textual explanation. This must be done to show that
you understand what your models expresses and to explain why you have chosen to model the way
you have.
DFD
DFD should be used to model the processing of the system as a totality, and must contain the
following types of diagrams:
a) Context diagram
b) Top level diagram
c) Lower level decomposed diagrams, where you shall decompose all processes from the
top level and at least one more level, and more where it is naturally to do so.
1
Please see http://sourceforge.net/projects/pdfcreator/ for a program that can generate PDFdocuments.
A usual recommendation in connection with DFD diagrams is that they should contain between 5-7
processes. To avoid creation of to many DFD diagrams you are recommended to not have more than
7 processes in your top level diagram.
UML activity diagram
UML activity diagrams are typically used to show single work processes. They should be created for
tasks that involve the fictitious interview objects (business processes where they perform all or some
of the activities), but do not need to be used beyond this. UML activity diagrams do not need to be
decomposed.
ER diagrams
ER is used to model the structure of the information that is treated, the connection between different
concepts, etc. But an important issue here is that it should not be a design model for a database, i.e. it
is no point in thinking 3rd normal form, or effective data storage when you create the model, just show
what kind of information the organization handles.
See also lecture notes (especially from F62) for tip on the differences on what to model with ER, DFD
and UML activity diagram.
Guidelines for delivery of information to the interviewer-group
As an interviewer (consultant) there will not be natural to come totally unprepared to do an interview –
as a consultant you normally know who to talk to and why.
What should be given to the group that will interview you is an updated version of exercise 1, except
the role descriptions you have created. It’s important that the models you create in this exercise not
is given to the group that will do requirement collection from you – in case they would get unnatural
start help in finding requirements (usually the customer don’t come with process- and information
models). The detailed descriptions, including models, are on the other hand important as basic
knowledge – to make sure you have some sensible to say about “your job” and your/the organizations
needs. Bad preparations here will often result in “getting empty” in the middle of the interview, or just
sitting there creating requirements randomly and incoherently – this will also destroy some of the
training for the interviewer and for the requirement workshop. Since the problems are “fictitious” you
necessarily need to think through the details thoroughly in advance (while you with a real, self
experienced problem could have spoken of experience without preparations). In addition you will get
valuable training in modelling through this exercise.
In addition the “customer” can bring examples of paper schemas and/or existing screen shots to the
interview or the requirement workshop, when this is typically things that you would have shown the
requirement collector in a real dialogue on the workplace.
Tip on working method
If everyone in the group constantly sits together and work in front of the computer screen
working, it can be relatively ineffective, then 20 nominally work hours gets reduced to 5
effective work hours per week with regards to how long time you have to come up with a
result.
Therefore: Work in groups where this is naturally (brainstorming, finding a superior plan of
what the organization should do, make context diagram and top level DFD), but after that also
individual (with regards to decomposition of DFD to lower level you can easily work
independently of each other by concentrating on different processes, the same applies to the
detailed role descriptions that each group member is responsible for. UML activity diagrams
2
http://www.idi.ntnu.no/emner/tdt4175/pdfs/forelesninger/F6-dfd2.pdf, (especially slide 9).
for business processes (at least as long as not one or more of the other roles also enters into
this). It can also be possible to take on different parts of an ER-diagram and then put this
together (for example one person can look into information about customers, another on
information about employees, another on information on products, etc.). But make sure that
your models become consistent and that the paper becomes uniform.