{"title":"需求学徒:一个初始场景","authors":"H. Reubenstein, R. Waters","doi":"10.1145/75199.75231","DOIUrl":null,"url":null,"abstract":"The implementation of the Requirements Apprentice has reached the point where it is possible to exhibit a concrete scenario showing the intended basic capabilities of the system. The Requirements Apprentice accepts ambiguous, incomplete, and inconsistent input from a requirements analyst and assists the analyst in creating and validating a coherent requirements description. This processing is supported by a general-purpose reasoning system and a library of requirements cliches that contains reusable descriptions of standard concepts used in requirements. 1 The Requirements Apprentice The philosophy underlying the Requirements Apprentice (RA) is laid out in detail in [14]. In the interest of brevity, this discussion will not be repeated here. However, it is important to keep in mind the position occupied by the RA in the requirements acquisition process. As illustrated by Figure 1, the RA is intended to assist a requirements analyst. The analyst begins the requirements acquisition process by means of a “skull session” that illicits an informal idea of what. is wanted. A good example of the result of such a skull session is the library database requirement sketch [l] that was used as a benchmark by previous Workshops on Software Specification and Design. Starting from such an informal requirements sketch, the RA aLsist.s an analyst (and through the analyst, the end user) t.o arrive at a more complete and more formal requirement. In I his, the RA continues in the tradition of the SAFE project ]2] and differs from most current work on software requirements tools (e.g., [4, 7, 111) that focuses instead on the validation of a requirement that is already stated in a formal way. Viewed from an artificial intelligence perspective, the problem faced by the RA is essentially one of knowledge acqrhitim. Related systems in this area include KLATJS[.lO] and ROGET[5], which provide automated assistance for arquiring new rules for expert systems. These tools support Pernksion to copy without fee all or pert of this material is granted provided that the copies arc not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy othc&se, or to republish, requires a fee and/or specific permission. l D Analyst + Requirements Knowledge Base","PeriodicalId":435917,"journal":{"name":"International Workshop on Software Specification and Design","volume":"75 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1989-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"41","resultStr":"{\"title\":\"The requirements apprentice: an initial scenario\",\"authors\":\"H. Reubenstein, R. Waters\",\"doi\":\"10.1145/75199.75231\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"The implementation of the Requirements Apprentice has reached the point where it is possible to exhibit a concrete scenario showing the intended basic capabilities of the system. The Requirements Apprentice accepts ambiguous, incomplete, and inconsistent input from a requirements analyst and assists the analyst in creating and validating a coherent requirements description. This processing is supported by a general-purpose reasoning system and a library of requirements cliches that contains reusable descriptions of standard concepts used in requirements. 1 The Requirements Apprentice The philosophy underlying the Requirements Apprentice (RA) is laid out in detail in [14]. In the interest of brevity, this discussion will not be repeated here. However, it is important to keep in mind the position occupied by the RA in the requirements acquisition process. As illustrated by Figure 1, the RA is intended to assist a requirements analyst. The analyst begins the requirements acquisition process by means of a “skull session” that illicits an informal idea of what. is wanted. A good example of the result of such a skull session is the library database requirement sketch [l] that was used as a benchmark by previous Workshops on Software Specification and Design. Starting from such an informal requirements sketch, the RA aLsist.s an analyst (and through the analyst, the end user) t.o arrive at a more complete and more formal requirement. In I his, the RA continues in the tradition of the SAFE project ]2] and differs from most current work on software requirements tools (e.g., [4, 7, 111) that focuses instead on the validation of a requirement that is already stated in a formal way. Viewed from an artificial intelligence perspective, the problem faced by the RA is essentially one of knowledge acqrhitim. Related systems in this area include KLATJS[.lO] and ROGET[5], which provide automated assistance for arquiring new rules for expert systems. These tools support Pernksion to copy without fee all or pert of this material is granted provided that the copies arc not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy othc&se, or to republish, requires a fee and/or specific permission. l D Analyst + Requirements Knowledge Base\",\"PeriodicalId\":435917,\"journal\":{\"name\":\"International Workshop on Software Specification and Design\",\"volume\":\"75 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1989-04-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"41\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"International Workshop on Software Specification and Design\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/75199.75231\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"International Workshop on Software Specification and Design","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/75199.75231","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
The implementation of the Requirements Apprentice has reached the point where it is possible to exhibit a concrete scenario showing the intended basic capabilities of the system. The Requirements Apprentice accepts ambiguous, incomplete, and inconsistent input from a requirements analyst and assists the analyst in creating and validating a coherent requirements description. This processing is supported by a general-purpose reasoning system and a library of requirements cliches that contains reusable descriptions of standard concepts used in requirements. 1 The Requirements Apprentice The philosophy underlying the Requirements Apprentice (RA) is laid out in detail in [14]. In the interest of brevity, this discussion will not be repeated here. However, it is important to keep in mind the position occupied by the RA in the requirements acquisition process. As illustrated by Figure 1, the RA is intended to assist a requirements analyst. The analyst begins the requirements acquisition process by means of a “skull session” that illicits an informal idea of what. is wanted. A good example of the result of such a skull session is the library database requirement sketch [l] that was used as a benchmark by previous Workshops on Software Specification and Design. Starting from such an informal requirements sketch, the RA aLsist.s an analyst (and through the analyst, the end user) t.o arrive at a more complete and more formal requirement. In I his, the RA continues in the tradition of the SAFE project ]2] and differs from most current work on software requirements tools (e.g., [4, 7, 111) that focuses instead on the validation of a requirement that is already stated in a formal way. Viewed from an artificial intelligence perspective, the problem faced by the RA is essentially one of knowledge acqrhitim. Related systems in this area include KLATJS[.lO] and ROGET[5], which provide automated assistance for arquiring new rules for expert systems. These tools support Pernksion to copy without fee all or pert of this material is granted provided that the copies arc not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy othc&se, or to republish, requires a fee and/or specific permission. l D Analyst + Requirements Knowledge Base