CMSC 735 Assignment 2 (Overview) In order to give you experience dealing with software processes, in this assignment you are asked to reason about a specific procedure for use in software development. Your team will be given a procedure intended to be used for reviewing requirements documents, and must submit a report evaluating this procedure This assignment consists of three (3) parts: Assignment 2A – (Described in more detail below) to evaluate PBR using the Observer-Executor method taught in class. This part of the assignment must be completed by class time on Wednesday, October 24. The defect list created during the inspection will be due at the beginning of class on Oct. 24. Assignment 2B – Class discussion of experiences from Assignment 2A. After the class discussion on Oct. 24, team members will switch roles and be given a new requirements document and will repeat the procedure for Assignment 2A. Assignement 2C – Team members will jointly write a report about your experiences with PBR. More details will be provided later as to the exact contents of the report. Things to keep in mind as you are observing each other include, but are not limited to: How feasible is this procedure? Can it be used for the intended purpose in a practical situation? Would it be worth using in some situations or environments? Which ones? Can it be improved? Assignment 2A (Detailed) The Procedure to be Evaluated You will be evaluating a Perspective-Based Reading (PBR) procedure. PBR is a set of procedures for detecting defects in requirements documents; your team will be assigned one procedure from the set. The PBR procedures were covered in class on Oct. 10. You will also be given a specific requirements document (a natural-language description of a particular system’s functionality) on which the PBR procedure should be applied. The "Background" and "Purpose" sections of the requirements can be assumed to be correct. Defects may be found in all other portions of the requirements document. These portions contain the detailed requirements from which the system will be designed and implemented. A defect in a requirements document is an omission, incorrect fact, inconsistency, ambiguity or anything that would lead to an unsatisfactory solution of the problem to be solved. It can fall into any of the following classes (note that the same defect could potentially be described as more than one type): Omission Necessary information about the system has been omitted from the software artifact. Ambiguous Information Some information in the software artifact contradicts information in the requirements document or the general domain knowledge. Inconsistency Information within one part of the software artifact is inconsistent with other information in the software artifact. Incorrect fact Information within the software artifact is ambiguous, i.e. any of a number of interpretations may be derived that should not be the prerogative of the developer doing the implementation. Extraneous Information is provided that is not needed or used. Miscellaneous Other defects; e.g. a requirement may be found in an inappropriate section of the document. Evaluating the Procedure In order to evaluate the procedure, you and your teammate will each be assigned distinct roles, and collect a number of different measures. Both teammates should write the report. One of you will be assigned the role of Executor, meaning that you will apply the PBR procedure with the goal of detecting defects in the given requirements document.The other team member will be the Observer. Your role is to: 1) help guide the Executor through the different steps of the PBR procedure; 2) prompt the Executor for specific feedback about the procedure at certain times; 3) take notes on the Executor’s experiences with the procedure in practice; and 4) record defects you see which the Executor misses, and add these to the end of the defect list with an indication that they were found by the Observer and not by the Executor. The notes collected by the Observer will be an important source for your evaluation of the procedure. Other sources may include: the type and quality of defects uncovered by the Executor, the Executor’s subjective opinions about the procedure, etc. How you should perform these roles, and use them to understand the procedure better, was also covered in class on Oct. 10. You will be assigned a specific role and a specific requirements document in class on Oct. 17. It is important that you follow the assignments given by the instructors. For Assignment 2A You Should Turn In: 1) The list of defects found by the Executor. A form for reporting defects will be placed on the class web page. 2) Forms A and B (you may use more than one copy of them). 3) A copy of the notes taken by the Observer. (You should keep the original notes because you will need them to write your report for Assignment 2C. The due date for these items is Oct. 24. Your grade for Assignment 2 will be based on: the quality of your final report, as determined by the instructor, and how well you conformed to the procedures that you were asked to apply (PBR and the Observer roles). Your grades will NOT depend on your specific answers, e.g. the number of faults that you report, or whether or not you found the techniques valuable. NOTE: This assignment is part of a study. As always, working with another student will be considered cheating, but for the purposes of the study it is especially crucial that you do not discuss your work with other students in the class. The motivation and design of the study will be discussed in class later this