CS211 Lecture: Requirements Engineeringlast revised August 15, 2008Objectives:1. To understand the importance of Requirements Analysis in the overall software development process2. To understand the distinction between functional and non-functional requirementsMaterials: 1. Projectable of book figures 2-4, 2-52. Projectable of book figure 2-6.I. IntroductionA. As we pointed out at the start of the course, there are many different processes that can be followed in software development (e.g. waterfall life cycle, RUP, etc).B. Regardless of what process is followed, however, certain tasks will need to be done as part of the development process per se - whether all at once, iteratively, or incrementally. In fact, activities like these will be part of any situation in which one uses his/her professional skills to help solve someone else’s problem - not just when creating software or even in a computer field.1. Establishing Requirements: The goal of this is to spell out what constitutes a satisfactory solution to the problem.2. Analysis. The goal of this is to understand the problem. The key question is “What?”.3. Design. The goal of this is to develop the overall structure of a solution to the problem in terms of individual, buildable components and their relationships to one another. The key question is “How?”.4. Implementation. The goal of this task is to actually build the system as designed.5. Installation / Maintenance / RetirementAll of these must be done in a context of commitment to Quality Assurance - ensuring that the individual components and the system as a whole do what they are supposed to do (which may involve identifying their shortcomings and fixing them.)1C. Today’s focus is the first of these: establishing requirements - sometimes called requirements engineering. The question that is answered is “how will I know that I have found a satisfactory solution to the problem - i.e. what must characterize an acceptable solution? Though we will discuss the specific context of software development, establishing requirements is part of any design process.Example: Gordon recently built a new science building. The design of the building was based on input garnered from science division faculty and others affected by the building (e.g. the registrar had some input regarding classroom space). A suitable building would have to incorporate space for various purposes.Example: Gordon recently adopted a revised core curriculum. One of the early steps in the process was asking the question “what should a student who has completed the core know and be able to do?” A suitable core would have to develop certain knowledge and skills.D. What were the specific stages of requirements engineering the book discussed? (This is Quick Check Question a) What is the purpose of each stage?ASK1. Requirements elicitation - gathering information2. Requirements specification - putting the information into an ordered form3. Requrements validation - checking to be sure the requirements are consistent and complete 2II. Requirements ElicitationA. Since the book discussed this extensively, we will spend only limited time on it. What were some of the requirements elicitation techniques the book discussed?ASK1. Interviews with key people. Who might this include? (Think back to the notion of a stakeholder)a) Potential users of the systemb) The client2. Questionairres3. Studying documents4. Observing the existing system (if there is one)B. Quick-Check Questions / Exercises1. What documents should be produced by the developer before and after an interview with a client or user of the system? (QC b)ASKa) Interview planb) An interview summary (reviewed with interviewee)2. When are questionairres useful? (QC c)ASK3. What is a scenario? (QC d)ASKa) Examples in the book - figure 2-4, 2-5 (pages 30, 31)PROJECTb) Scenarios serve as a bridge to the development of use cases - our next major topic4. [ As time permits ] Exercises 2.1-2.2 (do as one exercise) p. 375. [ As time permits ] Exercise 2.5 p. 383III. Requirements SpecificationA. Having gathered general information about a particular project, it is important to document the information.B. Sometimes, this is done fairly informally.1. This may take the form of a simple statement of the problem that is to be solved - a problem definition. (This is true for any problem solving process - not just with regard to software).Example: For the “Wheels” case study in the book, a problem definition appears as figure 2.6 (page 32) in the book. PROJECTNote: often, it is helpful to see if one can capture the gist of such a statement in 1-2 sentences. Exercise: do this for the “Wheels” system.2. Quick check question e: What are the typical sections of a problem definition?ASKcf figure 2.6 on page 32C. Sometimes, a specification is more formal.1. In contract projects, the requirements specification document often becomes explicitly or implicitly a part of the formal contract between the developer and the client - i.e. the developer gets paid for developing a system that fulfills the specifications.2. As part of a formal specification of requirements, it is common to give each requirement a number. This is done to facilitate traceability: i.e. checking that no requirements are inadvertently lost sight of during development, and that capabilities which are not required do not inadvertently creep into the system.4D. Whether specifications are informal or formal, one issue that needs to be made very clear at this point is the scope of the system - i.e. what is part of the system and what is not? (Again, this is part of identifying requirements in general, not just with regard to software).Example: the Video Store project you are working on this semester does deal with keeping track of DVD’s and games owned by the store, but does not deal with paying the store’s employees. That is, DVD/game inventory is part of the scope of the system, but employee payroll is not.Example: the new Science Building includes some classroom space in addition to office and laboratory space for the sciences; but it does not include administration office space (though such space is needed). That is, science faculty office space, laboratories, and classroom space are part of the scope of the project; adminstration office space is not.1. Often, identifying the scope for a system can be done by listing all the sorts of things the system might do, then