{"title":"对软件需求的实际审查","authors":"Grigory I. Gusev","doi":"10.1109/CEE-SECR.2010.5783173","DOIUrl":null,"url":null,"abstract":"Quality of the requirements is more important than quality of any other work document of the software lifecycle. On the other hand, typical requirements quality assurance methods, such as peer review are always costly and often detect only formal and cosmetic defects. According to Luxoft experience, review is more effective when it is combined with practical validation of the requirements. The reviewers should not go through a checklist with abstract “non-ambiguity, verifiability, or feasibility,‥” criteria but should generate draft implementations of the requirements instead, to see if they can be really put into design, test cases, and user documentation. The approach improves quality and non-volatility of the requirements, decreases rework rate on the subsequent phases, and yet does not affect project budget.","PeriodicalId":187644,"journal":{"name":"2010 6th Central and Eastern European Software Engineering Conference (CEE-SECR)","volume":"591 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2010-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"2","resultStr":"{\"title\":\"Practical review of software requirements\",\"authors\":\"Grigory I. Gusev\",\"doi\":\"10.1109/CEE-SECR.2010.5783173\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Quality of the requirements is more important than quality of any other work document of the software lifecycle. On the other hand, typical requirements quality assurance methods, such as peer review are always costly and often detect only formal and cosmetic defects. According to Luxoft experience, review is more effective when it is combined with practical validation of the requirements. The reviewers should not go through a checklist with abstract “non-ambiguity, verifiability, or feasibility,‥” criteria but should generate draft implementations of the requirements instead, to see if they can be really put into design, test cases, and user documentation. The approach improves quality and non-volatility of the requirements, decreases rework rate on the subsequent phases, and yet does not affect project budget.\",\"PeriodicalId\":187644,\"journal\":{\"name\":\"2010 6th Central and Eastern European Software Engineering Conference (CEE-SECR)\",\"volume\":\"591 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2010-10-01\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"2\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2010 6th Central and Eastern European Software Engineering Conference (CEE-SECR)\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/CEE-SECR.2010.5783173\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2010 6th Central and Eastern European Software Engineering Conference (CEE-SECR)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/CEE-SECR.2010.5783173","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Quality of the requirements is more important than quality of any other work document of the software lifecycle. On the other hand, typical requirements quality assurance methods, such as peer review are always costly and often detect only formal and cosmetic defects. According to Luxoft experience, review is more effective when it is combined with practical validation of the requirements. The reviewers should not go through a checklist with abstract “non-ambiguity, verifiability, or feasibility,‥” criteria but should generate draft implementations of the requirements instead, to see if they can be really put into design, test cases, and user documentation. The approach improves quality and non-volatility of the requirements, decreases rework rate on the subsequent phases, and yet does not affect project budget.