Software Engineering: Requirements Analysis for Customer Perspective, Study notes of Software Engineering

Download Software Engineering: Requirements Analysis for Customer Perspective and more Study notes Software Engineering in PDF only on Docsity! 1 REQUIREMENTS ANALYSIS (Customer Perspective) GA Tech CS 3300 AY 2002 Fall 2001 Chapter Learning Goals • Distinguish C- (Customer) requirements from D- (Detailed) requirements • Be equipped with ways to express C-requirements – exploit use cases – exploit state diagrams – sketch user interfaces • Be able to write first parts of a Software Requirements Specification Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. C- vs D-Requirements SRS (IEEE) 1. Introduction 2. Overall description 3. Specific requirements 4. Supporting information C- requirements D- requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel. To Be Performed With Each Requirement Each requirement must be … • expressed properly, • made easily accessible, • numbered, • accompanied by tests that verify it, • provided for in the design, • accounted for by code, • tested in isolation, • tested in concert with other requirements, and • validated by testing after the application has been built. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Typical RoadMap for Customer (“C-”) Requirements 1. Identify “the customer” -- see section 2.2 2. Interview customer representatives • identify wants and needs • exploit tools for expression (section 3.1 - 3.4) • sketch GUI’s (section 3.5) • identify hardware 3. Write C-requirements in standard document form (see case study) 4. Inspect C-requirements 5. Build D-requirements (next chapter) On customer approval ... Review with customer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. IEEE 830-1993 SRS Table of Contents 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 1.4. References 1.5. Overview 2. Overall description 2.1. Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces 2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies 2.6. Apportioning of requirements 3. Specific requirements -- see chapter four -- 4. Supporting information -- see chapter four -- tbd: get copyright permission from IEEE 2 Example Application: Encounter (1/2) • Role-playing game which simulates all or part of the lifetime of the player's character. • Game characters not under the player’s control called "foreign" characters. • Game characters have a number of qualities such as strength, speed, patience etc. • Each quality has a value • Characters "encounter" each other when in the same area, and may then "engage" each other. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Example Application: Encounter (2/2) • The result of the engagement depends on the values of their qualities and on the area in which the engagement takes place. • Player characters may reallocate their qualities, except while a foreign character is present. • Reallocation taking effect after a delay, during which the player may be forced to engage. • Success is measured … • by the "life points" maximum attained by the player - or - • by living as long as possible. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Before interview: 1. List and prioritize “customer” interviewees – most likely to determine project’s success 2. Schedule interview with fixed start and end times – at least two from development team should attend – prepare to tape? At interview: 3. Concentrate on listening Don’t be passive: probe and encourage – persist in understanding wants and exploring needs – walk through use cases, also data flow? state diagrams? Take thorough notes 4. Schedule follow-up meeting After interview: 5. Draft SRS C-requirements using a standard 6. E-mail customer for comments Handle Interviews Initialize Use Case for Encounter Encounter foreign character player designer Set rules actors Encounter Travel to adjacent area Initialize 1. System displays player’s main character in the dressing room. 2. System displays a window for setting his character's qualities. 3. Player allocates the qualities of his main character. 4. Player chooses an exit from the dressing room. 5. System moves player’s main character into the area on the other side of the exit. Initialize Use case Use case details Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engage Foreign Character Use Case player designer Initialize Use case Encounter Travel to adjacent area Set rules Engage Foreign Character 1. System displays the foreign character in the same area as the player’s. 2. System exchanges quality values between the two characters. 3. System displays the results of the engagement. 4. System displays player’s character in a random area. Engage foreign character Use case details Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Partial Encounter State-Transition Diagram Setting up Preparing Waiting Complete setup Foreign character enters area Engaging Player clicks qualities menu Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.