Requirements &
Use Case Diagrams
DUM 04
SW requirements
• Requirement can be briefly defined as a „specification of what should be
implemented“.
• Functional reqs define what behavior or what services will the system
provide
• Non-functional reqs define attributes or restrictive conditions of given
system (quality, technology, documentation, project management, etc.)
• Requirement defines „WHAT“, not „HOW“
Non-functional requirements
• Performance
• Capacity
• Availability
• Standards compliance
• Security
• Documentation
• Project organization
• Technology
• …
Non-functional requirements
Non-functional requirements are to be recorded and continually implemented during the
project delivery. A catalogue record with following attributes can be used for this purpose:
• Identification number
• Last change date
• Name of author and recipient
• Requirements prioirity
• Brief description
• Detailed description
• Connection to other reqs
• Requirement complexity/complicacy
Functional reqs can be recorded in a „similar“ manner
Requirements record
Example of requirements record
Functional requirements – use cases
• Use Case Diagram provides an outside view on the modelled system and
therefore helps to define the borders of the system.
• It is a sequence of related transactions between user (usually a user in certain
role but also a different system) and the system itself during a mutual dialogue.
• Main purpose is to record actors communicating with system and relations
between services and their recipients through a visual and textual form that is
comprehensive for both developers and customers (i.e. people who are going
to use the system)
Use Case
Diagram
Components and relationships
Use case (depicted as oval) – sequence of actions connected with an
actor, can contain relationships
• Include – use case may contain other (Including – e.g. Edit text → Write text,
Create table, etc.)
• Extend – use case may extend other (e.g. Open document → Import from
other format, etc.)
• Generalisation (inheritance) – use case can be a special case of other use case
Actor/Participant (depicted as figure) – description of external objects
participating in the process, may contain relationships
Generalisation (inheritance) – actor may be a special case of other actor
Components and relationships
Components and relationships
Components and relationships
Components and relationships