Pub Date : 1993-01-04DOI: 10.1109/ISRE.1993.324839
E. Yu
In attempting to understand information system environments during requirements engineering, it is often helpful to have an understanding of the 'whys' as well as the 'whats' about the environment. A natural way to answer why questions is by tracing them to goals. In an organizational environment, however, the whys do not originate from a single set of given goals. Organizational agents depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. A requirements model that captures knowledge about an organizational environment can be enriched by including the network of dependency relationships among agents. A set of intentional operators for modeling dependencies among agents is proposed, and a preliminary axiomatic characterization is presented.<>
{"title":"Modeling organizations for information systems requirements engineering","authors":"E. Yu","doi":"10.1109/ISRE.1993.324839","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324839","url":null,"abstract":"In attempting to understand information system environments during requirements engineering, it is often helpful to have an understanding of the 'whys' as well as the 'whats' about the environment. A natural way to answer why questions is by tracing them to goals. In an organizational environment, however, the whys do not originate from a single set of given goals. Organizational agents depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. A requirements model that captures knowledge about an organizational environment can be enriched by including the network of dependency relationships among agents. A set of intentional operators for modeling dependencies among agents is proposed, and a preliminary axiomatic characterization is presented.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"2017 10","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132679368","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324822
J. Goguen, C. Linde
The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself.<>
{"title":"Techniques for requirements elicitation","authors":"J. Goguen, C. Linde","doi":"10.1109/ISRE.1993.324822","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324822","url":null,"abstract":"The authors survey and evaluate techniques for eliciting requirements of computer-based systems, paying particular attention to dealing with social issues. The methods surveyed include introspection, interviews, questionnaires, and protocol, conversation, interaction, and discourse analyses. The last three techniques grew out of ethnomethodology and sociolinguistics. They can elicit tacit knowledge by observing actual interactions in the workplace, and can also be applied to the system development process itself.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134396696","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324846
Eiji Kuwana, J. Herbsleb
The selection and structuring of requirements engineering data necessitates an empirical prediction about the future utility of the selected data and of the retrieval paths available in the structure. In order to investigate these predictions, the questions asked by software engineers at software requirements and preliminary design meetings are analyzed. It is assumed that the kinds of information elicited by these questions are good indicators of what data would be most useful. Results lend support to systems that focus on the developing artifact itself, and indicate the importance of user scenarios.<>
{"title":"Representing knowledge in requirements engineering: an empirical study of what software engineers need to know","authors":"Eiji Kuwana, J. Herbsleb","doi":"10.1109/ISRE.1993.324846","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324846","url":null,"abstract":"The selection and structuring of requirements engineering data necessitates an empirical prediction about the future utility of the selected data and of the retrieval paths available in the structure. In order to investigate these predictions, the questions asked by software engineers at software requirements and preliminary design meetings are analyzed. It is assumed that the kinds of information elicited by these questions are good indicators of what data would be most useful. Results lend support to systems that focus on the developing artifact itself, and indicate the importance of user scenarios.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"287 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133489318","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324835
S. Easterbrook
It is shown how domain modelling can be used within requirements engineering to reveal the conceptual models used by the participants, and relate these to one another. Existing elicitation techniques used in AI adopt a purely cognitive stance, in that they model a single problem-cognitive stance, and ignore the social and organizational context. A framework for representing alternative, conflicting viewpoints in a single domain model is described. The framework is based on the development of a hierarchy of viewpoint descriptions, where lower levels of the hierarchy contain the conflicts. The hierarchies can be viewed in a number of ways, and allow the participants to develop an understanding of each other's perspective. The framework is supported by a set of tools for developing and manipulating these hierarchies.<>
{"title":"Domain modelling with hierarchies of alternative viewpoints","authors":"S. Easterbrook","doi":"10.1109/ISRE.1993.324835","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324835","url":null,"abstract":"It is shown how domain modelling can be used within requirements engineering to reveal the conceptual models used by the participants, and relate these to one another. Existing elicitation techniques used in AI adopt a purely cognitive stance, in that they model a single problem-cognitive stance, and ignore the social and organizational context. A framework for representing alternative, conflicting viewpoints in a single domain model is described. The framework is based on the development of a hierarchy of viewpoint descriptions, where lower levels of the hierarchy contain the conflicts. The hierarchies can be viewed in a number of ways, and allow the participants to develop an understanding of each other's perspective. The framework is supported by a set of tools for developing and manipulating these hierarchies.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123985738","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324830
Thomas J. Smith
A hypertext system, READS, designed to support the key requirements engineering activities of requirements discovery, analysis, decomposition, allocation, traceability and reporting is discussed. READS facilitates the construction, browsing, and maintenance of a typed hypertext network mapped onto a high-speed relational database server through a user interface designed specifically for the system engineer. READS is an integral part of an evolving Paramax system development environment whose goals include the specification of a requirements engineering process and the tool suite necessary to support it. An interface between READS and software using pictures has been developed to test this concept, and it is in active use in many Paramax programs.<>
{"title":"READS: a requirements engineering tool","authors":"Thomas J. Smith","doi":"10.1109/ISRE.1993.324830","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324830","url":null,"abstract":"A hypertext system, READS, designed to support the key requirements engineering activities of requirements discovery, analysis, decomposition, allocation, traceability and reporting is discussed. READS facilitates the construction, browsing, and maintenance of a typed hypertext network mapped onto a high-speed relational database server through a user interface designed specifically for the system engineer. READS is an integral part of an evolving Paramax system development environment whose goals include the specification of a requirements engineering process and the tool suite necessary to support it. An interface between READS and software using pictures has been developed to test this concept, and it is in active use in many Paramax programs.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129214469","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324837
M. Harrison, P. Barnard
Requirements that involve the usability of systems can be properties of interactions rather than systems alone. This proposition is demonstrated by means of four examples. The authors suggest that a notation like CSP (communicating sequential processes) may be used to provide a framework for considering different modeling approaches. Interaction requirements that relate to multiwindowed systems, walk up and use systems, and dynamic systems such as power stations are considered. It is shown how models provide different representations to which advice from the different disciplines of human computer interaction may be applied.<>
{"title":"On defining requirements for interaction","authors":"M. Harrison, P. Barnard","doi":"10.1109/ISRE.1993.324837","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324837","url":null,"abstract":"Requirements that involve the usability of systems can be properties of interactions rather than systems alone. This proposition is demonstrated by means of four examples. The authors suggest that a notation like CSP (communicating sequential processes) may be used to provide a framework for considering different modeling approaches. Interaction requirements that relate to multiwindowed systems, walk up and use systems, and dynamic systems such as power stations are considered. It is shown how models provide different representations to which advice from the different disciplines of human computer interaction may be applied.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116195468","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324818
P. Luff, M. Jirotka, C. Heath, D. Greatbatch
Methods for requirements elicitation have emphasized techniques for their elicitation and representation. The conception of tasks embodied in these methods is often vague or left implicit and generally characterized in individualistic terms. The authors draw from empirical materials to reveal the social and collaborative nature of task that is also overlooked in participative design or in attempts to elicit multiple viewpoints of an activity. Exploring the socio-interactional nature of activities leads to some radical implications for the technological design. An approach that utilizes ethnographic studies of real-world settings with detailed analysis of interactions of the participants may make an important contribution to the development of requirements method.<>
{"title":"Tasks and social interaction: the relevance of naturalistic analyses of conduct for requirements engineering","authors":"P. Luff, M. Jirotka, C. Heath, D. Greatbatch","doi":"10.1109/ISRE.1993.324818","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324818","url":null,"abstract":"Methods for requirements elicitation have emphasized techniques for their elicitation and representation. The conception of tasks embodied in these methods is often vague or left implicit and generally characterized in individualistic terms. The authors draw from empirical materials to reveal the social and collaborative nature of task that is also overlooked in participative design or in attempts to elicit multiple viewpoints of an activity. Exploring the socio-interactional nature of activities leads to some radical implications for the technological design. An approach that utilizes ethnographic studies of real-world settings with detailed analysis of interactions of the participants may make an important contribution to the development of requirements method.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"77 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124709639","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324852
K. Ryan
The potential role of natural language processing in the requirements engineering process has been overstated in the past, possibly due to fundamental misunderstandings of the requirements engineering process itself. Since more realistic ambitions are likely to lead to less disappointment in the future, an effort is made to identify some phases and tasks where natural language processing may usefully be applied. It is suggested that the validation of requirements must remain an informal, social process.<>
{"title":"The role of natural language in requirements engineering","authors":"K. Ryan","doi":"10.1109/ISRE.1993.324852","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324852","url":null,"abstract":"The potential role of natural language processing in the requirements engineering process has been overstated in the past, possibly due to fundamental misunderstandings of the requirements engineering process itself. Since more realistic ambitions are likely to lead to less disappointment in the future, an effort is made to identify some phases and tasks where natural language processing may usefully be applied. It is suggested that the validation of requirements must remain an informal, social process.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125762785","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324824
John S. Anderson, Brian Durney
A process is described for generating and validating specifications, together with an automated tool which supports this approach. The input to the process is a set of client objectives, expressed as transitions between states. These transitions fall into two classes: those which should be supported, and those which should be prevented. The output is a specification of a target artifact, expressed as a set of capabilities. A valid specification is a set of artifact capabilities that can be used to achieve all desired transitions but cannot be used to achieve any undesirable transitions. An automated system is used for reasoning about scenarios (sequences of actions) to generate and evaluate specifications. Scenarios are employed to identify missing capabilities that would enable artifact users to achieve their goals, and to determine whether a particular capability set will allow prohibited transitions.<>
{"title":"Using scenarios in deficiency-driven requirements engineering","authors":"John S. Anderson, Brian Durney","doi":"10.1109/ISRE.1993.324824","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324824","url":null,"abstract":"A process is described for generating and validating specifications, together with an automated tool which supports this approach. The input to the process is a set of client objectives, expressed as transitions between states. These transitions fall into two classes: those which should be supported, and those which should be prevented. The output is a specification of a target artifact, expressed as a set of capabilities. A valid specification is a set of artifact capabilities that can be used to achieve all desired transitions but cannot be used to achieve any undesirable transitions. An automated system is used for reasoning about scenarios (sequences of actions) to generate and evaluate specifications. Scenarios are employed to identify missing capabilities that would enable artifact users to achieve their goals, and to determine whether a particular capability set will allow prohibited transitions.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"20 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124902300","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 : 1993-01-04DOI: 10.1109/ISRE.1993.324825
R. Lutz
The root causes of safety-related software errors in safety-critical embedded systems are analyzed. The results show that software errors identified as potentially hazardous to the system tend to be produced by different error mechanisms than those that produce nonsafety-related software errors. Safety-related software errors are shown to arise most commonly from: discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system; and misunderstandings of the interface of the software with the rest of the system. These results are used to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems.<>
{"title":"Analyzing software requirements errors in safety-critical, embedded systems","authors":"R. Lutz","doi":"10.1109/ISRE.1993.324825","DOIUrl":"https://doi.org/10.1109/ISRE.1993.324825","url":null,"abstract":"The root causes of safety-related software errors in safety-critical embedded systems are analyzed. The results show that software errors identified as potentially hazardous to the system tend to be produced by different error mechanisms than those that produce nonsafety-related software errors. Safety-related software errors are shown to arise most commonly from: discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system; and misunderstandings of the interface of the software with the rest of the system. These results are used to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems.<<ETX>>","PeriodicalId":375368,"journal":{"name":"[1993] Proceedings of the IEEE International Symposium on Requirements Engineering","volume":"92 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1993-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131002082","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}