{"title":"从需求管理工具的角度来看,自动需求规范更新处理","authors":"L. James","doi":"10.1109/ECBS.1997.581763","DOIUrl":null,"url":null,"abstract":"Most systems engineering activities initially start out with early or draft version of various customer or company specifications written in popular desktop publishing tool formats (e.g. Interleaf, Framemaker and Word). Using the more advanced requirements and traceability management (RTM) tools (which are embedded directly into these desktop publishing systems) information relevant to the project can then be \"captured\" from these documents into the tool's requirements repository for audit trail, engineering and traceability purposes. Then typically, several months later (after much systems engineering activity, requirements editing/decomposition/focusing, CASE tool modelling and through lifecycle traceability creation) updated copies of these documents are received. This then severely disrupts the flow of the project as much nugatory manual re-work has to be done in the form of change identification, impact analysis and consistency checking between the systems engineering work carried out so far in the project database and the latest information in the updated documents. The paper examines the issues involved in automatic document update processing from a requirements and traceability management tool perspective. The paper does not make any major assumptions about the reader's knowledge of any particular requirements management tool, although familiarity with general RTM operational philosophy concepts would be of benefit.","PeriodicalId":240356,"journal":{"name":"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems","volume":"66 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1997-03-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"6","resultStr":"{\"title\":\"Automatic requirements specification update processing from a requirements management tool perspective\",\"authors\":\"L. James\",\"doi\":\"10.1109/ECBS.1997.581763\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Most systems engineering activities initially start out with early or draft version of various customer or company specifications written in popular desktop publishing tool formats (e.g. Interleaf, Framemaker and Word). Using the more advanced requirements and traceability management (RTM) tools (which are embedded directly into these desktop publishing systems) information relevant to the project can then be \\\"captured\\\" from these documents into the tool's requirements repository for audit trail, engineering and traceability purposes. Then typically, several months later (after much systems engineering activity, requirements editing/decomposition/focusing, CASE tool modelling and through lifecycle traceability creation) updated copies of these documents are received. This then severely disrupts the flow of the project as much nugatory manual re-work has to be done in the form of change identification, impact analysis and consistency checking between the systems engineering work carried out so far in the project database and the latest information in the updated documents. The paper examines the issues involved in automatic document update processing from a requirements and traceability management tool perspective. The paper does not make any major assumptions about the reader's knowledge of any particular requirements management tool, although familiarity with general RTM operational philosophy concepts would be of benefit.\",\"PeriodicalId\":240356,\"journal\":{\"name\":\"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems\",\"volume\":\"66 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1997-03-24\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"6\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ECBS.1997.581763\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings International Conference and Workshop on Engineering of Computer-Based Systems","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ECBS.1997.581763","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Automatic requirements specification update processing from a requirements management tool perspective
Most systems engineering activities initially start out with early or draft version of various customer or company specifications written in popular desktop publishing tool formats (e.g. Interleaf, Framemaker and Word). Using the more advanced requirements and traceability management (RTM) tools (which are embedded directly into these desktop publishing systems) information relevant to the project can then be "captured" from these documents into the tool's requirements repository for audit trail, engineering and traceability purposes. Then typically, several months later (after much systems engineering activity, requirements editing/decomposition/focusing, CASE tool modelling and through lifecycle traceability creation) updated copies of these documents are received. This then severely disrupts the flow of the project as much nugatory manual re-work has to be done in the form of change identification, impact analysis and consistency checking between the systems engineering work carried out so far in the project database and the latest information in the updated documents. The paper examines the issues involved in automatic document update processing from a requirements and traceability management tool perspective. The paper does not make any major assumptions about the reader's knowledge of any particular requirements management tool, although familiarity with general RTM operational philosophy concepts would be of benefit.