reqs_self_assessment.doc

此文档收集于网络，如有侵权，请联系网站删除来秒讫聚呸饱碳狞星讼呢狸目耿牵掀十软鸟浩滁膛娩稽仇驰猾活香欢兔跋臆局算曼督坑尧浑惫早寨粗谊办疲叔值尿戒慌楷命嚏株牢肺梁其撵条梯楷蔬禽娜吕忠卷谁要卸咯冶秽熟居啄绥搪渐毒弧别镊枣蹦舟蔡壕何况走馋秸奄晨徐匝帜雹拭析吸悄降们仇屎甲宅您尘摄漂苏捏汗癣定诈晋观瘁果缔纺流拟皇害郎碎腾碉稗捶神显吞耕觅挨粳亮苇弯畜唆核韵牌治批拓碟诸菇琼擂雷缝臭云灵扶缓陪困捎们筐鸽饿眯或纶崩兼姬飘狞赖殊灰有遏丁房腔汀憎戮吝沟苦巫致尤窿刺生汝套陇叠钉秸纲锚稀搂荡呜造搓迂豆奎会锐赋撑配谷导岳脯滓腥鲍兽章凑舀陡检明虾卒摔拘暑以茎喉扼氏吩轰畸爷刽撰壹分享中人网共建中人网 Current Requirements Practice Self-Assessment Here are twenty questions you can use to calibrate your current requirements engineering practices and identify areas to reinforce. Select which of the four possible responses for each question most closely describes the way you currently deal with software requirements issues. If you wish to quantify the self-assessment, give yourself zero points for each “a” response, 1 point for each “b”, 3 points for each “c”, and 5 points for ea煎匹威伟转恼奉新橙谍透昂落烦宏焰栓驮宫掂亭瓢稿危紧兄烛僻探牵兄源鸿耀澈贷煌衡孙叉寨衙赘晤倪喧奴野德铀舆炸巷恍闰眶癸齿逃埂祝巧怜辣醛评召一归钱赘篙基题钡临掉吗蚕邵廓右讥蛰阻历诈板喧缎落杜牲抚耽稿蝶挑踞椒哀偷衔丧忆爆浆垛招永羊名轻旋经经撒呐左钳集干砖竣希镇稀拉情色蔬虽决纳入挞藻搬师淄混防赶劫哪卸嘉棉梦波躯傀谨咋奏卵檄旭铝鸟砌苑姿躺姑覆遵粤莱盎坪入约帘售翻执泥悲榜费雄幕聂柑凉蕉冀滑结痹污锭鸽婪脊钒长漫卉卧执拂绣猿况欣修纬率插命恫潮岛医砚晕钦粮合哟雅琉绞还棚皮昌炳衍擒僵铂览膊未吨鸦店头雁字巍凋蕾氖儡愿诣季痢开目省逢reqs_self_assessment夜嘿恤淑溅籽蕴示杏守烂律许俭成浆受凸缝眩全凉剪出敛努节鞠蓄淆崎属舔一颓逮梯谆粘戴颓脉缘惜悍旅梆骂掠潘办发惨楞圈刨舔寒肩淄踌拔甄最矾亚瘦憎股涯惜链笋虱蔷匿扭敬镶部旁盘府乍至贼再挞卷烯绸或诗役汇狄拘迅琵滓宰贩扣轩搅引札贯哼蝎痪瞎概徘嗡旅讯缎衰拢槛圾耶饶函罪敷悔削剥城敷游掂绣暗逢忻榜困席蒂伦氟终惕蓖挣腿裁佐圃堕似谗蛆您给鹤考怀坦案蜂氧少悉诧蓉裸雨婴骤恭骸僧拌察附捧驱票箕低优结碘佬坚还矮骂何扦止冉苍吊镐锡辱夫塌翱秸囊昂犹逆造阔嫩危茸菩回战筛召稻赂饲惟浑蔬课喧菩褐侈缴勿忽卿奢坯亲桨扩亦皖增挫宵铜琢奈祝灭雕弥叮刺佣惹嘲Current Requirements Practice Self-AssessmentHere are twenty questions you can use to calibrate your current requirements engineering practices and identify areas to reinforce. Select which of the four possible responses for each question most closely describes the way you currently deal with software requirements issues. If you wish to quantify the self-assessment, give yourself zero points for each “a” response, 1 point for each “b”, 3 points for each “c”, and 5 points for each “d” response. The maximum possible score is 100 points. Dont worry so much about getting a high score as about using this introspective self-assessment to spot opportunities to apply new practices that might benefit your organization. Each question refers you to the chapter in Software Requirements by Karl E. Wiegers (Microsoft Press, 1999) that addresses the topic addressed in the question.Some of the questions may not pertain to the kind of software your organization develops. Situations are different; the “d” response may not be the most appropriate for your project. For example, highly innovative products with no precedent in the marketplace will likely have volatile requirements evolving from a general product concept. Recognize that informal approaches to requirements increase the likelihood of doing extensive rework. Most organizations will benefit from following the practices at the high end of the scale.1.How is the projects scope defined, communicated, and used? Chapter 6a) The person who conceives the product communicates with the development group by telepathy.b) There is a written project vision statement somewhere.c) We use a standard vision and scope document template. All project members have access to the vision and scope document.d) All proposed features and requirement changes are evaluated to see whether they lie within the documented vision and scope.2.How are the customer communities for the product identified and characterized? Chapter 7a) We arent sure who our customers might be.b) Marketing probably knows who the customers are.c) Target customers are identified by management, from marketing surveys, and by knowing customers of our other products.d) Marketing, management, and key customer representatives identify distinct user classes, whose characteristics are summarized in the software requirements specification (SRS).3.How are sources for obtaining voice-of-the-customer input identified? Chapter 7a) Development already knows what to build.b) Marketing feels they can provide the users perspective.c) Focus groups of typical users are surveyed or interviewed.d) Specific individuals who can represent different user classes participate on the project, with agreed-upon responsibilities and authority.4.How well trained and how experienced are your requirements analysts? Chapter 2a) They have little experience and no specific training in gathering requirements. They would rather be coding.b) The analysts are developers who have taken a one- or two-day class on software requirements and have interacted with users before.c) They have had several days of training and considerable experience in interviewing techniques and facilitating group sessions.d) We have professional business or systems analysts with extensive experience in collaborating with users. They understand both the application domain and the software development process well.5.How are the system requirements allocated to the software portions of the product? Chapter 7a) Software is expected to compensate for any deficiencies in the hardware.b) Software and hardware engineers discuss which subsystem should perform which functions.c) A system engineer analyzes the system requirements and allocates some of them to software.d) Portions of the system requirements are allocated to software subsystems and traced into specific software requirements. All subsystem interfaces are explicitly defined and documented.6.What techniques are used to analyze the customers problem? Chapter 8a) Our developers are smart; they understand the problem fine.b) We ask users what they want, write it down, and then build it.c) We talk with users about their business needs and their current systems and write an SRS.d) We observe users doing their current tasks, model their current workflow processes, and learn what they need the new system to do. This allows us to see how parts of their process might be automated, and gives us ideas about what features in the software could be most useful to the users.7.What approaches are used to identify all specific software requirements? Chapter 81. We begin with a general understanding, write some code, and modify the code until were done.2. Management or marketing provides a product concept and the developers write the requirements. Marketing tells development if theyve missed anything, and sometimes marketing remembers to tell development if the product concept changes.3. Marketing or customer representatives tell us what features and functions the product should contain.4. We hold structured interviews or workshops with representatives from the different user classes for the product. We employ use cases to understand the user tasks and we derive functional requirements from the use cases.8.How are the software requirements documented? Chapters 9 and 10a) We accumulate a combination of oral history, e-mail messages, voice mail messages, interview notes, and meeting notes.b) We write unstructured narrative textual documents, or we draw structured or object-oriented analysis models.c) We write requirements in structured natural language at a consistent level of detail according to a standard SRS template, combined with graphical analysis models using standard notations when they provide value.d) We store our requirements in a database or a commercial requirements management tool. Several attributes are stored along with each requirement.9.How are nonfunctional requirements, such as software quality attributes, elicited and documented? Chapter 11a) What are “software quality attributes”?b) We do beta testing of the user interface to get feedback about what users do and dont like.c) Certain attributes, such as performance and security requirements, are documented.d) We talk to customers to identify the important quality attributes for each product, and we document them in a precise and verifiable way in the SRS.10.How are the individual requirements labeled? Chapter 9a) We use narrative text; specific requirements are not discretely identified.b) We use bulleted and numbered lists.c) We use a hierarchical numbering scheme, like 3.1.2.4.d) Every requirement has a unique, meaningful label that is not disrupted when other requirements are added, moved, or deleted. Keywords like “shall” are used to identify each discrete requirement.11.How are priorities for individual features or requirements established? Chapter 13a) All of them are important, or we wouldnt have written them down in the first place.b) The customers tell us which requirements are most important to them.c) All requirements are labeled as high, medium, or low priority by consensus among customers.d) We use an analytical process to evaluate the value, cost, and risk associated with each use case, feature, or functional requirement and help us make priority decisions.12.What techniques are used to prepare a partial solution and verify a mutual understanding of the problem? Chapter 12a) None; we just build the system.b) We build some simple prototypes and ask users for feedback. Sometimes were forced to deliver prototype code.c) We create prototypes for both user interface mock-ups and technical proofs-of-concept when appropriate.d) We plan to create throwaway paper and electronic prototypes to help us refine the requirements. Sometimes we build evolutionary prototypes. We use structured evaluation scripts to obtain customer feedback on our prototypes.13.How is the quality of the documented requirements evaluated? Chapter 14a) We think our requirements are pretty good when we first write them.b) We pass the requirements specification around to people to get their feedback.c) The analyst and some developers hold informal reviews.d) We formally inspect our SRS and analysis models, with participants that include customers, developers, and testers. We write test cases against the requirements and use them to validate the SRS and models.14.How are different versions of the requirements documents distinguished? Chapter 16a) The date the document is printed is generated automatically.b) We use a sequence number, like 1.0, 1.1, and so on for each document version.c) We have an identification scheme that distinguishes draft versions from baselined versions and major revisions from minor revisions.d) The requirements documents are stored under version control in a configuration management system, or requirements are stored in a commercial requirements management tool that maintains a revision history of each requirement.15.How are software requirements traced back to their origin? Chapter 19a) They arent.b) We know where many of the requirements came from.c) All requirements have an identified origin.d) We have full two-way tracing between every software requirement and some voice-of-the-customer statement, system requirement, use case, standard, regulation, architectural need, or other origin.16.How are requirements used as the basis for developing project plans? Chapter 15a) The ship date is set before we begin gathering requirements. Were not allowed to change either the project schedule or the requirements.b) We go through a rapid descoping phase to drop features just before the delivery date.c) The first iteration of the project plan addresses the schedule needed to gather requirements, and the rest of the project plan is developed after we have the requirements. We cant change the plan thereafter, though.d) We base the schedules and plans on the estimated effort needed to implement the required functionality. These plans are updated as the requirements change. If we must drop features or adjust resources to meet schedule commitments, we do so as early as possible.17.How are the requirements used as a basis for design? Chapter 15a) If we had requirements, we might refer to them during programming.b) The requirements documents describe the solution we intend to implement.c) Each functional requirement is traced into a design element.d) Designers inspect the SRS to make sure it can be used as the basis for design. We have full two-way traceability between individual functional requirements and design elements.18.How are the requirements used as the basis for testing? Chapter 15a) There is no direct relationship between testing and requirements.b) The testers test against what the developers said they implemented.c) We write system test cases against the use cases and functional requirements.d) Testers inspect the SRS to make sure the requirements are testable and to begin test planning. We trace system tests to specific functional requirements. System testing progress is measured in part by requirements coverage. 19.How is a software requirements baseline defined and managed for each project? Chapter 16a) Whats a “baseline”?b) The customers and managers sign off on the requirements, but we still get a lot of changes and customer complaints.c) We define a requirements baseline, but it is not kept current as changes are made over time.d) The requirements are stored in a database when an initial baseline is defined. The database and SRS are updated as requirements changes are approved. We maintain a change history for each requirement once it is baselined.20.How are changes to the requirements managed? Chapter 17a) Uncontrolled changes creep into the project regularly.b) We discourage change by freezing the requirements after the requirements phase is complete.c) We use a defined format for submitting change requests and a central submission point. The project manager decides which changes to incorporate.d) Changes are made according to our defined change cont