Extending UML Use Case Diagrams to Represent Non-Interactive Functional Requirements

Saqib Iqbal, Issam Al-Azzoni, Gary Allen, Hikmat Ullah Khan

Research output: Contribution to journalArticlepeer-review

6 Citations (Scopus)


Background: The comprehensive representation of functional requirements is a crucial activity in the analysis phase of the software development life cycle. Representation of a complete set of functional requirements helps in tracing business goals effectively throughout the development life cycle. Use case modelling is one of the most widely-used methods to represent and document functional requirements of the system. Practitioners exploit use case modelling to represent interactive functional requirements of the system while overlooking some of the non-interactive functional requirements. The non-interactive functional requirements are the ones which are performed by the system without an initiation by the user, for instance, notifying something to the user or creating an internal backup.
Aim: This paper addresses the representation of non-interactive requirements along with interactive ones (use cases) in one model. This paper calls such requirements ‘operation cases’ and proposes a new set of graphical and textual notations to represent them.
Method: The proposed notations have been applied on a case study and have also been empirically evaluated to demonstrate the effectiveness of the new notations in capturing non-interactive functional requirements.
Results and Conclusion: The results of the evaluation indicate that the representation of operation cases helps in documenting a complete set of functional requirements, which ultimately results in a comprehensive translation of requirements into design.
Original languageEnglish
Pages (from-to)97-115
Number of pages19
JournalE-Informatica Software Engineering Journal
Issue number1
Early online date24 Jun 2020
Publication statusPublished - 24 Jun 2020


Dive into the research topics of 'Extending UML Use Case Diagrams to Represent Non-Interactive Functional Requirements'. Together they form a unique fingerprint.

Cite this