200 likes | 215 Views
Learn to identify stakeholders, business areas, and use cases. Develop actor/activity tables for requirements gathering and defining system boundaries.
E N D
SYS366 Week 8 Lecture 1: Identifying Actors and Activities
Where are we? • Identified Stakeholder categories/types • Identified business areas & basic processes • Completed interviews with stakeholder rep. • Identified Business Use Cases • Built a Business Use Case Diagram • Wrote Business Use Case Descriptions • NEXT: Create Actor/Activity Tables from Business Use Case Descriptions
Identifying Actors and Activities • Requirements Gathering • find out, in detail, what stakeholders require to achieve their goals • Allows the Analyst to clearly understand users’ requirements • Need to describe the interaction between users of the system and the system itself • Describes what the system is to do, not how it is going to do it
Requirements Analysis: Steps 1. Identify actors vs stakeholders 2. Identify business processes 3. Define the system boundaries
Stakeholders vs. Actors • A stakeholder is someone who has an interest in the system being developed they may not actually use the system but they may be paying for the development of that system, they may receive the benefits of that system
Actors • An actor represents anything that interacts with the system humans, devices, other systems, etc • Actors are not part of the system. They are outside of the system boundary but are visible to the system • Can make a service request of the system (initiating system activity) • Can be requested to provide a service (responds to a request initiated by the system)
System Behavior SystemBoundary
Actors • User • Somebody who maintains the data, uses the data or generates reports • Applications • External processes or software systems (email interface, DB repository) • Devices • External sensors (e.g. swipe reader may init security check & authorization) • Time Events • System clock, schedule nightly backup
Actors • To Identify: • actors that initiate activity on the system • Who uses the system? • What other systems use this system? • Who provides information to this system? • Does anything happen automatically? • non-initiating actors • Who gets information from this system? • What other systems does this system use? • Who is asked to provide additional information to this system to complete an action?
UML Notation • Actors are represented in UML by a ‘stick’ person “I am an actor. I play a rolethat involves using the system. I amoutside of the system.” “My name indicates my role.” OrderClerk “I can be a person, a department,a system, hardware, scheduler, and so on”.
Actors • An actor is NOT an object. (An object is inside the system.) • However, an object might store information about an actor. For instance: • Actor is Customer • Class is Customer Information • Object in the class stores information about a particular customer
Business Processes:System Behavior • An activity the system does to achieve its purpose • Purpose: satisfy an actor’s goal • Happens only inside the system boundary
System Behavior SystemBoundary
Business Processes: System Behavior • Identifying Activities: • Ask the following questions: • What initial activity starts the process? • What processes achieve some business goal? • What are the different processes that are used? • What is the activity starts a series of interactions in the system? • Use ActionObject nomenclature to name the activity, e.g. RentCar
Actor/Activity Tables • Used to document the behavior of a system • Includes: • The person who initiates the activity (the actor) • other actors • The activities
Actor/Activity Tables • Sample Actor/Activity table:
Actor/Activity Table - example • RegisterRallyParticipationAAT.doc
OVER TO YOU • Write up the other 5 Actor Activity Tables for the Car Rally
Actor/Activity Table - example • ConsignGoodsAAT.doc
OVER TO YOU • Write up the other 5 Actor Activity Tables for Holly’s House