Exercise 2: Models and role descriptions for the fictitious organization

Organization: / The exercise is carried out in groups.
Deadline: / Tuesday 14.02.2006, 12:00
Delivery: / Electronically as one PDF file[1] per group in the MEIS system ( Mark the delivery with name and group number.
Score: / 0-5 points
Version: / English version 1 (24.01.2006)


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):


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:
  • Possible paper schemas that are used, in the degree the existing system is manually.
  • Examples of screen shots, in the degree that some parts of the system are already automated.
  • Models of work processes and work processes that is treated, both superiorprocesses and detailed processes where the four particular roles specifically co-operates.

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 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 shalldecompose all processes from the top level and at least one more level, and more where it is naturally to do so.

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 fictitiousinterview 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 F6[2]) 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 additionthe “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 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.

[1]Please see for a program that can generate PDF-documents.

[2] (especially slide 9).