Academia.eduAcademia.edu

Outline

Title
Abstract
Figures
Introduction
Discussion
References
All Topics
Computer Science
Information Systems

The domain theory for requirements engineering

Profile image of Neil MaidenNeil MaidenProfile image of Alistair SutcliffeAlistair Sutcliffe

1998, … Engineering, IEEE Transactions on

https://doi.org/10.1109/32.667878
visibility

…

description

23 pages

link

1 file

Abstract

Retrieval, validation, and explanation tools are described for cooperative assistance during requirements engineering and are illustrated by a library system case study. Generic models of applications are reused as templates for modeling and critiquing requirements for new applications. The validation tools depend on a matching process which takes facts describing a new application and retrieves the appropriate generic model from the system library. The algorithms of the matcher, which implement a computational theory of analogical structure matching, are described. A theory of domain knowledge is proposed to define the semantics and composition of generic domain models in the context of requirements engineering. A modeling language and a library of models arranged in families of classes are described. The models represent the basic transaction processing or 'use case' for a class of applications. Critical difference rules are given to distinguish between families and hierarchical levels. Related work and future directions of the domain theory are discussed.

Figures (12)
Fig. 1. Hierarchical structure of object system models with the knowledge types used for matching.
Fig. 1. Hierarchical structure of object system models with the knowledge types used for matching.
Fig. 2. Fact capture screen in early part of the dialogue, illustrating the dialogue controller and fact entry.
Fig. 2. Fact capture screen in early part of the dialogue, illustrating the dialogue controller and fact entry.
Fig. 3. Illustration of the first cycle matcher dialogue showing windows for (a) explaining the retrieved generic model anc (b) the problem notepad.
Fig. 3. Illustration of the first cycle matcher dialogue showing windows for (a) explaining the retrieved generic model anc (b) the problem notepad.
Fig. 4. Explanation dialogue (a, b) for the retrieved “object supply” model after further fact entry with details of the system rationale for selecting the object supply model (c, d).
Fig. 4. Explanation dialogue (a, b) for the retrieved “object supply” model after further fact entry with details of the system rationale for selecting the object supply model (c, d).
Fig. 5. Critiquer dialogue with active guidance for explaining inconsistent facts (a, b), with further explanation later in the dialogue of an information system model (c).
Fig. 5. Critiquer dialogue with active guidance for explaining inconsistent facts (a, b), with further explanation later in the dialogue of an information system model (c).
Fig. 6. Matching between input facts and the OC system model.
Fig. 6. Matching between input facts and the OC system model.
Fig. 7. Possible structure mappings between the structure <container- many-resource> and three Structure objects in the input model. The best-fit is with <library-many-book>.
Fig. 7. Possible structure mappings between the structure <container- many-resource> and three Structure objects in the input model. The best-fit is with <library-many-book>.
Fig. 8. Architecture of the AIR toolset. The architecture of AIR (Advisor for Intelligent Reuse) has six major components; illustrated in Fig. 8.
Fig. 8. Architecture of the AIR toolset. The architecture of AIR (Advisor for Intelligent Reuse) has six major components; illustrated in Fig. 8.
Fig. 9. Metaschema of knowledge types for domain modeling.
Fig. 9. Metaschema of knowledge types for domain modeling.
Fig. 10. Key components of Object System Models. The power of state transitions to discriminate between models is best illustrated by an example in Fig. 10. In the first OSM, stock is dispatched from the warehouse to the customer while books are lent from the library to the bor- rower in the second OSM. Both systems have structures representing objects held in and leaving a container but the library is distinguished by an additional state transition returning the outgoing object to the container.
Fig. 10. Key components of Object System Models. The power of state transitions to discriminate between models is best illustrated by an example in Fig. 10. In the first OSM, stock is dispatched from the warehouse to the customer while books are lent from the library to the bor- rower in the second OSM. Both systems have structures representing objects held in and leaving a container but the library is distinguished by an additional state transition returning the outgoing object to the container.
Fig. 12. Object system model hierarchy showing subclasses of the Object Containment Model.
Fig. 12. Object system model hierarchy showing subclasses of the Object Containment Model.

Related papers

The use of object-oriented models in requirements engineering: a field study
Linda Dawson

1999

In many organizations, there has been a move toward the use of object-oriented methods for the development of information systems. Little is understood, or reported on the basis of research, of the use of object-oriented methods by practicing professionals in the production of requirements specifications for commercial or industrial sized projects. In this paper, we outline a conceptual framework of "what might be happening" in professional object-oriented requirements engineering based on the common characteristics of published, well known object-oriented methods. We then describe a research project and the findings from a set of six case studies that have been undertaken that examine professional practice from the standpoint of the epistemology contained in the conceptual model. In these studies, it was found that the more formal models of objectorientation were rarely used to validate, or even clarify, the specification with clients or users. Rather, analysts tended to use informal models, such as use cases or ad hoc diagrams, to communicate the specification to users. Formal models are more often used internally within the analysis team and for communicating the specification to the design team.

View PDFchevron_right
Requirements Classification and Reuse: Crossing Domain Boundaries
Jacob L Cybulski

Software Reuse: Advances in Software Reusability, 2000

A serious problem in the classification of software project artefacts for reuse is the natural partitioning of classification terms into many separate domains of discourse. This problem is particularly pronounced when dealing with requirements artefacts that need to be matched with design components in the refinement process. In such a case, requirements can be described with terms drawn from a problem domain (e.g. games), whereas designs with the use of terms characteristic for the solution domain (e.g. implementation). The two domains have not only distinct terminology, but also different semantics and use of their artefacts. This paper describes a method of cross-domain classification of requirements texts with a view to facilitate their reuse and their refinement into reusable design components.

View PDFchevron_right
Workshop Proceedings Editors De@caise'2010 Chairs Caise'10 Workshop Chairs Profile-based Development: Profile for Domain Specific Patterns: Application to Real-time Organization De@caise'10 Organizers Additional Reviewers Table of Contents Domain Dependent Semantic Requirement Engineering a Uml Prof
nadia bouassida

2010

Preface Domain Engineering, also referred to as product line engineering, deals with developing reusable assets that can be adjusted and adapted to families of applications, rather than to particular systems. A domain in this context can be defined as an area of knowledge that uses common concepts for describing phenomena, requirements, problems, capabilities, and solutions. The purpose of domain engineering is to identify, model, construct, catalog, and disseminate artifacts that represent the commonalities and differences within a domain, as well as to provide mechanisms, techniques, and tools to reuse these artifacts in the development of particular applications and systems. Although being applicable to different engineering disciplines, domain engineering methods and domain specific languages (DSL) receive nowadays special attention from the information systems and software engineering communities who deal with artifact reuse, application validation, and domain knowledge represe...

View PDFchevron_right
A Metamodeling Approach for Requirements Specification
Elena Navarro

Journal of Computer Information Systems, 2006

There are many Requirements Engineering approaches and techniques that help to specify, analyze and validate requirements in the context of practically any kind of project. However, they are neither widely accepted nor widely used by industrial software community. One of the main problems faced when applying a requirement technique is to what extent it can be easily adapted to the specific needs of the project. This has often led to unsatisfactory requirements management in industrial software development. Currently, Use Case model is the most widely accepted despite its restricted expressiveness and overloaded semantics. Other more sophisticated modeling techniques have been developed independently of any others and/or for specific application domains. Frequently, techniques that provide richer expressiveness do not include scalability from other more popular techniques nor do they offer integration with other more advanced techniques. In this work, we present an approach for requirements modeling that allows the integration of the expressiveness of some of the more relevant techniques in the Requirements Engineering arena. Our work takes advantage of metamodeling as a medium for integrating and customizing Requirements Engineering techniques. By focusing on the scalability with respect to expressiveness and adaptability to the application domain, we have established some basic guidelines and extension mechanisms that lend coherence and semantic precision to our approach. A case study is presented to describe the application of our approach in a real-life project and the tool support we are using.

View PDFchevron_right
Domain Engineering
Arne Sølvberg

2013

These lecture notes are primarily about domain modelling and only secondarily how to transform domain models into domain and interface requirements. The following facets of domain modelling will be covered: business processes, intrinsics, support technologies, management and organisation, rules and regulations, scripts, and human behaviour. The lectures will exemplify excerpts of models of container shipping, financial services, etcetera. We shall relate two (of three) parts of requirements models to domain models: the domain requirements-which are the requirements that can be expressed solely in terms of the terms of the domain models, and the interface requirements-which are those requirements that can only be expressed using terms both of the domain and the machine: the hardware and software being required. For domain requirements we briefly sketch the domain-to-requirements "algebra" of projection, instantiation, determination, extension and fitting. For interface requirements we briefly sketch the domain & machine issues of shared entities (bulk data input and refreshments), shared functions, shared events, and shared behaviours.

View PDFchevron_right
Application of Conceptual Structures in Requirements Modeling
Michael Bogatyrev

2011

Requirements modeling has been applied in CASE technologies to formalize knowledge needed for constructing models of information systems. The problem is to acquire knowledge from requirements texts and represent it as intermediate requirements model for entity-relationships or object oriented modeling. Proposed approach is based on formalization of entities and their attributes as formal contexts. It is shown that formal contexts created on the set of conceptual graphs extracted from requirements text may serve as data source for requirements models have been applied in real CASE technologies.

View PDFchevron_right
Goal and scenario based domain requirements analysis environment
Sooyong Park

Journal of Systems and Software, 2006

Identifying and representing domain requirements among products in a product family are crucial activities for a successful software reuse. The domain requirements should be not only identified based on the business goal, which drives marketing plan, product plan, and differences among products, but also represented as familiar notations in order to support developing a particular product in the product family. Thus, our proposal is to identify the domain requirements through goals and scenarios, and represent them as variable use cases for a product family. Especially, for identification of the domain requirements, we propose four abstraction levels of requirements in a product family, and goal and scenario modeling. For representation of them, variable use case model is suggested, and also the use case transfer rules are proposed so as to bridge the gap between the identification and representation activity. The paper illustrates the application of the approach within a supporting tool using the HIS (Home Integration System) example.

View PDFchevron_right
Domain knowledge reuse during requirements engineering
Kevin Conheeney

Lecture Notes in Computer Science, 1995

The accurate capture, understanding and representation of requirements is a critical step in the construction of effective and usable information systems. Tiffs activity is highly cognitive and is people and knowledge intensive; its success or failure is significantly influenced by the skills and especially the previous experience of the development staff involved. Many of the processes of requirements engineering are not well defined and remain difficult and problematic, significantly the initial investigation, elicitation and checking of requirements are poorly supported by current development tools and development methods. This paper describes research within the field of requirements engineering which draws upon AI/KBS research to adopt a knowledge based approach for requirements eaptttre, modelling and validation and encourage the reuse of knowledge about typical information system applications and domains during such activities. * Relations -as simple brackets containing a relation label. * Arcs -shown as a dash and direction arrow.

View PDFchevron_right
A metamodeling approach for reasoning on multiple requirements models
Ivan Kurtev

2013 17th IEEE International Enterprise Distributed Object Computing Conference, 2013

The complex software development projects of today may require developers to use multiple requirements engineering approaches. Different teams may have to use different requirements modeling formalisms to express requirements related to their assigned parts of a given project. This situation poses difficulties in achieving interoperability and integration of requirements models for the purpose of reasoning on the overall system requirements. It is challenging to compose distributed models expressed in different notations and to reason on the composed models. In this paper we present a metamodeling approach which allows reasoning about requirements and their relations on the whole/composed models expressed in different requirements modeling approaches. In a previous work we expressed the structure of requirements documents as a requirements metamodel in which the most important elements are requirements relations and their types. The semantics of these elements is given in First Order Logic (FOL) and allows two activities: inferring new relations from the initial set of relations and checking consistency of relations. In this work we use the requirements metamodel as a core metamodel to be specialized for different requirements modeling approaches and notations such as Product-line and SysML. Mainly, the requirements relations in the metamodel are specialized to support relations in different requirements modeling approaches. The specialization allows using the same semantics and reasoning mechanism of the core metamodel for multiple requirements modeling approaches. To illustrate the approach we use an example from automotive domain expressed with two modeling approaches: product-line requirements models and SysML for system requirements.

View PDFchevron_right
Domain Specific Languages for Software Requirements Capture
Laura Mendoza

Software Engineering Research and Practice, 2010

The task of requirements capture is a crucial step in the development software process. The accuracy of requirements identication is useful in order to ensure the success of a software development project. Regularly, requirements are materialized in particular documents expressed either as documents in natural language or technical diagramas like class diagrams or use cases. All of them are non executable documents. In this paper we propose the use of domain specic languages (DSL's) as a medium for requirements identication. Domain specic languages design implicitly involves the denition of concepts and their relations of the domain. For this, we introduce examples from dierent programming paradigms that model specic domain concepts. Finally, we suggest particular DSL's like an integration mechanism between Software Factories and Model Driven Architecture for the requirements model.

View PDFchevron_right

References (72)

  1. A. Aamodt et al., "The Common KADS Library," Vrieje Univer- siteit, Brussels, Deliverable KADS-II Project, KADS-II/T1.3/ VUB/TR/005, 1992.
  2. J. Allen, "A Common Sense Theory of Time," Proc. Int'l Joint Conf. Artificial Intelligence, 1985.
  3. J.R. Anderson, The Adaptive Character of Thought. Hillsdale, N.J.: Lawrence Erlbaum Assoc., 1990.
  4. G. Arango, E. Schoen, and R. Pettengill, "Design as Evolution and Reuse," Proc. Second Int'l Workshop Software Reusability (Advances in Software Reuse), pp. 9-18, 1993.
  5. B. Chandrasekaran, A. Keuneke, and M. Tanner, "Explanation in Knowledge Systems: The Roles of the Task Structures and Do- main Functional Models," Proc. Workshop Task Based Explanation, Univ. of the Aegean, Samos, Greece, 1992.
  6. P.W. Cheng and K.J. Holyoak, "Pragmatic Reasoning Schemas," Cognitive Psychology, vol. 17, pp. 391-416, 1985.
  7. M.T.H. Chi, R. Glaser, and E. Rees, "Expertise in Problem Solv- ing," Advances in the Psychology of Human Intelligence, R. Sternberg, ed., pp. 7-75, 1982.
  8. M.T.H. Chi, M. Bassock, M.W. Lewis, P. Reimann, and R. Glaser, "Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems," Cognitive Science, vol. 13, pp. 145- 182, 1989.
  9. L. Chung, "Representing and Using Non-Functional Require- ments: A Process-Oriented Approach," Research in Data and Knowledge Base Systems, DKBS-TR-93-1, Dept. of Computer Sci- ence, Univ. of Toronto, 1993.
  10. P. Coad and E.E. Yourdon, Object-Oriented Analysis. New York: Yourdon Press, 1990.
  11. P. Constantopoulos, M. Jarke, J. Mylopoulos, and Y. Vassilou, "Software Information Base: A Server for Reuse," Technical Re- port, FORTH Research Inst., Univ. of Heraklion, Crete, 1991.
  12. A. Dardenne, A. v. Lamsweerde, and S. Fickas, "Goal Directed Requirements Acquisition," Science of Computer Programming, vol. 20, pp. 3-50, 1993.
  13. S. Easterbrook, "Handling Conflict Between Domain Descriptions with Computer-Supported Negotiation," Knowledge Acquisition, vol. 3, pp. 255-289, 1991.
  14. B. Falkenhainer, K.D. Forbus, and D. Gentner, "The Structure- Mapping Engine: Algorithm and Examples," Artificial Intelligence, no. 41, pp. 1-63, 1989.
  15. C.J. Fillmore, "The Case for Case Reopened," Syntax and Semantics VIII, P. Cole and J.M. Sadock, eds. New York: Academic Press, 1977.
  16. C.J. Filmore, P. Kay, and M.C. O'Connor, "Regularity and Idio- maticity in Grammmatic Constructions: The Case of Let Alone Language," vol. 64, pp. 501-538.
  17. G. Fischer, A. Girensohn, K. Nakakoji, and D. Redmiles, "Sup- porting Software Designers with Integrated Domain-Oriented Design Environments," IEEE Trans. Software Eng., vol. 18, no. 6, pp. 511-522, 1992.
  18. G. Fischer, K. Nakakoji, J. Otswald, G. Stahl, and T. Sumner, "Em- bedding Computer-Based Critics in the Contexts of Design," Proc. INTERCHI'93, S. Ashlund, K. Mullet, A. Henderson, E. Hollnagel, and T. White, eds., pp. 157-163, 1993.
  19. D. Gentner, "Structure-Mapping: A Theoretical Framework for Analogy," Cognitive Science, vol. 5, pp. 121-152, 1983.
  20. T.R.G. Green and R. Navarro, "Programming Plans, Imagery and Visual Programming," Proc. Human Computer Interaction-IN- TERACT'95, K. Nordby, P.H. Helersen, D. Gilmore, S.A. Arnesen, eds., London: Chapman and Hall, 1995.
  21. R. Greiner, "Learning by Understanding Analogies," Artificial Intelligence, vol. 5, pp. 81-125, 1988.
  22. T.R. Gruber, "Towards Principles for the Design of Ontologies Used for Knowledge Sharing," Knowledge Systems Laboratory Report, KSL 93-04, Dept. of Computer Science, Stanford Univ., 1993.
  23. T.R. Gruber, "A Translation Approach to Portable Ontology Speci- fications," Knowledge Acquisition, vol. 5, pp. 199-220, 1993.
  24. R. Guindon, "Designing the Design Process: Exploiting Oppor- tunistic Thoughts," Human-Computer Interaction, no. 5, pp. 305- 344, 1990.
  25. J.A. Hampton, "Disjunction in Natural Categories," Memory and Cognition, vol. 16, pp. 579-591, 1988.
  26. M.T. Harandi and M.Y. Lee, "Acquiring Software Design Sche- mas: A Machine Learning Perspective," Proc. Sixth Conf. Knowl- edge Based Software Engineering, Syracuse, N.Y., vol. 1, pp. 239-250, Sept. 1991.
  27. K.J. Holyoak and P. Thagard, "Analogical Mapping by Constraint Satisfaction," Cognitive Science, vol. 13, pp. 295-355, 1989.
  28. M.J. Jackson, Systems Development. Prentice Hall, 1983.
  29. L. Jacobson, Object-Oriented Software Engineering: A User Case- Driven Approach. ACM Press, 1992.
  30. M. Jarke, J. Mylopoulos, J. Schmidt, and Y. Vassilou, "DIADA- An Environment for Evolving Information Systems," ACM Trans. on Information Systems, vol. 10, pp. 1-50, 1992.
  31. M. Jarke, "ConceptBase V3.1 User Manual," Aachen, Germany, RWTH-Aachen, 1992.
  32. M. Jarke, Y. Bubenko, C. Rolland, A.G. Sutcliffe, and Y. Vassilou, "Theories Underlying Requirements Engineering: An Overview of NATURE at Genesis," Proc. IEEE Symp. Requirements Engineer- ing, pp. 19-31, 1993.
  33. M. Jarke et al., "Requirements Engineering: An Integrated View of Representation," Proc. Fourth European Software Engineering Conf., Garmish-Partenkirchen, Sept. 1993.
  34. P. Johnson, H. Johnson, R. Waddington, and R. Shouls, "Task- Related Knowledge Structures: Analysis, Modeling and Applica- tion," D.M. Jones and R. Winder, eds., HCI'88, pp. 35-61. Cam- bridge: Cambridge Univ. Press, 1988.
  35. G. Lakoff, Women, Fire and Dangerous Things: What Categories Re- veal about the Mind. Chicago: Univ. of Chicago Press, 1987.
  36. J.C.S.P. Leite and P.A. Freeman, "Requirements Validation Through Viewpoint Resolution," IEEE Trans. Software Eng., vol. 17, no. 12, pp. 1,253-1,269, 1991.
  37. P. Loucopoulos, G. Papamastatiou, D. Pantazis, and G. Diakono- laou, "Design and Execution of Event/Action DB Applications," Proc. Second Int'l Workshop Deductive Approach to Information Sys- tems and Databases, Aiguablava, Spain, 1991.
  38. N.A.M. Maiden and A.G. Sutcliffe, "Analogical Matching for Specification Retrieval," Proc. Sixth Knowledge-Based Software En- gineering Conf., pp. 108-116, 1991.
  39. N.A.M. Maiden and A.G. Sutcliffe, "Exploiting Reusable Specifi- cations Through Analogy," Comm. ACM, vol. 35, no. 4, pp. 55-64, 1992.
  40. N.A.M. Maiden and A.G. Sutcliffe, "Analogical Retrieval in Re- use-Oriented Requirements Engineering," Software Engineering J., vol. 11, no. 5, pp. 281-292, 1996.
  41. N.A.M. Maiden and A.G. Sutcliffe, "Requirements Engineering by Example: An Empirical Study," Proc. IEEE Symp. Requirements Engineering RE-93, E. Finkelstein A.C. IEEE CS Press, 1993.
  42. N.A.M. Maiden, P. Mistry, and A.G. Sutcliffe, "How People Cate- gorise Requirements for Reuse: A Natural Approach," Proc. Sec- ond Int'l Symp. Requirements Engineering RE'95, P. Zave and M.D. Harrison, eds., pp. 148-157. IEEE CS Press, 1995.
  43. S.M. McMenami and J.F. Palmer, Essential Systems Analysis. Your- don Press, 1984.
  44. B. Meyer, "On Formalism in Specifications," IEEE Software, pp. 6- 26, Jan. 1985.
  45. J. Mylopoulos, A. Borgida, M. Jarke, and M. Koubarakis, "Telos: Representing Knowledge about Information Systems," ACM Trans. Office Information Systems, vol. 8, no. 4, 1990.
  46. J. Mylopoulos, L. Chung, and B. Nixon, "Representing and Using Nonfunctional Requirements: A Process-Oriented Approach," IEEE Trans. Software Eng., vol. 18, no. 6, pp. 483-497, 1992.
  47. J.M. Neighbors, "Software Construction Using Components," PhD thesis, Dept. of Information and Computer Science, Univ. of California, Irvine, 1980.
  48. N. Pennington, "Stimulus Structures and Mental Representation in Expert Comprehension of Computer Programs," Cognitive Psy- chology, vol. 19, pp. 295-341, 1987.
  49. R. Prieto-Diaz and P. Freeman, "Classifying Software for Reus- ability," IEEE Software, pp. 6-16, Jan. 1987.
  50. R. Prieto-Diaz, "Domain Analysis: An Introduction," ACM SIG- SOFT Software Engineering Notes, vol. 15, no. 2, pp. 47-54, 1990.
  51. R. Prieto-Diaz, "Implementing Faceted Classification for Software Reuse," Comm. ACM, vol. 34, no. 5, pp. 88-97, 1991.
  52. P.P. Puncello, "ASPIS: A Knowledge-Based CASE Environment," IEEE Software, pp. 58-65, Mar. 1988.
  53. M.R. Quillian, Semantic Memory. Cambridge, Mass.: Bolt, Beranak and Newman, 1966.
  54. B. Ramesh and V. Dhar, "Supporting Systems Development by Capturing Deliberations During Requirements Engineering," IEEE Trans. Software Eng., vol. 18, no. 6, pp. 498-510, 1992.
  55. H.B. Reubenstein and R.C. Waters, "The Requirements Appren- tice: An Initial Scenario," Proc. Fifth Int'l Workshop Software Specifi- cation and Design, Pittsburgh, pp. 211-218, May 1989.
  56. C.K. Riesbeck and R.C. Schank, Inside Case-Based Reasoning. Hillsdale, N.J.: Lawrence Erlbaum Assoc., 1989.
  57. G. Roman, "A Taxonomy of Current Issues in Requirements Engi- neering," Computer, pp. 14-22, Apr. 1985.
  58. E. Rosch, C.B. Mervis, W.D. Grey, D.M. Johnson, and P. Boyes- Braem, Basic Objects in Natural Categories. Academic Press, 1976.
  59. E. Rosch, "Prototype Classification and Logical Classification: The Two Systems," New Trends in Conceptual Representation: Challenges to Piaget's Theory? E.K. Scholnick, ed., 1985.
  60. D.E. Rumelhart, "Notes on a Schema for Stories," Representation and Understanding, D.G. Bobrow and A.M. Collins, eds., 1976.
  61. R.C. Schank, Dynamic Memory: A Theory of Reminding and Learning in Computers and People. Cambridge Univ. Press, 1982.
  62. M. Shaw, "Heterogeneous Design Idioms for Software Architec- ture," Proc. Sixth Int'l Workshop Software Specification and Design, pp. 158-165, 1991.
  63. D.R. Smith, "KIDS: A Semi-Automated Program Development System," IEEE Trans. Software Eng., vol. 16, no. 9, pp. 1,024-1,043, 1990.
  64. D.R. Smith, "Track Assignment in an Air Traffic Control System: A Rational Reconstruction of System Design," Proc. KBSE'92, Knowledge Based Software Engineering, pp. 60-68, 1992.
  65. J.F. Sowa, Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley, 1984.
  66. A.G. Sutcliffe and N.A.M. Maiden, "Software Reusability: Deliv- ering Productivity Gains or Short Cuts," Proc. INTERACT'90, D. Diaper, D. Gilmore, G. Cockton, and B. Shackel, eds., pp. 895-901, 1990.
  67. A.G. Sutcliffe and N.A.M. Maiden, "Supporting Component Matching for Software Reuse," Proc. Fourth Conf. Advanced Infor- mation Software Engineering CAiSE'92, M.P. Loucopoulos, ed., pp. 290-303, 1992.
  68. A.G. Sutcliffe and N.A.M. Maiden, "Bridging the Requirements Gap: Policies, Goals and Domains," Proc. Seventh Int'l Workshop System Specification and Design, pp. 52-55, 1993.
  69. C.N. Taylor, A.G. Sutcliffe, N.A.M. Maiden, and D. Till, "Formal Representations for Domain Knowledge," Technical Report, 95/5, Centre for HCI Design, School of Informatics, City Univ., London, 1995.
  70. B.J. Wielinga, A.T. Schreiber, and J.A. Breuker, "KADS: A Model- ing Approach to Knowledge Engineering," Technical Report ES- PRIT Project P5248 KADS-II, 1991.
  71. R. Wirfs-Brook, B. Wilkerson, and L. Wiener, Designing Object- Oriented Software. Prentice Hall, 1990.
  72. E.S.K. Yu, "Modeling Organizations for Information Systems Requirements Engineering," Proc. IEEE Symp. Requirements Engi- neering RE-93, San Diego, Calif., A.C.W. Finkelstein, ed., pp. 34-41, 1993.

Related papers

From Domains to Requirements On a Triptych of Software Development
Dines Bjorner

In [9, Barry Boehm 81] two qualities of software were characterised (30+ years ago): "the right software" and "software that is right". The former is software that offers its users exactly and only what they expect from that software. In this paper we shall take "the right software" to be software whose data and functions accurately reflect the are of their work (i.e., the application domain, or just domain). "Software that is right" is software which correctly implements its requirements (in the context of assumptions about the domain). Seminal works [20, 21, M.A. Jackson], [17, David Lorge Parnas] and [28, Axel van Lamsweerde] have stressed the importance of careful domain analysis in conjunction with similarly careful requirements analysis and prescription. In this paper we shall "isolate" domain description (incl. analysis) into a separate phase, which we shall call domain engineering 1 , ideally preceding requirements engineering.. In the above cited works, where we especially acknowledge the influence, in our work, from [20, M.A. Jackson 1995], domain analysis appears to be tightly interwoven with requirements analysis. In this paper we shall separate the two and "pretend" that software can be developed in three "ideally" consecutive phases: domain description development 2 and requirements prescription development 3. We shall not cover a third phase of software development: software design. We shall structure domain modelling into the composed modelling on domain facets such as (a) intrinsics, (b) support technologies, (c) rules and regulations, (d) scripts (licenses and contracts), (e) management and organisation and (f) human behaviour. We shall show that signaificant parts of requirements prescriptions can be systematically "derived" from a domain descruption, in particular the two parts of requirements that we shall call domain requirements and interface requirements. We shall structure domain requirements modelling into the staged modelling of such domain requirements facets as (g) projection, (h) instantiation, (i) determination, (j) extension and (k) fitting, as well as the staged modelling of such interface requirements facets as (l) shared simple entities, (m) shared actions, (n) shared events and (o) shared behaviours. We suggest, but can only point to empirical observations, that the systematic adherence to the items (a)-(o) contributes * This is an evolving draft of an invited, to be refereed paper for a special JTCS issue in honour of NNN's KKKth Anniversary. I expect the draft to be completed by August 10, 2010. Currently I have started a complete rewite of the text. All examples will be renewed. As of July 15, 2010 my rewite ends at the beginning of Sect. 1.4. 1 But domain engineering does not entail the construction, as in ordinary engineering, of a domain. It entails the construction of a domain description 2 colloquially: domain engineering 3 colloquially: requirements engineering From Domains to Requirements: towards achieving "the right software", while pursuing all phases using formal techniques (notably specification, verification) contributes towards achieving "that the software is right".

View PDFchevron_right
Utilizing domain models for application design and validation
Arnon Sturm

Information & Software Technology, 2009

Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system developers to design valid applications in the domain. One major way of carrying out the domain analysis is modeling. Several studies suggest using metamodeling techniques, featureoriented approaches, or architectural-based methods for modeling domains and specifying applications in those domains. However, these methods mainly focus on representing the domain knowledge, providing insufficient guidelines (if any) for creating application models that satisfy the domain rules and constraints. In particular, validation of the application models which include application-specific knowledge is insufficiently dealt. In order to fill these lacks, we propose a general approach, called Application-based DOmain Modeling (ADOM), which enables specifying domains and applications similarly, (re)using domain knowledge in application models, and validating the application models against the relevant domain models. In this paper we present the ADOM approach, demonstrating its application to UML 2.0 class and sequence diagrams.

View PDFchevron_right
Requirements Engineering: An Integrated View of Representation, Process, and Domain
Yannis Vassiliou

1993

Reuse, system integration, and interoperability create a growing need for capturing, representing, and using application-level information about software-intensive systems and their evolution. In ESPRIT Basic Research Project NATURE, we are developing an integrative approach to requirements management based on a three-dimensional framework which addresses formalism as well as cognitive and social aspects. This leads to a new requirements process model which integrates human freedoms through allowing relatively free decisions in given situations. Classes of situations and decisions are defined with respect to the three-dimensional framework through the integration of informal and formal representations, theories of domain modeling, and the explicit consideration of nonfunctional requirements in teamwork. Technical support is provided by a conceptual modeling environment with knowledge acquisition through interactive as well as reverse modeling, and with similarity-based querying.

View PDFchevron_right
A metamodeling approach for reasoning about requirements
Klaas van den Berg

Model Driven Architecture– …, 2008

In requirements engineering, there are several approaches for requirements modeling such as goal-oriented, aspect-driven, and system requirements modeling. In practice, companies often customize a given approach to their specific needs. Thus, we seek a solution that allows customization in a systematic way. In this paper, we propose a metamodel for requirements models (called core metamodel) and an approach for customizing this metamodel in order to support various requirements modeling approaches. The core metamodel represents the common concepts extracted from some prevalent approaches. We define the semantics of the concepts and the relations in the core metamodel. Based on this formalization, we can perform reasoning on requirements that may detect implicit relations and inconsistencies. Our approach for customization keeps the semantics of the core concepts intact and thus allows reuse of tools and reasoning over the customized metamodel. We illustrate the customization of our core metamodel with SysML concepts. As a case study, we apply the reasoning on requirements of an industrial mobile service application based on this customized core requirements metamodel.

View PDFchevron_right
Ontology and model alignment as a means for requirements validation
Mark Rouncefield

2010

View PDFchevron_right

Related topics

  • Information Systems
  • Computability Theory
  • Domain Theory
  • Requirement Engineering
  • Transaction Processing

    • Cited by

    Requirements Elicitation: A Survey of Techniques, Approaches, and Tools
    Didar Zowghi

    Engineering and Managing Software Requirements, 2005

    Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems. It is generally understood that requirements are elicited rather than just captured or collected. This implies there are discovery, emergence, and development elements to the elicitation process. Requirements elicitation is a complex process involving many activities with a variety of available techniques, approaches, and tools for performing them. The relative strengths and weaknesses of these determine when each is appropriate depending on the context and situation. The objectives of this chapter are to present a comprehensive survey of important aspects of the techniques, approaches, and tools for requirements elicitation, and examine the current issues, trends, and challenges faced by researchers and practitioners in this field.

    View PDFchevron_right
    On the effective use and reuse of HCI knowledge
    Alistair Sutcliffe

    ACM Transactions on Computer-Human Interaction, 2000

    The article argues that new approaches for delivering HCI knowledge from theory to designers will be necessary in the new millennium. First the role of theory in HCI design to date is reviewed, including the progress made in cognitive theories of interaction and their impact on the design pr ocess. The role of bridging models that build on models of interaction is described, but it is argued that direct application of cognitive theory to design is limited by scalability problems. The alternative of representing HCI knowledge as claims and the role of the task-artefact approach to theory-based design are introduced. Claims are proposed as a possible bridging representation that may enable theories to frame appropriate recommendations for designers and, vice versa, enable designers to ask appropriate questions for theoretical research. However, claims provide design advice grounded in specific scenarios and examples, which limits their generality. The prospects for reuse becoming an i...

    View PDFchevron_right
    Modular norm models: practical representation and analysis of contractual rights and obligations
    Robin Gandhi

    Requirements Engineering

    Compliance analysis requires legal counsel but is generally unavailable in many software projects. Analysis of legal text using logic-based models can help developers understand requirements for the development and use of software-intensive systems throughout its lifecycle. We outline a practical modeling process for norms in legally binding agreements that include contractual rights and obligations. A computational norm model analyzes available rights and required duties based on the satisfiability of situations, a state of affairs, in a given scenario. Our method enables modular norm model extraction, representation, and reasoning. For norm extraction, using the theory of frame semantics, we construct two foundational norm templates for linguistic guidance. These templates correspond to Hohfeld's concepts of claim-right and its jural correlative, duty. Each template instantiation results in a norm model, encapsulated in a modular unit which we call a super-situation that corresponds to an atomic fragment of law. For hierarchical modularity, super-situations contain a primary norm that participates in relationships with other norm models. Norm compliance values are logically derived from its related situations and propagated to the norm's containing super-situation, which in turn participates in other super-situations. This modularity allows on-demand incremental modeling and reasoning using simpler model primitives than previous approaches. While we demonstrate the usefulness of our norm models through empirical studies with contractual statements in open source software and privacy domains, its grounding in theories of law and linguistics allows wide applicability.

    View PDFchevron_right
    Empirical Findings on BDD Story Parsing to Support Consistency Assurance between Requirements and Artifacts
    Brian Fitzgerald

    Evaluation and Assessment in Software Engineering

    Behaviour-Driven Development (BDD) stories have gained considerable attention in recent years as an effective way to specify and test user requirements in agile software development projects. External testing frameworks also allow developers to automate the execution of BDD stories and check whether a fully functional software system behaves as expected. However, other software artifacts may quite often lose synchronization with the stories, and many inconsistencies can arise with respect to requirements representation. This paper reports on preliminary empirical findings regarding the performance of two existing approaches in the literature intended to support consistency assurance between BDD stories and software artifacts. The first approach involves the parsing of BDD stories in order to identify conceptual elements to automatically generate consistent class diagrams, while the second approach seeks to identify interaction elements to automatically assess the consistency of task models and GUI prototypes. We report on the precision of these approaches when applied to a study with BDD stories previously written by Product Owners (POs). Based on the results, we also identify a set of challenges and opportunities for BDD stories in the consistency assurance of such artifacts. CCS CONCEPTS • Software and its engineering → Software verification and validation.

    View PDFchevron_right
    580 California St., Suite 400
    San Francisco, CA, 94104
    © 2025 Academia. All rights reserved