A. V. Lamsweerde, Robert Darimont, Philippe Massonet
{"title":"Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt","authors":"A. V. Lamsweerde, Robert Darimont, Philippe Massonet","doi":"10.1109/ISRE.1995.512561","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512561","url":null,"abstract":"Recently a number of requirements engineering languages and methods have flourished that not only address 'what' questions but also 'why', 'who' and 'when' questions. The objective of the paper is twofold: to assess the strengths and weaknesses of one of these methodologies on a nontrivial benchmark; and to illustrate and discuss a number of challenging issues that need to be addressed for such methodologies to become effective in supporting real, complex requirements engineering tasks. The problem considered here is that of a distributed meeting scheduler system; the methodology considered is the KAOS goal directed language and method. The issues raised from this case study include goal identification, the \"deidelization\" of unachievable goals, the handling of interfering goals, the impact of early formal reasoning, the merits of early reuse of abstract descriptions and categories, requirements traceability and the need to link requirements to retractable assumptions, and the potential benefits of hybrid acquisition strategies.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"232 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129332857","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}
{"title":"Implementing requirements traceability: a case study","authors":"B. Ramesh, T. Powers, Curtis Stubbs, M. Edwards","doi":"10.1109/ISRE.1995.512549","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512549","url":null,"abstract":"Many standards that mandate requirements traceability as well as current literature do not provide a comprehensive model of what information should be captured and used as a part of a traceability scheme. Therefore, the practices and usefulness of traceability vary considerably across systems development efforts, ranging from very simplistic practices just aimed at satisfying the mandates to very comprehensive traceability schemes used as an important tool for managing the systems development process. We present a case study of a systems development organization, employing a comprehensive view of traceability. A model describing the traceability practice in the organization, perceived benefits of such a scheme and lessons learnt from implementing it are presented.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"109 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124144825","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}
{"title":"Invented requirements and imagined customers: requirements engineering for off-the-shelf software","authors":"C. Potts","doi":"10.1109/ISRE.1995.512553","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512553","url":null,"abstract":"The requirements engineering research and consulting communities are not serving the interests of software developers who build off-the-shelf application software. Most of our models and methods evolved with the aid of funding from organizations interested in obtaining unique systems under contract and in which there is a clear interface between \"customer\" and \"developer\". These origins have spawned many assumptions about what requirements are. Through several design scenarios I illustrate how these assumptions break down in the case of off-the-shelf software. I then suggest some alternative priorities that would address these shortcomings. My aim is to provoke and stimulate thought, not to propose a developed solution.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128035287","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}
{"title":"A client oriented requirements baseline","authors":"Julio Cesar Sampaio do Prado Leite, A. Oliveira","doi":"10.1109/ISRE.1995.512551","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512551","url":null,"abstract":"Traceability, a major issue in software engineering, is seldom present at the initial requirements engineering process. The paper reports a proposal for organizing requirements statements as a model, where change and evolution are taken into consideration. The model uses natural language statements as its basic representation, which helps the communication between clients and software engineers. The model is supported by a customized software system for which a prototype was built and used in an industrial setting.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"72 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131820418","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}
{"title":"A field study of requirements engineering practices in information systems development","authors":"K. Emam, N. Madhavji","doi":"10.1109/ISRE.1995.512547","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512547","url":null,"abstract":"To make recommendations for improving requirements engineering processes, it is critical to understand the problems faced in contemporary practice. We describe a field study whose general objectives were to formulate recommendations to practitioners for improving requirements engineering processes, and to provide directions for future research on methods and tools. The results indicate that there are seven key issues of greatest concern in requirements engineering practice. These issues are discussed in terms of the problems they represent, how these problems are addressed successfully in practice, and impediments to the implementation of such good practices.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"114 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125026147","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}
{"title":"A task centered approach to analysing human error tolerance requirements","authors":"B. Fields, P. Wright, M. Harrison","doi":"10.1109/ISRE.1995.512542","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512542","url":null,"abstract":"We put forward an approach to deriving and applying human error tolerance requirements. Such requirements are concerned with the response of a system to errors introduced by human operators. The approach provides a means by which operators' tasks can be described and analysed for likely errors and the impact of these errors on system safety can be explored. The approach, based on previous work by the same authors (P. Wright et al., 1994), uses a software engineering notation to provide the bridge between operator models and systems engineering concerns. The approach is extended to include a more refined understanding of the processes that contribute to human error. The operators' process in achieving goals is understood in terms of structured tasks. With this additional apparatus we are able to capture a more complex set of human error forms.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"80 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128605445","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}
{"title":"Requirements traceability in an integrated development environment","authors":"I. Macfarlane, I. Reilly","doi":"10.1109/ISRE.1995.512552","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512552","url":null,"abstract":"Good development environment support is essential for good requirements traceability. The paper describes how requirements traceability is supported in Bell-Northern Research's Integrated Development Environment, an internally developed version control and configuration management environment. Emphasis is given to the way in which requirements traceability interacts with the key features of the environment: generic (tool independent), fine-grained design information management that permits users to quickly integrate new tools, and version control/configuration management.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115267305","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}
{"title":"Challenges in requirements engineering","authors":"J. Bubenko","doi":"10.1109/ISRE.1995.512557","DOIUrl":"https://doi.org/10.1109/ISRE.1995.512557","url":null,"abstract":"We discuss a number of essential problems of software requirements engineering, related to management, organisations, users, stakeholders, methodology, tools, and education. Most of the problems seem to have their roots in how requirements engineering is appreciated at the business management and IT management levels.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123203142","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}
{"title":"Integrating requirements analysis and safety analysis","authors":"J. Atlee, J. Mcdermid","doi":"10.1109/ISRE.1995.1393410","DOIUrl":"https://doi.org/10.1109/ISRE.1995.1393410","url":null,"abstract":"Summary form only given. In developing software for safety critical systems, it is necessary to carry out both requirements analysis and safety analysis. During requirements analysis, the behavioural and functional requirements of the system's software components are defined, documented, and reviewed. In addition, the requirements analyst is responsible for identifying and documenting the system safety requirements that pertain to the system's software. Safety analysis techniques are used to determine whether or not the safety requirements are satisfied. Traditionally, safety analysis has been performed on designs of the system's software, including a high level design, and not on the system's software requirements specification. However, if the requirements are described in terms of an operational model, a safety analysis of the requirements is possible. Are there any requirements techniques that help with the problems of developing safety critical software? Are there any requirements techniques that hinder development of such software? Is it effective to perform parts of a safety analysis on the requirements specification, as opposed to delaying analysis until design or implementation? If so, what parts of a safety analysis should be done on the requirements specification, and what parts should be done on the design description?.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122345124","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}
{"title":"Classification of research efforts in requirements engineering","authors":"P. Zave","doi":"10.1145/267580.267581","DOIUrl":"https://doi.org/10.1145/267580.267581","url":null,"abstract":"The article proposes and justifies a trial classification scheme. An earlier version was used to organize the papers submitted to this symposium, and the scheme has been refined somewhat in response to inadequacies discovered during the process of selecting the program. The first issue to be tackled is the heterogeneity of the topics usually considered part of requirements engineering. They include: tasks that must be completed; problems that must be solved; solutions to problems; ways of contributing to knowledge; and types of system. There seems to be a need for several orthogonal dimensions of classification. While multiple dimensions certainly help us cope with the heterogeneity of concerns, there is a danger of making the classification scheme too complex to use. I have compromised by settling on two dimensions.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123475078","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}