{"title":"使用非功能需求系统地支持变更","authors":"L. Chung, B. Nixon, E. Yu","doi":"10.1109/ISRE.1995.512554","DOIUrl":null,"url":null,"abstract":"Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR-framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design tradeoffs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms: of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank.","PeriodicalId":354711,"journal":{"name":"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","volume":"75 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"1995-03-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"99","resultStr":"{\"title\":\"Using non-functional requirements to systematically support change\",\"authors\":\"L. Chung, B. Nixon, E. Yu\",\"doi\":\"10.1109/ISRE.1995.512554\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR-framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design tradeoffs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms: of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank.\",\"PeriodicalId\":354711,\"journal\":{\"name\":\"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)\",\"volume\":\"75 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"1995-03-27\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"99\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/ISRE.1995.512554\",\"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 of 1995 IEEE International Symposium on Requirements Engineering (RE'95)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ISRE.1995.512554","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Using non-functional requirements to systematically support change
Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR-framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design tradeoffs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms: of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank.