View page as slide show

Communications Software and architecture

requirements and use cases

Literature: Any good book about UML and software design


  • Every software has a goal what to do
    • protocols provide services
  • Requirements answer to question “what must be done?” to provide the protocol service
    • need or desire for a software
  • Functional requirements define desired system behaviour
    • e.g. transmit instant message
  • Nonfunctional requirements define additional attributes related to behaviour
    • e.g. message should be answered within five seconds
  • Requirements form a base for testing
    • It is easier to test that behaviour is as desired, when we know what the software should do.
    • requirement should be unambiquous


  • Requirements model
    • defines one functional requirement
    • modelled in use case diagram
  • analysis model
    • collaboration of objects
    • realisation of requirements model

Requirements modelling

  • Requirements model
  • defines one functional requirement
  • Modelled in use case diagram
  • use case != requirement
  • use cases help to understand the requirements
  • requirements can be found in specification, use cases don´t
  • Requirements can be translated to test model
    • test model is used as basis and verification
    • TTCN (tree and tabular combined notation) used for test cases and testing (testing chapter)
  • Detailed UML models can be used for automating test cases
    • Model bugs are hard to find
      • application behaviour testing required.
    • Error in model will cause erraneous testing.

Use cases

  • Illustrate and imply the requirements.
  • “Use case is a narrative document that describes the sequence of events of an actor” - Jacobson
    • narrative!
    • sequence of events.
    • example: client connects to server, fetches a file and shows it to user.
  • It is good to start development on high level use cases.
    • Do not go too much in detail on your use cases.

Use case contents

  • Use case name
  • Actors
    • participants of the use case
  • Purpose
    • what the use case is used for
  • Description
    • the sequence of events
  • overview
    • for detailed use cases it is good idea to have overview of events described in short
  • cross references can be used to point out related use cases.

Use case diagrams

  • Describes a set of use cases in a system, the actors and the relations between actors an use cases
  • Actor
    • represent functional entities (human, machine, software)
    • Actor in communication software can be in the system
      • In traditional software engineering Actors are external from system.
    • denoted with stick figure
  • Use cases
    • possible use of software under development
    • denoted with ellipse
  • relation
    • denoted with line
    • «uses», «extends», «includes»
      • special relations
    • generalisation
      • TCP client → client (actor)
      • make TCP connection → make connection (use case)
  • Constraints
    • e.g. authenticate or select free service
    • dotted arrow
  • Notes
    • Used for more detailed textual information (e.g. defining constraint).


  • How can we fulfil the requirements?
  • What parts are required for the system
    • Parts that we have to make.
    • Parts that we have to communicate with.
  • How different parts collaborate with each other to provide the desired result

analysis model

  • describe the parts of system
  • high level definitions
  • High level collaboration diagrams
    • What are the functional parts and their relations
    • What kind of communication is happening between entities

Collaboration diagram

  • Illustrates object interactions in graph format
  • Object is denoted with box
    • instance-name:class-name
  • Communication between instances is denoted with line
    • Messages can be numbered to describe sequence of events
    • arrow can show the direction of message

Collaboration diagram

Last modified: 2013/07/01 14:42