Attendants Imad Abugessaisa (FPX), Lars Bernard (TUD), Mohamed Bishr (ifgi), Johannes Brauner (TUD), Carlos Granell (UJI), Bernard Hakizimana (CGIS-NUR/ITC), Chris Higgins (EDINA), Mike Jackson (CGS), Ari Jolma (TKK), Volker Kraut (TUM), Rob Lemmens (ITC), Michael Lutz (JRC), David Medyckyj-Scott (EDINA), Jeremy Morley (UCL), Edward Nash (Uni Rostock), Anders Östman (HIG), Albert Remke (52°North), Valentina Sagris (JRC), Ulf Sandgren (Läntmätriet), Solgerd Tanzilli (FPX), Danny Vandenbroucke (SADL), Andreas von Dömming (BKG), Regine Weber (UNIBW)
出席者 Imad Abugessaisa (FPX), Lars Bernard (TUD), Mohamed Bishr (ifgi), Johannes Brauner (TUD), Carlos Granell (UJI), Bernard Hakizimana (CGIS-NUR/ITC), Chris Higgins (EDINA), Mike Jackson (CGS), Ari Jolma (TKK), Volker Kraut (TUM), Rob Lemmens (ITC), Michael Lutz (JRC)、David Medyckyj-Scott (EDINA), Jeremy Morley (UCL), Edward Nash (Uni Rostock), Anders Östman (HIG), Albert Remke (52°North), Valentina Sagris (JRC), Ulf Sandgren (Läntmätriet), Solgerd Tanzilli (FPX), Danny Vandenbroucke (SADL), Andreas von Dömming (BKG), Regine Weber (UNIBW)
{"title":"Report from the Pre-Conference Workshop","authors":"Brian Lawrence","doi":"10.1109/ICRE.1998.10000","DOIUrl":"https://doi.org/10.1109/ICRE.1998.10000","url":null,"abstract":"Attendants Imad Abugessaisa (FPX), Lars Bernard (TUD), Mohamed Bishr (ifgi), Johannes Brauner (TUD), Carlos Granell (UJI), Bernard Hakizimana (CGIS-NUR/ITC), Chris Higgins (EDINA), Mike Jackson (CGS), Ari Jolma (TKK), Volker Kraut (TUM), Rob Lemmens (ITC), Michael Lutz (JRC), David Medyckyj-Scott (EDINA), Jeremy Morley (UCL), Edward Nash (Uni Rostock), Anders Östman (HIG), Albert Remke (52°North), Valentina Sagris (JRC), Ulf Sandgren (Läntmätriet), Solgerd Tanzilli (FPX), Danny Vandenbroucke (SADL), Andreas von Dömming (BKG), Regine Weber (UNIBW)","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"9 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":"131891791","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.667807
Xiping Song, W. Hasling, Gaurav Mangla, W. Sherman
Tracing requirements and other documents in large software projects are very difficult, particularly when these documents are distributed over a heterogeneous computing environment. In order to address such needs, we have experimented with Web technologies to aid the tracing of requirements. Our project (called STAR-Track) has been completed through requirement analysis, design and a prototype implementation. The paper reports on the lessons we learned from these activities.
{"title":"Lessons learned from building a Web-based requirements tracing system","authors":"Xiping Song, W. Hasling, Gaurav Mangla, W. Sherman","doi":"10.1109/ICRE.1998.667807","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667807","url":null,"abstract":"Tracing requirements and other documents in large software projects are very difficult, particularly when these documents are distributed over a heterogeneous computing environment. In order to address such needs, we have experimented with Web technologies to aid the tracing of requirements. Our project (called STAR-Track) has been completed through requirement analysis, design and a prototype implementation. The paper reports on the lessons we learned from these activities.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"6 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":"114960847","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.667805
R. Lutz, Guy G. Helmer, Michelle M. Moseman, Dave Statezni, S. Tockey
A safety analysis was performed on the software requirements for a family of flight instrumentation displays of commercial aircraft. First, an existing safety checklist was extended to apply to four-variable models and used to analyze the requirements models for representative members of the product family. The results were evaluated against an initial specification of the product family's required commonalities and variabilities. The safety checklist was found to be effective at analyzing the completeness of the product family requirements and at identifying additional variabilities and commonalities. Secondly, a forward and backward search for hazards was performed on representative members of the product family. Additional safety requirements for enhanced fault tolerance were derived from these searches. The safety analysis techniques used here appear to have applicability for enhancing the completeness and robustness of a product family's safety related software requirements.
{"title":"Safety analysis of requirements for a product family","authors":"R. Lutz, Guy G. Helmer, Michelle M. Moseman, Dave Statezni, S. Tockey","doi":"10.1109/ICRE.1998.667805","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667805","url":null,"abstract":"A safety analysis was performed on the software requirements for a family of flight instrumentation displays of commercial aircraft. First, an existing safety checklist was extended to apply to four-variable models and used to analyze the requirements models for representative members of the product family. The results were evaluated against an initial specification of the product family's required commonalities and variabilities. The safety checklist was found to be effective at analyzing the completeness of the product family requirements and at identifying additional variabilities and commonalities. Secondly, a forward and backward search for hazards was performed on representative members of the product family. Additional safety requirements for enhanced fault tolerance were derived from these searches. The safety analysis techniques used here appear to have applicability for enhancing the completeness and robustness of a product family's safety related software requirements.","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":"129411745","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.667806
Theodore Hammer, Lenore Huffman
At NASA and across industry, with multiple release projects, requirement storage is a volatile, dynamic process. The skill with which a project maintains, keeps current, tracks, and traces its set of requirements affects every phase of the project's software development life cycle-including maintenance. The ability to effectively manage requirements influences, months and/or years before project completion, how, when, and how expensively completion, will take place. The Software Assurance Technology Center (SATC) at NASA Goddard Space Flight Center is working to continually evaluate the requirement activities of a multi billion dollar project. This task requires that the SATC evaluate the project's tools, specifically the requirement database management tool. The objective of the paper is to identify a major failing in the use of requirement management tools that causes loss of data, loss of data integrity, and loss of tool functionality. It also shows that bringing engineers and database designers together to define tool use is mandatory; and that each discipline's experience and expertise is required for successful tool implementation. Using experiences from a NASA project, we demonstrate some potential risks when a requirement management tool is incorrectly used, and how this fatal flaw plants the seeds of requirement management destruction and consequent project overruns. This information will benefit any project considering or using requirement management tools.
{"title":"Automated requirements management-beware HOW you use tools: an experience report","authors":"Theodore Hammer, Lenore Huffman","doi":"10.1109/ICRE.1998.667806","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667806","url":null,"abstract":"At NASA and across industry, with multiple release projects, requirement storage is a volatile, dynamic process. The skill with which a project maintains, keeps current, tracks, and traces its set of requirements affects every phase of the project's software development life cycle-including maintenance. The ability to effectively manage requirements influences, months and/or years before project completion, how, when, and how expensively completion, will take place. The Software Assurance Technology Center (SATC) at NASA Goddard Space Flight Center is working to continually evaluate the requirement activities of a multi billion dollar project. This task requires that the SATC evaluate the project's tools, specifically the requirement database management tool. The objective of the paper is to identify a major failing in the use of requirement management tools that causes loss of data, loss of data integrity, and loss of tool functionality. It also shows that bringing engineers and database designers together to define tool use is mandatory; and that each discipline's experience and expertise is required for successful tool implementation. Using experiences from a NASA project, we demonstrate some potential risks when a requirement management tool is incorrectly used, and how this fatal flaw plants the seeds of requirement management destruction and consequent project overruns. This information will benefit any project considering or using requirement management tools.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"88 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":"114791149","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.667830
P. Forsgren, A. Daugulis
This paper deals with requirements engineering (RE) in control center procurement projects in the power industry. Post-analysis of a large number of such projects has been made. Based on these experiences, combined with general purpose RE concepts, a method for elicitation, expression, and test of system requirements on these kinds of systems has been worked out. The method has been used in two full-scale procurements: a project in which the Swedish power grid company is procuring a new national control center for the Swedish transmission network, and a project in which the Latvian state power board, Latvenergo, is procuring one national control center and two regional control centers for its power system. In this paper, an introduction to the above mentioned RE method is given. Further on, the focus is on the practical experiences from the two full-scale projects in which the method has been used.
{"title":"Requirements engineering in control center procurement projects: practical experiences from the power industry","authors":"P. Forsgren, A. Daugulis","doi":"10.1109/ICRE.1998.667830","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667830","url":null,"abstract":"This paper deals with requirements engineering (RE) in control center procurement projects in the power industry. Post-analysis of a large number of such projects has been made. Based on these experiences, combined with general purpose RE concepts, a method for elicitation, expression, and test of system requirements on these kinds of systems has been worked out. The method has been used in two full-scale procurements: a project in which the Swedish power grid company is procuring a new national control center for the Swedish transmission network, and a project in which the Latvian state power board, Latvenergo, is procuring one national control center and two regional control centers for its power system. In this paper, an introduction to the above mentioned RE method is given. Further on, the focus is on the practical experiences from the two full-scale projects in which the method has been used.","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":"121164366","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.667803
F. Schneider, S. Easterbrook, J. Callahan, G. Holzmann
Model checking is shown to be an effective tool in validating the behavior of a fault tolerant embedded spacecraft controller. The case study presented, shows that by judiciously abstracting away extraneous complexity, the state space of the model could be exhaustively searched allowing critical functional requirements to be validated down to the design level. Abstracting away detail not germane to the problem of interest leaves by definition a partial specification behind. The success of this procedure shows that it is feasible to effectively validate a partial specification with this technique. Three anomalies were found in the system. One was an error in the detailed requirements, and the other two were missing/ambiguous requirements. Because the method allows validation of partial specifications, it is also an effective approach for maintaining fidelity between a co-evolving specification and an implementation.
{"title":"Validating requirements for fault tolerant systems using model checking","authors":"F. Schneider, S. Easterbrook, J. Callahan, G. Holzmann","doi":"10.1109/ICRE.1998.667803","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667803","url":null,"abstract":"Model checking is shown to be an effective tool in validating the behavior of a fault tolerant embedded spacecraft controller. The case study presented, shows that by judiciously abstracting away extraneous complexity, the state space of the model could be exhaustively searched allowing critical functional requirements to be validated down to the design level. Abstracting away detail not germane to the problem of interest leaves by definition a partial specification behind. The success of this procedure shows that it is feasible to effectively validate a partial specification with this technique. Three anomalies were found in the system. One was an error in the detailed requirements, and the other two were missing/ambiguous requirements. Because the method allows validation of partial specifications, it is also an effective approach for maintaining fidelity between a co-evolving specification and an implementation.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"101 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":"116019513","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.667824
Marilyn T. Gaska, D. C. Gause
This paper describes a method and a sample application of an approach to cross-discipline requirements engineering process patterns. The patterns concept has been applied to the cross-discipline design process domain to include requirements definition, analysis, and validation in contrast to previous efforts in requirements product pattern and discipline-specific process patterns. A method, template, and example process pattern are described. Ways to apply this method to extend the requirement exploration framework of Gause and Weinberg (1989) are proposed for generic design problems in any discipline to include a domain-specific process composition approach. A proposed list of patterns based on this framework is provided. A follow on paper will detail cross-discipline analysis results and pattern identification to include case study analysis from an exemplar set of successful and failed projects and validation using a final case study.
{"title":"An approach for cross-discipline requirements engineering process patterns","authors":"Marilyn T. Gaska, D. C. Gause","doi":"10.1109/ICRE.1998.667824","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667824","url":null,"abstract":"This paper describes a method and a sample application of an approach to cross-discipline requirements engineering process patterns. The patterns concept has been applied to the cross-discipline design process domain to include requirements definition, analysis, and validation in contrast to previous efforts in requirements product pattern and discipline-specific process patterns. A method, template, and example process pattern are described. Ways to apply this method to extend the requirement exploration framework of Gause and Weinberg (1989) are proposed for generic design problems in any discipline to include a domain-specific process composition approach. A proposed list of patterns based on this framework is provided. A follow on paper will detail cross-discipline analysis results and pattern identification to include case study analysis from an exemplar set of successful and failed projects and validation using a final case study.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"7 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":"128759940","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-03-01DOI: 10.1109/ICRE.1998.667832
N. Maiden, Cornelius Ncube
An increasing number of organisations are procuring off-the-shelf systems from commercial suppliers. However, successful selection of off-the-shelf systems to fit customer requirements remains problematic. The London Ambulance Service fiasco in 1992 is a well-known example of system failure due, at least in part, to poor product selection. New methods and techniques for requirements acquisition and product selection are needed. The authors propose a new method which integrates techniques from several disciplines in response to lessons learned from a complex commercial off-the-shelf product selection exercise undertaken by the authors. They report on a recent experience in selecting a complex commercial off-the-shelf software system to be compliant with over 130 customer requirements, and lessons learned from the experience. These lessons learned inform design of PORE (Procurement-Oriented Requirements Engineering), a template-based method for requirements acquisition. This paper reports 11 of these lessons. Particular focus is put on the typical problems which arose during acquisition of requirements to enable this selection, and solutions to avoid these problems in the future.
{"title":"Acquiring COTS software selection requirements","authors":"N. Maiden, Cornelius Ncube","doi":"10.1109/ICRE.1998.667832","DOIUrl":"https://doi.org/10.1109/ICRE.1998.667832","url":null,"abstract":"An increasing number of organisations are procuring off-the-shelf systems from commercial suppliers. However, successful selection of off-the-shelf systems to fit customer requirements remains problematic. The London Ambulance Service fiasco in 1992 is a well-known example of system failure due, at least in part, to poor product selection. New methods and techniques for requirements acquisition and product selection are needed. The authors propose a new method which integrates techniques from several disciplines in response to lessons learned from a complex commercial off-the-shelf product selection exercise undertaken by the authors. They report on a recent experience in selecting a complex commercial off-the-shelf software system to be compliant with over 130 customer requirements, and lessons learned from the experience. These lessons learned inform design of PORE (Procurement-Oriented Requirements Engineering), a template-based method for requirements acquisition. This paper reports 11 of these lessons. Particular focus is put on the typical problems which arose during acquisition of requirements to enable this selection, and solutions to avoid these problems in the future.","PeriodicalId":207183,"journal":{"name":"Proceedings of IEEE International Symposium on Requirements Engineering: RE '98","volume":"21 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123884036","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：