Re werkcollege12-02-stakeholders
•
1 like•488 views
The document discusses stakeholder analysis for requirements engineering, including identifying stakeholders based on their position, decision-making role, expertise, and objectives. It explains that stakeholder analysis is important for developing a shared understanding of the problem, ensuring requirements are complete and realistic, and facilitating cooperative learning. The document then provides an example stakeholder analysis for a bank call center software system.
Re werkcollege12-02-stakeholders
- 1. Requirements Engineering Werkcollege Spring 2012 Session 2: Stakeholders Christoph J. Stettina (stettina@liacs.nl) Enrique Larios (elarios@liacs.nl) Leiden University. The university to discover.
- 2. Session 2: Stakeholder Analysis IdenDfying Stakeholders: How? • Relevant posi-on in the organiza-on • Effec-ve role in making decisions about the system-‐to-‐be • Level of domain exper-se • Influence in system acceptance • Personal objec-ves and conflicts of interest (van Lamsweerde, 2009; p. 62) Leiden University. The university to discover.
- 3. Session 2: Stakeholder Analysis Why is it important? • Essen-al for a shared problem understanding • Complete, adequate and realis-c requirements • Coopera-ve learning (van Lamsweerde, 2009; p. 62) Leiden University. The university to discover.
- 4. Exercise 1 -‐ Stakeholder Analysis Bank Call Center Leiden University. The university to discover.
- 5. Stakeholder Analysis: Bank Call Center Scenario: Call Center -‐ Abandoned Call The call center manager has a problem with unbalanced resources and would like to support monitoring and alloca6on of agents to a specific hotline via so:ware. An external IT company has been hired to adapt / write the so:ware module and conducts a stakeholder analysis. Leiden University. The university to discover.
- 6. Stakeholder Analysis: Roleplay Bank Call Center: Roles • Customer • Agent • Supervisor • Manager • Helpdesk / IT Department Leiden University. The university to discover.
- 7. Stakeholder Analysis Sun … Who… Stakeholders expects What? Participants Expectations Leiden University. The university to discover.
- 8. Stakeholder Analysis -‐ Template INSIDE Stakeholder Objec-ves Concerns OUTSIDE Stakeholder Objec-ves Concerns Leiden University. The university to discover.
- 10. What is a use case? “A use case is a sequence of ac-ons performed by an actor” Use Case Diagram: Textual descripDon: Basic sequence of actions: 1. A student wants to register to a course 2. The student provides his name & student number to the registrar 3. The registrar verifies the student's eligibility 4. The student chooses a course from a list of available courses 5. .... 6. .... 7. .... Can be: Few sentences, few paragraphs, formal document Leiden University. The university to discover.
- 11. What is a use case? -‐ Use case types 1. EssenDal Use Case (Business Use Case) -‐ Capture the essence of problems -‐ Technology independent view of behavior req. -‐ High level of abstrac-on -‐ More flexible and resilient to changes 2. System Use Case (Concrete Use Case) -‐ A detailed analysis of behavioral requirements -‐ Describing how the system works Leiden University. The university to discover.
- 12. EssenDal in creaDng UC diagrams 1. IdenDfying Actors -‐ People, external systems, other organiza-ons -‐ Actors are always external to the system 2. IdenDfying use cases -‐ Actors' main tasks (things they try to achieve)? -‐ Actors' input to the system? -‐ Actors' needs from the system (e.g., informa-on)? Leiden University. The university to discover.
- 13. Example: Course Management Leiden University. The university to discover.
- 14. Example: Library System Leiden University. The university to discover.
- 15. Use Case Diagram: In-‐class assignment Bank Call Center Roles to consider • Customer, Agent, Call Center Supervisor, CC Manager, Helpdesk / IT Department Use cases to consider 1. Checking Account Balance 2. Checking Last Transac-ons Leiden University. The university to discover.
- 16. Use Case Diagram: In-‐class assignment 1. Iden-fy the solu-on. 1. Elicit, analyze, nego-ate the requirements. 1. Make a use case diagram to get an overview of the solu-on. Leiden University. The university to discover.
- 17. Bibliography • Brooks, F. (1995) Mythical man-‐month: essays on so`ware engineering, 20th anniversary edi-on. Addison-‐Wesley Professional. Gause, D., and G. Weinberg. 1989. Exploring requirements, quality before design. New York: Dorset House Publishing. • Fowler, M. (2004) UML Dis-lled: A Brief Guide to the Standard Object Modeling Language (3rd ed. ed.). Addison-‐ Wesley • van Lamsweerde, A. (2009) Requirements Engineering: From System Goals to UML Models to So`ware Specifica-ons. Wiley, March 2009. Leiden University. The university to discover.