B. Penzenstadler, Daniel Méndez Fernández, D. Richardson, David Callele, K. Wnuk
A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.
{"title":"The requirements engineering body of knowledge (REBoK)","authors":"B. Penzenstadler, Daniel Méndez Fernández, D. Richardson, David Callele, K. Wnuk","doi":"10.1109/RE.2013.6636758","DOIUrl":"https://doi.org/10.1109/RE.2013.6636758","url":null,"abstract":"A body of knowledge is a term used to represent the complete set of concepts, terms and activities that make up a professional domain. It encompasses the core teachings, skills and research in a field or industry. So far, the discipline of RE is lacking an official Requirements Engineering Body of Knowledge (REBoK). This working session brings together researchers and practitioners to elaborate the goals, requirements and constraints for a REBoK that shall serve as commonly agreed basis for developing a draft over the following months.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"91525763","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}
A little rebellion now and then is a good thing. This short position statement describes my views on some of the challenges associated with many conferences, the Requirements Engineering Conference being among them. The main concepts are; the goals, as well as criteria for paper selection for the conference should be defined explicitly, and shared with the community. Industry involvement in the conference should be increased, but the focus of all tracks should be quality - what constitutes quality however needs to be defined and agreed on. Industrial validation of research results have to be more than an intention. Last but not least, how papers are presented and discussed needs to change, focusing on quality over quantity.
{"title":"A little rebellion now and then is a good thing: Views on the requirements engineering conference","authors":"T. Gorschek","doi":"10.1109/RE.2013.6636751","DOIUrl":"https://doi.org/10.1109/RE.2013.6636751","url":null,"abstract":"A little rebellion now and then is a good thing. This short position statement describes my views on some of the challenges associated with many conferences, the Requirements Engineering Conference being among them. The main concepts are; the goals, as well as criteria for paper selection for the conference should be defined explicitly, and shared with the community. Industry involvement in the conference should be increased, but the focus of all tracks should be quality - what constitutes quality however needs to be defined and agreed on. Industrial validation of research results have to be more than an intention. Last but not least, how papers are presented and discussed needs to change, focusing on quality over quantity.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"78325293","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}
A. Zarghami, Eelco Vriezekolk, M. Eslami, M. V. Sinderen, R. Wieringa
In this paper we consider service-oriented applications composed of component services provided by different, economically independent service providers. As in all composite applications, the component services are composed and configured to meet requirements for the composite application. However, in a field experiment of composite service-oriented applications wef found that, although the services as actually delivered by the service providers meet their requirements, there is still a mismatch across service providers due to unstated assumptions, and that this mismatch causes an incorrect composite application to be delivered to end-users. Identifying and analyzing these initially unstated assumptions turns requirements engineering for service-oriented applications into risk analysis. In this paper, we describe a field experiment with an experimental service-oriented homecare system, in which unexpected behavior of the system turned up unstated assumptions about the contributing service providers. We then present an assumptions-driven risk identification method that can help identifying these risks, and we show how we applied this method in the second iteration of the field experiment. The method adapts some techniques from problem frame diagrams to identify relevant assumptions on service providers. The method is informal, and takes the “view from nowhere” in that it does not result in a specification of the component services, but for every component service delivers a set of assumptions that the service must satisfy in order to contribute to the overall system requirements. We end the paper with a discussion of generalizability of this method.
{"title":"Assumption-based risk identification method (ARM) in dynamic service provisioning","authors":"A. Zarghami, Eelco Vriezekolk, M. Eslami, M. V. Sinderen, R. Wieringa","doi":"10.1109/RE.2013.6636717","DOIUrl":"https://doi.org/10.1109/RE.2013.6636717","url":null,"abstract":"In this paper we consider service-oriented applications composed of component services provided by different, economically independent service providers. As in all composite applications, the component services are composed and configured to meet requirements for the composite application. However, in a field experiment of composite service-oriented applications wef found that, although the services as actually delivered by the service providers meet their requirements, there is still a mismatch across service providers due to unstated assumptions, and that this mismatch causes an incorrect composite application to be delivered to end-users. Identifying and analyzing these initially unstated assumptions turns requirements engineering for service-oriented applications into risk analysis. In this paper, we describe a field experiment with an experimental service-oriented homecare system, in which unexpected behavior of the system turned up unstated assumptions about the contributing service providers. We then present an assumptions-driven risk identification method that can help identifying these risks, and we show how we applied this method in the second iteration of the field experiment. The method adapts some techniques from problem frame diagrams to identify relevant assumptions on service providers. The method is informal, and takes the “view from nowhere” in that it does not result in a specification of the component services, but for every component service delivers a set of assumptions that the service must satisfy in order to contribute to the overall system requirements. We end the paper with a discussion of generalizability of this method.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"77404921","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}
The research on visual analytics for requirements engineering has noticeably advanced in the past few years. For many software projects, requirements management needs an effective and efficient path from data to decision. Visual analytics (VA) creates such a path that enables the user to extract insights by interacting with the relevant information. While various requirements visualization techniques exist, only few have produced end-to-end values to practitioners. In this research proposal, we advance the literature on visual requirements analytics by characterizing its key components and relationships. Such a characterization allows us to not only assess existing approaches, but also develop tool enhancements in a principled manner. We describe our ongoing work on VA and outline future research plans.
{"title":"Visual analytics for software requirements engineering","authors":"S. Reddivari","doi":"10.1109/RE.2013.6636762","DOIUrl":"https://doi.org/10.1109/RE.2013.6636762","url":null,"abstract":"The research on visual analytics for requirements engineering has noticeably advanced in the past few years. For many software projects, requirements management needs an effective and efficient path from data to decision. Visual analytics (VA) creates such a path that enables the user to extract insights by interacting with the relevant information. While various requirements visualization techniques exist, only few have produced end-to-end values to practitioners. In this research proposal, we advance the literature on visual requirements analytics by characterizing its key components and relationships. Such a characterization allows us to not only assess existing approaches, but also develop tool enhancements in a principled manner. We describe our ongoing work on VA and outline future research plans.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"90438606","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}
In this paper, we propose a pattern for decomposing and structuring the model of a feature's behavioural requirements, based on modes of operation (e.g., Active, Inactive, Failed) that are common to features in multiple domains. Interestingly, the highest-level modes of the pattern can serve as a generic behavioural interface for all features that adhere to the pattern. We have applied the pattern in modelling the behavioural requirements of 19 automotive features that were specified in 5 production-grade requirements documents. We found that the pattern was applicable to all 19 features, and that our proposed generic feature interface was applicable to 50 out of 57 inter-feature references.
{"title":"A mode-based pattern for feature requirements, and a generic feature interface","authors":"D. Dietrich, J. Atlee","doi":"10.1109/RE.2013.6636708","DOIUrl":"https://doi.org/10.1109/RE.2013.6636708","url":null,"abstract":"In this paper, we propose a pattern for decomposing and structuring the model of a feature's behavioural requirements, based on modes of operation (e.g., Active, Inactive, Failed) that are common to features in multiple domains. Interestingly, the highest-level modes of the pattern can serve as a generic behavioural interface for all features that adhere to the pattern. We have applied the pattern in modelling the behavioural requirements of 19 automotive features that were specified in 5 production-grade requirements documents. We found that the pattern was applicable to all 19 features, and that our proposed generic feature interface was applicable to 50 out of 57 inter-feature references.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"91292332","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}
Requirements elicitation research is reviewed using a framework categorising the relative `knowness' of requirements specification and Common Ground discourse theory. The main contribution of this survey is to review requirements elicitation from the perspective of this framework and propose a road map of research to tackle outstanding elicitation problems involving tacit knowledge. Elicitation techniques (interviews, scenarios, prototypes, etc.) are investigated, followed by representations, models and support tools. The survey results suggest that elicitation techniques appear to be relatively mature, although new areas of creative requirements are emerging. Representations and models are also well established although there is potential for more sophisticated modelling of domain knowledge. While model-checking tools continue to become more elaborate, more growth is apparent in NL tools such as text mining and IR which help to categorize and disambiguate requirements. Social collaboration support is a relatively new area that facilitates categorisation, prioritisation and matching collections of requirements for product line versions. A road map for future requirements elicitation research is proposed investigating the prospects for techniques, models and tools in green-field domains where few solutions exist, contrasted with brown-field domains where collections of requirements and products already exist. The paper concludes with remarks on the possibility of elicitation tackling the most difficult question of `unknown unknown' requirements.
{"title":"Requirements elicitation: Towards the unknown unknowns","authors":"A. Sutcliffe, P. Sawyer","doi":"10.1109/RE.2013.6636709","DOIUrl":"https://doi.org/10.1109/RE.2013.6636709","url":null,"abstract":"Requirements elicitation research is reviewed using a framework categorising the relative `knowness' of requirements specification and Common Ground discourse theory. The main contribution of this survey is to review requirements elicitation from the perspective of this framework and propose a road map of research to tackle outstanding elicitation problems involving tacit knowledge. Elicitation techniques (interviews, scenarios, prototypes, etc.) are investigated, followed by representations, models and support tools. The survey results suggest that elicitation techniques appear to be relatively mature, although new areas of creative requirements are emerging. Representations and models are also well established although there is potential for more sophisticated modelling of domain knowledge. While model-checking tools continue to become more elaborate, more growth is apparent in NL tools such as text mining and IR which help to categorize and disambiguate requirements. Social collaboration support is a relatively new area that facilitates categorisation, prioritisation and matching collections of requirements for product line versions. A road map for future requirements elicitation research is proposed investigating the prospects for techniques, models and tools in green-field domains where few solutions exist, contrasted with brown-field domains where collections of requirements and products already exist. The paper concludes with remarks on the possibility of elicitation tackling the most difficult question of `unknown unknown' requirements.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"85574953","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}
Requirements management and traceability have always been one of grand challenges in software development area. Studies reveal that 30-40% of software defects can be traced to gaps or errors in requirements Although several models and techniques have been defined to optimize the requirements process, ensuring alignment and consistency of elicited requirements continues to be a challenge. All software engineering standards and methodologies recognize the importance of maintaining relationships among the software elements for traceability. We have leveraged the structured relationships among the requirement elements to come up with an approach to systematically carry out consistency analysis of requirements for software systems. The framework has multiple models: a multi layered requirement model, a configuration structure to link and track the requirement items, a consistency analysis method to identify the inconsistencies in the requirements and a consistency index computation to indicate the level of consistency in overall requirements of the software system. This approach helps to validate the requirements from both completeness and correctness perspectives and also check their consistency in forward and backward directions. The paper outlines the framework, describes the encompassing models and the implementation details from pilot of the framework to an industry case study along with results.
{"title":"An approach to carry out consistency analysis on requirements: Validating and tracking requirements through a configuration structure","authors":"Padmalata V. Nistala, Priyanka Kumari","doi":"10.1109/RE.2013.6636737","DOIUrl":"https://doi.org/10.1109/RE.2013.6636737","url":null,"abstract":"Requirements management and traceability have always been one of grand challenges in software development area. Studies reveal that 30-40% of software defects can be traced to gaps or errors in requirements Although several models and techniques have been defined to optimize the requirements process, ensuring alignment and consistency of elicited requirements continues to be a challenge. All software engineering standards and methodologies recognize the importance of maintaining relationships among the software elements for traceability. We have leveraged the structured relationships among the requirement elements to come up with an approach to systematically carry out consistency analysis of requirements for software systems. The framework has multiple models: a multi layered requirement model, a configuration structure to link and track the requirement items, a consistency analysis method to identify the inconsistencies in the requirements and a consistency index computation to indicate the level of consistency in overall requirements of the software system. This approach helps to validate the requirements from both completeness and correctness perspectives and also check their consistency in forward and backward directions. The paper outlines the framework, describes the encompassing models and the implementation details from pilot of the framework to an industry case study along with results.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"79499057","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}
In a previous case study, we presented data demonstrating the impact that a well-written and well-reviewed set of requirements had on software defects and other quality indicators between two generations of an Intel product. The first generation was coded from an unorganized collection of requirements that were reviewed infrequently and informally. In contrast, the second was developed based on a set of requirements stored in a Requirements Management database and formally reviewed at each revision. Quality indicators for the second software product all improved dramatically even with the increased complexity of the newer product. This paper will recap that study and then present data from a subsequent Intel case study revealing that quality enhancements continued on the third generation of the product. The third generation software was designed and coded using the final set of requirements from the second version as a starting point. Key product differentiators included changes to operate with a new Intel processor, the introduction of new hardware platforms and the addition of approximately fifty new features. Software development methodologies were nearly identical, with only the change to a continuous build process for source code check-in added. Despite the enhanced functionality and complexity in the third generation software, requirements defects, software defects, software sightings, feature commit vs. delivery (feature variance), defect closure efficiency rates, and number of days from project commit to customer release all improved from the second to the third generation of the software.
{"title":"The impact of requirements on software quality across three product generations","authors":"John Terzakis","doi":"10.1109/RE.2013.6636731","DOIUrl":"https://doi.org/10.1109/RE.2013.6636731","url":null,"abstract":"In a previous case study, we presented data demonstrating the impact that a well-written and well-reviewed set of requirements had on software defects and other quality indicators between two generations of an Intel product. The first generation was coded from an unorganized collection of requirements that were reviewed infrequently and informally. In contrast, the second was developed based on a set of requirements stored in a Requirements Management database and formally reviewed at each revision. Quality indicators for the second software product all improved dramatically even with the increased complexity of the newer product. This paper will recap that study and then present data from a subsequent Intel case study revealing that quality enhancements continued on the third generation of the product. The third generation software was designed and coded using the final set of requirements from the second version as a starting point. Key product differentiators included changes to operate with a new Intel processor, the introduction of new hardware platforms and the addition of approximately fifty new features. Software development methodologies were nearly identical, with only the change to a continuous build process for source code check-in added. Despite the enhanced functionality and complexity in the third generation software, requirements defects, software defects, software sightings, feature commit vs. delivery (feature variance), defect closure efficiency rates, and number of days from project commit to customer release all improved from the second to the third generation of the software.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"85212133","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}
Software requirement patterns have been proposed as a type of artifact for fostering requirements reuse. In this paper, we present PABRE-Proj a tool aimed at supporting requirements elicitation and specification.
{"title":"PABRE-Proj: Applying patterns in requirements elicitation","authors":"Cristina Palomares, C. Quer, Xavier Franch","doi":"10.1109/RE.2013.6636741","DOIUrl":"https://doi.org/10.1109/RE.2013.6636741","url":null,"abstract":"Software requirement patterns have been proposed as a type of artifact for fostering requirements reuse. In this paper, we present PABRE-Proj a tool aimed at supporting requirements elicitation and specification.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"88645135","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}
Requirements are traditionally viewed as being free of the details of an envisioned solution and specified using purely problem domain entities. Preventing premature design in the requirements permits the available design space not to be restricted too early which might inhibit innovative designs. In practice, on many industrial projects, separating the problem and solution domain entities can be difficult, and arguably there are benefits for not doing so. Many customers feel more confident describing their requirements, often as the difference between the existing products and their needs, some customers have such intimate knowledge of their products that their requirements tend to be very specific, and if the customer knows the exact solution needed that naturally will reduce the cost of the requirements elicitation as well as design activities. Practitioners are challenged to understand when having solution information in requirements is sensible and when it should be avoided. In this research challenge paper, we advocate that researchers should identify different contexts and corresponding criteria that practitioners can use to evaluate when requirements specifications may include design information. To understand the research challenge we present experiences from real projects and suggest possible factors that affect when design information may be viable in requirements specifications.
{"title":"Challenges in balancing the amount of solution information in requirement specifications for embedded products","authors":"J. Savolainen, Dagny Hauksdottir, M. Mannion","doi":"10.1109/RE.2013.6636726","DOIUrl":"https://doi.org/10.1109/RE.2013.6636726","url":null,"abstract":"Requirements are traditionally viewed as being free of the details of an envisioned solution and specified using purely problem domain entities. Preventing premature design in the requirements permits the available design space not to be restricted too early which might inhibit innovative designs. In practice, on many industrial projects, separating the problem and solution domain entities can be difficult, and arguably there are benefits for not doing so. Many customers feel more confident describing their requirements, often as the difference between the existing products and their needs, some customers have such intimate knowledge of their products that their requirements tend to be very specific, and if the customer knows the exact solution needed that naturally will reduce the cost of the requirements elicitation as well as design activities. Practitioners are challenged to understand when having solution information in requirements is sensible and when it should be avoided. In this research challenge paper, we advocate that researchers should identify different contexts and corresponding criteria that practitioners can use to evaluate when requirements specifications may include design information. To understand the research challenge we present experiences from real projects and suggest possible factors that affect when design information may be viable in requirements specifications.","PeriodicalId":6342,"journal":{"name":"2013 21st IEEE International Requirements Engineering Conference (RE)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2013-07-15","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"73186638","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
扫码关注我们
求助内容：
应助结果提醒方式：