Object Oriented Software Engineering   View all facts   Glossary   Help

subject > person or group > person > stakeholder > user > actor

actor
subject			fact

actor	has definition A role that a user or some other system plays when interacting with your system; a class of user of a system
	has goals for using the system, and a given user may have different roles from time to time
	is a subtopic of 7.3 - Developing Use Case Models of Systems
	is a kind of user
user	can learn an application quickly if it is similar to an application they already know
	can notice a single small spot of red or orange on an entire screen
	does not fear bad consequences of what he does if he can undo any action
	does not feel that the computer is in control of her time if response time is adequate
	feels that he or she has enough information to make decisions if the system informs her of what it is doing, has done and is about to do
	has a perception of acceptable response time based on the other applications she uses
	has characteristics that vary from one user to another including: goals for using the system, depending on job function or roles potential patterns of use such as how often the system is used demographics such as age knowledge of the domain and of computers physical ability psychological traits and emotional feelings
	has goal doing enjoyable or interesting work, and gaining recognition for the work they have done
	is concerned with efficiency
	is concerned with reliability
	likes software that is easy to learn and use, makes their life easier, helps them achieve more, or allows them to have fun
	makes mistakes
	may be affected by information overload
	may be frustrated when they seek help
	may fear that new software could jeopardize their job
	may judge utility^2 and usability differently from another user depending on her level of computer experience and the tasks she is performing
	may work for customer
	must be involved in the development of software
	must like a system or they will not use it, even if it has high learnability and efficiency of use
	often welcomes new or improved software
	should be able to understand everything that appears on the screen
	should be involved in all decision-making that relates to the requirements and to the user interface design and to a limited extent in requirements analysis
	should be involved in requirements analysis, user interface design and deployment, and also may play a role in design, quality assurance and project management
	should be made to feel involved in the software engineering process resulting in fewer mistakes being made and greater acceptance of the finished product
	should feel in control of the computer, not the other way around
	should give feedback on prototypes, on-line help and draft user manuals
	should not be expected to participate in detailed low-level internal design decisions
	wants software that is easy to learn
	wants software that is easy to learn, efficient to use, and which helps get work done
stakeholder	must agree on requirements

Next user: beginning user    Up: user    Previous user: user with a disability