Communicating requirements for business: UML or problem frames?

Authors:
Mark Vincent
Affiliations:
Independent Consultant, Stroud, Gloucestershire, United Kingdom
Venue:
Proceedings of the 3rd international workshop on Applications and advances of problem frames
Year:
2008

Citing 8
Cited 0

A field study of the software design process for large systems

Communications of the ACM
Problem frames: analyzing and structuring software development problems

Problem frames: analyzing and structuring software development problems
Pleasure and Pain: Perceptual Bias and Its Implications for Software Engineering

IEEE Software
Business Modelling for Component Systems with UML

EDOC '02 Proceedings of the 6th International Enterprise Distributed Object Computing Conference
Adapting the UML to Business Modelling's Needs - Experiences in Situational Method Engineering

UML '02 Proceedings of the 5th International Conference on The Unified Modeling Language
Unified Modeling Language Reference Manual, The (2nd Edition)

Unified Modeling Language Reference Manual, The (2nd Edition)
Requirements Engineering for e-Business Systems: Integrating Jackson Problem Diagrams with Goal Modeling and BPM

APSEC '04 Proceedings of the 11th Asia-Pacific Software Engineering Conference
Deriving requirements from process models via the problem frames approach

Information and Software Technology

Quantified Score

Hi-index	0.00

Visualization

Abstract

We compared two prominent software development notations: Problem Frames and the UML, to establish which is more effective at conveying the problem domain and software requirements. The UML scored slightly higher in both the comprehension and perceived difficulty ratings, although the results varied considerably between the different participants and problems. In general the business participants seemed to find the Problem Frames diagrams more difficult than those from an IT background; this was evident from both the scores and the feedback. We have concluded that much of the effort in creating software development methods has been focused inwardly towards the needs of the software development teams, with less consideration for the needs of the non-specialists. Ultimately, the effectiveness of any development approach will be judged by those who need to use it and the true measure of success must surely lie in how widely it is adopted.