Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667821
H. Kaindl, Stefan Kramer, Robert Kacsich
Potential users of a proposed system sometimes tend not to formulate functional requirements on that system. Rather they define requirements on the compound system that includes the proposed software/hardware as well as other objects and even people such as the users themselves. Since such requirements do not make explicit what exactly the proposed system is supposed to do, they are insufficient for developing it. We present a case study that shows how functional requirements can be successfully decomposed using scenarios. According to our approach, for each of the functional requirements on the compound system, a corresponding scenario is developed. The scenario descriptions include steps to be performed by the proposed system. For each of these steps one or more functions are developed that will enable that system to perform these steps. These functions correspond to functional requirements on the proposed system. As a consequence of our case study, we propose to use this approach for decomposing functional requirements whenever they are requirements on the compound system rather than the system that is to be built.
{"title":"A case study of decomposing functional requirements using scenarios","authors":"H. Kaindl, Stefan Kramer, Robert Kacsich","doi":"10.1109/ICRE.1998.667821","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667821","url":null,"abstract":"Potential users of a proposed system sometimes tend not to formulate functional requirements on that system. Rather they define requirements on the compound system that includes the proposed software/hardware as well as other objects and even people such as the users themselves. Since such requirements do not make explicit what exactly the proposed system is supposed to do, they are insufficient for developing it. We present a case study that shows how functional requirements can be successfully decomposed using scenarios. According to our approach, for each of the functional requirements on the compound system, a corresponding scenario is developed. The scenario descriptions include steps to be performed by the proposed system. For each of these steps one or more functions are developed that will enable that system to perform these steps. These functions correspond to functional requirements on the proposed system. As a consequence of our case study, we propose to use this approach for decomposing functional requirements whenever they are requirements on the compound system rather than the system that is to be built.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"29 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114224714","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667817
S. Greenspan
{"title":"Delivering Requirements Engineering Introduction to the Mini-Tutorial","authors":"S. Greenspan","doi":"10.1109/ICRE.1998.667817","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667817","url":null,"abstract":"","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124876141","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667820
N. Maiden, S. Minocha, K. Manning, Michele Ryan
CREWS-SAVRE is a prototype software tool for systematic scenario generation and use. This paper reports on two interleaved strands of research and development of CREWS-SAVRE. The first is theoretical research into classes of exceptions in software-intensive systems. The second is the development of a software prototype which has been used to acquire requirements from current scenario users. This paper reports these user requirements and design implications for the current version of the prototype. The paper ends with a discussion of the advantages of integrating basic software engineering research with user-centred system design.
{"title":"CREWS-SAVRE: systematic scenario generation and use","authors":"N. Maiden, S. Minocha, K. Manning, Michele Ryan","doi":"10.1109/ICRE.1998.667820","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667820","url":null,"abstract":"CREWS-SAVRE is a prototype software tool for systematic scenario generation and use. This paper reports on two interleaved strands of research and development of CREWS-SAVRE. The first is theoretical research into classes of exceptions in software-intensive systems. The second is the development of a software prototype which has been used to acquire requirements from current scenario users. This paper reports these user requirements and design implications for the current version of the prototype. The paper ends with a discussion of the advantages of integrating basic software engineering research with user-centred system design.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133731287","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667808
A. Russo, B. Nuseibeh, J. Kramer
The paper describes our experiences in restructuring multi perspective requirements specifications in order to identify and analyse inconsistencies and manage change. A partial, heterogeneous and reasonably large requirements specification from a NASA project was analysed and decomposed into a structure of "viewpoints", where each viewpoint encapsulates partial requirements of some system components described in the specification. Relationships between viewpoints were identified which included not only the interactions explicitly stated in the requirements but also some implicit and potentially problematic inter dependencies. The restructuring process and a first informal analysis of the resulting relationships enabled the detection of inconsistencies and the definition of some interesting domain dependent consistency rules. We believe that this restructuring into view points also facilitated requirements understanding through partitioning, and requirements maintenance and evolution through explicit identification of the inter viewpoint relationships.
{"title":"Restructuring requirements specifications for managing inconsistency and change: a case study","authors":"A. Russo, B. Nuseibeh, J. Kramer","doi":"10.1109/ICRE.1998.667808","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667808","url":null,"abstract":"The paper describes our experiences in restructuring multi perspective requirements specifications in order to identify and analyse inconsistencies and manage change. A partial, heterogeneous and reasonably large requirements specification from a NASA project was analysed and decomposed into a structure of \"viewpoints\", where each viewpoint encapsulates partial requirements of some system components described in the specification. Relationships between viewpoints were identified which included not only the interactions explicitly stated in the requirements but also some implicit and potentially problematic inter dependencies. The restructuring process and a first informal analysis of the resulting relationships enabled the detection of inconsistencies and the definition of some interesting domain dependent consistency rules. We believe that this restructuring into view points also facilitated requirements understanding through partitioning, and requirements maintenance and evolution through explicit identification of the inter viewpoint relationships.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131865125","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667823
Xavier Franch
This paper presents NoFun, a notation aimed at dealing with non-functional aspects of software systems at the product level in the component programming framework. NoFun can be used to define hierarchies of non-functional attributes, which can be bound to individual software components, libraries of components or (sets of) software systems. Non-functional attributes can be defined in several ways, being possible to choose a particular definition in a concrete context. Also, NoFun allows to state the values of the attributes in component implementations, and to formulate non-functional requirements over component implementations. The notation is complemented with an algorithm able to select the best implementation of components (with respect to their non-functional characteristics) in their context of use.
{"title":"Systematic formulation of non-functional characteristics of software","authors":"Xavier Franch","doi":"10.1109/ICRE.1998.667823","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667823","url":null,"abstract":"This paper presents NoFun, a notation aimed at dealing with non-functional aspects of software systems at the product level in the component programming framework. NoFun can be used to define hierarchies of non-functional attributes, which can be bound to individual software components, libraries of components or (sets of) software systems. Non-functional attributes can be defined in several ways, being possible to choose a particular definition in a concrete context. Also, NoFun allows to state the values of the attributes in component implementations, and to formulate non-functional requirements over component implementations. The notation is complemented with an algorithm able to select the best implementation of components (with respect to their non-functional characteristics) in their context of use.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"24 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121714958","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667822
A. Sutcliffe, Michele Ryan
A method of scenario based requirements engineering is described that uses a combination of early prototypes, scenario scripts and design rationale to elicit and validate user requirements. Experience in using the method on an EU project, Multimedia Broker, is reported. Quantitative data on requirements sessions is analysed to assess user participation and quality of requirements captured. The method worked well but there were problems in the use of design rationale and control of turn taking in RE sessions. Lessons learned in using the method are summarised and future improvements for the method are discussed.
{"title":"Experience with SCRAM, a SCenario Requirements Analysis Method","authors":"A. Sutcliffe, Michele Ryan","doi":"10.1109/ICRE.1998.667822","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667822","url":null,"abstract":"A method of scenario based requirements engineering is described that uses a combination of early prototypes, scenario scripts and design rationale to elicit and validate user requirements. Experience in using the method on an EU project, Multimedia Broker, is reported. Quantitative data on requirements sessions is analysed to assess user participation and quality of requirements captured. The method worked well but there were problems in the use of design rationale and control of turn taking in RE sessions. Lessons learned in using the method are summarised and future improvements for the method are discussed.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"18 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130576747","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667814
M. Loomes, S. Jones
This paper puts forward the view that the life-cycle model of system development has been allowed to make the transition from a useful intellectual tool for discussing specific aspects of the process to a definitive statement of what the process actually "is". We argue that this hinders the discussion of Requirements Engineering in fundamental ways, and that challenges to the supremacy of this model are needed to open up effective debate. This is illustrated by the introduction of a model based on the construction of theories, which shifts the emphasis from a technocentric view of the process, where requirements are encoded in initial forms of a system, to one focused on the human understanding of situated systems. Thus requirements become the forces and constraints which influence the designer. We conclude by presenting samples of areas that can be discussed more effectively from this viewpoint.
{"title":"Requirements engineering: A perspective through theory-building","authors":"M. Loomes, S. Jones","doi":"10.1109/ICRE.1998.667814","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667814","url":null,"abstract":"This paper puts forward the view that the life-cycle model of system development has been allowed to make the transition from a useful intellectual tool for discussing specific aspects of the process to a definitive statement of what the process actually \"is\". We argue that this hinders the discussion of Requirements Engineering in fundamental ways, and that challenges to the supremacy of this model are needed to open up effective debate. This is illustrated by the introduction of a model based on the construction of theories, which shifts the emphasis from a technocentric view of the process, where requirements are encoded in initial forms of a system, to one focused on the human understanding of situated systems. Thus requirements become the forces and constraints which influence the designer. We conclude by presenting samples of areas that can be discussed more effectively from this viewpoint.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125323891","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667811
I. Sommerville, P. Sawyer, Stephen Viller
The paper introduces an approach to multi perspective requirements engineering (PREview) which has been designed for industrial use and discusses our practical experience in applying PREview. We have developed a flexible model of viewpoints and using examples from an industrial application, show how this can be used to organise system requirements derived from radically different sources. We show how 'concerns', which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders. We briefly describe the process of using PREview which has been designed to allow incremental requirements elicitation. Finally, we discuss some practical considerations which emerged when the approach was applied in industry.
{"title":"Viewpoints for requirements elicitation: a practical approach","authors":"I. Sommerville, P. Sawyer, Stephen Viller","doi":"10.1109/ICRE.1998.667811","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667811","url":null,"abstract":"The paper introduces an approach to multi perspective requirements engineering (PREview) which has been designed for industrial use and discusses our practical experience in applying PREview. We have developed a flexible model of viewpoints and using examples from an industrial application, show how this can be used to organise system requirements derived from radically different sources. We show how 'concerns', which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders. We briefly describe the process of using PREview which has been designed to allow incremental requirements elicitation. Finally, we discuss some practical considerations which emerged when the approach was applied in industry.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122253687","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667804
R. Linger, N. Mead, H. Lipson
Pervasive societal dependency on large scale, unbounded network systems, the substantial risks of such dependency, and the growing sophistication of system intruders, have focused increased attention on how to ensure network system survivability. Survivability is the capacity of a system to provide essential services even after successful intrusion and compromise, and to recover full services in a timely manner. Requirements for survivable systems must include definitions of essential and non essential services, plus definitions of new survivability services for intrusion resistance, recognition, and recovery. Survivable system requirements must also specify both legitimate and intruder usage scenarios, and survivability practices for system development, operation, and evolution. The paper defines a framework for survivable systems requirements definition and discusses requirements for several emerging survivability strategies. Survivability must be designed into network systems, beginning with effective survivability requirements analysis and definition.
{"title":"Requirements definition for survivable network systems","authors":"R. Linger, N. Mead, H. Lipson","doi":"10.1109/ICRE.1998.667804","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667804","url":null,"abstract":"Pervasive societal dependency on large scale, unbounded network systems, the substantial risks of such dependency, and the growing sophistication of system intruders, have focused increased attention on how to ensure network system survivability. Survivability is the capacity of a system to provide essential services even after successful intrusion and compromise, and to recover full services in a timely manner. Requirements for survivable systems must include definitions of essential and non essential services, plus definitions of new survivability services for intrusion resistance, recognition, and recovery. Survivable system requirements must also specify both legitimate and intruder usage scenarios, and survivability practices for system development, operation, and evolution. The paper defines a framework for survivable systems requirements definition and discusses requirements for several emerging survivability strategies. Survivability must be designed into network systems, beginning with effective survivability requirements analysis and definition.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127798107","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1998-04-06DOI: 10.1109/ICRE.1998.667813
H. Mayr, C. Kop
To overcome the impedance mismatch between requirement analysis and conceptual design, we introduce an intermediate step between the two phases, called conceptual pre-design. A (semantic) model for that phase should allow for an easy collection of requirements as well as for an unproblematic transformation of the collected requirements into entries of a conceptual scheme. We present a model that has been developed along these postulates. Following the classical DATA-ID approach, this model uses a "glossary metaphor" for scheme representation. It's basic semantic notions are 'thing type' and 'connection type'.
{"title":"Conceptual predesign bridging the gap between requirements and conceptual design","authors":"H. Mayr, C. Kop","doi":"10.1109/ICRE.1998.667813","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667813","url":null,"abstract":"To overcome the impedance mismatch between requirement analysis and conceptual design, we introduce an intermediate step between the two phases, called conceptual pre-design. A (semantic) model for that phase should allow for an easy collection of requirements as well as for an unproblematic transformation of the collected requirements into entries of a conceptual scheme. We present a model that has been developed along these postulates. Following the classical DATA-ID approach, this model uses a \"glossary metaphor\" for scheme representation. It's basic semantic notions are 'thing type' and 'connection type'.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"84 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-04-06","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130471167","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}