Responsibility Modelling and its Application to the Specification of Domain Knowledge

  • Andrew Blyth
Part of the IFIP Advances in Information and Communication Technology book series (IFIPAICT)


The most crucial aspect of software engineering is the gathering of requirements. The best source of requirements is domain knowledge and the best source of domain knowledge is stakeholders. Current requirements engineering techniques are failing to a) identify stakeholders, and b) identify why a stakeholder is a stakeholder. In an attempt to address this issue the responsibility modelling technique developed in this paper focuses upon the specification of domain knowledge through the identification of stakeholders and the specification of the roles they play and the actions they perform in an organisation.


Domain Knowledge Acquisition Requirements Engineering Responsibility Modelling Stakeholder Analysis 


  1. Alter, S., & Ginzberg, M. J. (1978). Managing Uncertainty in MIS Implementations. Sloan Management Review, 19, 23–31.Google Scholar
  2. Bailey, J., & Person, S. (1983). A Tool for Computer User Satisfaction. Management Science, 29(5), 530–545.CrossRefGoogle Scholar
  3. Beck, K., & Cunningham, W. (1989). A Laboratory for Teaching Object Oriented Thinking. In Object-Oriented Programming Systems Languages and Applications (OOPSLA), (pp. 1–6). ACM Press.CrossRefGoogle Scholar
  4. Beslmuller, E. (1988) Office Modelling Based on Petri Nets. ESPRIT 1988 Part 1. North-Holland. 977–987.Google Scholar
  5. Blyth, A. (1995a). Modelling the Business Process to Derive Organisational Requirements for Information Technology. ACM SIGOIS Bulletin, 16(1), 25–33.CrossRefGoogle Scholar
  6. Blyth, A. (1995b). Responsibility Modelling and Its Application to the Management of Change. Focus on Change Management — Cases in Business Process Reengineering, 17.Google Scholar
  7. Blyth, A., & Chudge, J. (1995). Modelling and Eliciting Organisational and Information System Requirements. In International Medical Informatics Association 8th World Congress on Medical Informatics (MEDINFO). Vancouver, British Columbia, Canada.Google Scholar
  8. Blyth, A., Chudge, J., Dobson, J., & Strens, R. (1993). ORDIT: A New Methodology to Assist in the Process of Eliciting and Modelling Organisational Requirements. In S. Kaplan (Ed.), Organisational Computing Systems (COOCS),. Milpitas, California, USA: ACM Press.Google Scholar
  9. Checkland, P. (1986). Systems Thinking, Systems Practice. Wiley.Google Scholar
  10. Checkland, P. and Scholes, J. (1990). Soft Systems Methodology in Action. Wiley.Google Scholar
  11. Commons, H. O. (1995). Health Committee Second Report London Ambulance Service. Her Majesties Stationary Office (HMSO).Google Scholar
  12. Dahlbom, B. and Mathiassen, L. (1994). Computers in Context: The Philosophy and Practice of Systems Design. NCC Blackwell.Google Scholar
  13. Dardenne. A., van Lamsweerde, A. and Fickas, S. (1993) Goal-directed Requirements Acquisition. Science of Computer Programming. 20(1–2) 3–50.zbMATHCrossRefGoogle Scholar
  14. Ehn, P. (1989). Work-Oriented Design of Computer Artifacts. Arbetslivscentrum.Google Scholar
  15. Executive, N. M. (1993a). Integrated Clinical Workstation: User Requirements (Acute Hospital) — Part A, Report No. F6018/ICWS/135. NHS Centre for Coding and Classification.Google Scholar
  16. Executive, N. M. (1993b). Integrated Clinical Workstation: User Requirements (Acute Hospital) — Part B, Report No. F6018/ICWS/136. NHS Centre for Coding and Classification.Google Scholar
  17. Flowers, S. (1995). The London Ambulance Service Computerised Despatch System. In Mega Mistakes — Lessons From Information System Failures J. Wiley.Google Scholar
  18. Franz, C. R., & Robey, D. (1984). An Investigation of User-Led System Design: Rational and Political Perspectives. Communications of the ACM, 27(12), 1202–1209.CrossRefGoogle Scholar
  19. Gause, D. C., & Weinberg, G. M. (1989). Exploring Requirements: Quality Before Design. New York: Dorset House Publishing.zbMATHGoogle Scholar
  20. Kling, R., & Iacono, S. (1984). The Control of Information Systems Development After Implementation. Communications of the ACM, 27(12), 1218–1226.CrossRefGoogle Scholar
  21. Lucas, H. C. (1975). Why Information Systems Fail. New York: Columbia University Press.Google Scholar
  22. Lyytinen, K., & Hirscheim, R. A. (1987). Information System Failures:A Survey and Classification of Empirical Literature. Oxford Surveys in Information Technology, 4, 257–309.Google Scholar
  23. Markus, M. L. (1983). Power, Politics and MIS Implementation. Communications of the ACM, 26 (6), 430–444.CrossRefGoogle Scholar
  24. Mason, R. O., & Mitroff, I. T. (1981). Challenging Strategic Planning Assumptions. New York: John Wiley and Sons.Google Scholar
  25. Mellor, P. (1994), CAD: Computer Aided Disaster. High Integrity Systems, 1(2), 101–156MathSciNetGoogle Scholar
  26. Page, D. (1993). Report of the Inquiry into the London Ambulance Service., Communications Directorate South West Thames Regional Health Authority.Google Scholar
  27. Rein, G. L. and Singh, C. (1992) Interaction Nets (RINs): A Process Description Formalism. Technical Report Number CT-083–92. Micro-Electronics and Computer Technology Corporation (MCC).Google Scholar
  28. Searle, J. R. (1969). Speech Acts — An Essay in the Philosophy of Language. Cambridge University Press.CrossRefGoogle Scholar
  29. Searle, J. R., & Vanderveken, D. (1985). Foundations of Illocutionary Logic. Cambridge University Press.zbMATHGoogle Scholar
  30. Stamper, R. (1985). Management Epistemology: Garbage In, Garbage Out. (And What About Deontology and Axiology?). In Knowledge Representation for Decision Support Systems (pp. 55–77). Elsevier Science.Google Scholar
  31. Strens, R., & Dobson, J. E. (1994). Responsibility Modelling as a Technique for Requirements Definition. Intelligent Systems Engineering, 3(1), 20–26.CrossRefGoogle Scholar
  32. Sutcliffe, A. G. and Maiden N. A. M. (1993) Bridging the Gap: Policies, Goals and Domains. Proceedings of the Seventh International Workshop on Software Specification and Design. IEEE Computer Press.Google Scholar
  33. Tuzhilin, A. (1995). Templar: A Knowledge-Based Language for Software Specification Using Temporal Logic. ACM Transactions on Information Systems, 13(3), 269–304.MathSciNetCrossRefGoogle Scholar
  34. Wells, W. (1995). Report on the London Ambulance Service,. South Thames Regional Health Authority.Google Scholar
  35. Wiener, L. R. (1993). Digital Woes: Why We Should Not Depend on Software. Addison-Wesley.Google Scholar
  36. Wise, J. A., & Debons, A. (Ed.). (1987). Information Systems: Failure Analysis, Springer-Verlag.zbMATHCrossRefGoogle Scholar
  37. Yu, E. S. K. and Mylopoulos, J. (1994) Using Goals, Rules and Methods to Support Reasoning in Business Process Re-Engineering. Proceedings of the Twenty Seventh Hawaii International Conference on System Sciences.Google Scholar

Copyright information

© IFIP International Federation for Information Processing 1996

Authors and Affiliations

  • Andrew Blyth
    • 1
  1. 1.Department of Computer StudiesUniversity of GlamorganPontypridd, Mid GlamorganUK

Personalised recommendations