Startup16 Assignment1

Requirement specification


Apply requirements modeling according to the IREB standard to the 101system. To this end, apply the types of diagrams, as suggested by the IREB handbook, to the 101system so that the existing requirements or reasonable suggestions are modeled.


  1. Context diagrams for context view: the available requirement specification patently ignores the context. No neighboring systems or actors are mentioned in the specification so far. On the grounds of what you learn about the system from the available requirement specification, come up with some reasonable options for neighboring systems and actors and suggest the interface between system and neighboring systems and actors in terms of data flow. (assigned to teams 1, 9)
  2. Class diagrams for information structure view: the available requirement specification definitely involves requirements that can and should be modeled with class diagrams. Go ahead and model those. Make a careful decision as to whether a relationship is "simple", whether it is instead a part-of relationship, or whether generalization is at play. Assign multiplicities carefully. Constrain classes, attributes, and relationships by textual comments. The available requirements specification may not suggest constraints directly and thus, you need to suggest reasonable constraints. (assigned to teams 2, 12)
  3. Use case diagrams for use case view (dynamic view): Arguably, some of the requirements from the available specification may correspond to use cases. For instance, summing up or cutting salaries may be functions that are close to use cases. However, not even these requirements are in the form of use cases. Enhance these requirements so that use cases are more clearly visible. This entails suggestion of actors for the use cases. Make use of the template for textual specification of use cases to provide details. Again, the details are not readily available from the requirement specification, but you need to suggest reasonable details. (assigned to teams 3, 9)
  4. Data flow diagrams for data flow oriented view (dynamic view): the available requirement specification does not really describe requirements at a level of detail comparable to a data flow diagram. Arguably, there is some mentioning of performance reviews and how conflicts of interest should be taken into consideration to avoid that an employee is consulted for the performance review if they are engaged in a conflict of interest. Thus, suggest a data flow diagram that models some form of performance review. The actors are presumably the employee under review, the manager performing the review, and another party that may provide input. There would be a data store identifying completed work items by the employee under review. Some data would flow; the performance review should eventually identify some salary raise. You may also pick another reasonable data flow which makes sense for the system at hand. (assigned to teams 4, 10)
  5. Activity diagrams for control flow oriented view (dynamic view): See the assignment on data flow diagrams just above. Suggest an activity diagram instead. This means that you need to identify the order of actions, decision nodes, and options, if any, for fork and join. (assigned to team 5)
  6. State machine diagrams for state oriented view (dynamic view): the available requirement specification does not really describe requirements of any kind that are to be addressed by state-oriented modeling. Suggest two state machines to model reasonable state-oriented aspects of the systems. Here are some ideas for inspiration: a) An employee may go through states in terms of being a new employee, an established employee, a senior employee, a retired employee, a fired employee, and a former employee. b) A department may go through states in terms of being a top-level department (i.e., an immediate department of the company) and a sub-department (i.e., a department below a top-level department). c) An employee may go through states in terms of transitions for entering company premises, working on work items, taking a break, leaving for an off-campus client meeting, and leaving for home. (assigned to teams 6, 11)
  7. Sequence diagrams for scenario view (dynamic view): the available requirement specification does not really describe requirements at a level of detail comparable to a sequence diagram. Arguably, the available requirement for restructuring part-of relationships hints at a dynamic view in terms of a user requesting restructuring and the involved department objects from where and where to to move some employee object. Suggest a sequence diagram for such restructuring. Suggest another reasonable behavior for the system such that the behavior can modeled in a relevant manner by a sequence diagram. (assigned to team 7)
  8. Communication diagrams for scenario view (dynamic view): See the assignment on sequence diagrams just above. Use communication diagrams instead of sequence diagrams. (assigned to team 8)


  • Develop the diagram(s) as described by the details.
  • Develop a short presentation.
    • 1 title page: members of team, course, headline for assignment
    • 1 page on the used modeling notation
    • 1+ page per diagram or requirement with elements as follows
      • What does the available requirement specification for the 101system contribute?
      • What is the textual requirement specification that you assume?
      • What is the suggested diagram for the textual requirement at hand?
  • Share the PDF of your presentation with the lecturer by the deadline; see details on sharing on the main page.


  • Handbook of Requirements Modeling IREB Standard: (.pdf) (Link to
  • A requirement specification for the 101system: (.pdf) (Shared privately with course participants)

Free UML editors

You may prefer to use PowerPoint or some other drawing App.

The only requirement is that you deliver your diagram per PDF.