Object Oriented Software Engineering   View all facts   Glossary   Help
subject > person or group > person > stakeholder > user > actor
Next userbeginning user    Upuser    Previous useruser with a disability   

actor
subjectfact 
actorhas definition A role that a user or some other system plays when interacting with your system; a class of user of a system2001-08-30 14:54:28.0
has goals for using the system, and a given user may have different roles from time to time2001-08-30 14:54:28.0
is a subtopic of 7.3 - Developing Use Case Models of Systems2001-08-30 14:54:28.0
is a kind of user2001-08-30 14:54:28.0
usercan learn an application quickly if it is similar to an application they already know2001-08-30 14:58:15.0
can notice a single small spot of red or orange on an entire screen2001-08-30 14:58:15.0
does not fear bad consequences of what he does if he can undo any action2001-08-30 14:58:15.0
does not feel that the computer is in control of her time if response time is adequate2001-08-30 14:58:15.0
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 do2001-08-30 14:58:15.0
has a perception of acceptable response time based on the other applications she uses2001-08-30 14:58:15.0
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
2001-08-30 14:58:15.0
has goal doing enjoyable or interesting work, and gaining recognition for the work they have done2001-08-30 14:58:15.0
is concerned with efficiency2001-08-30 14:58:15.0
is concerned with reliability2001-08-30 14:58:15.0
likes software that is easy to learn and use, makes their life easier, helps them achieve more, or allows them to have fun2001-08-30 14:58:15.0
makes mistakes2001-08-30 14:58:15.0
may be affected by information overload2001-08-30 14:58:15.0
may be frustrated when they seek help2001-08-30 14:58:15.0
may fear that new software could jeopardize their job2001-08-30 14:58:15.0
may judge utility^2 and usability differently from another user depending on her level of computer experience and the tasks she is performing2001-08-30 14:58:15.0
may work for customer2001-08-30 14:58:15.0
must be involved in the development of software2001-08-30 14:58:15.0
must like a system or they will not use it, even if it has high learnability and efficiency of use2001-08-30 14:58:15.0
often welcomes new or improved software2001-08-30 14:58:15.0
should be able to understand everything that appears on the screen2001-08-30 14:58:15.0
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 analysis2001-08-30 14:58:15.0
should be involved in requirements analysis, user interface design and deployment, and also may play a role in design, quality assurance and project management2001-08-30 14:58:15.0
should be made to feel involved in the software engineering process resulting in fewer mistakes being made and greater acceptance of the finished product2001-08-30 14:58:15.0
should feel in control of the computer, not the other way around2001-08-30 14:58:15.0
should give feedback on prototypes, on-line help and draft user manuals2001-08-30 14:58:15.0
should not be expected to participate in detailed low-level internal design decisions2001-08-30 14:58:15.0
wants software that is easy to learn2001-08-30 14:58:15.0
wants software that is easy to learn, efficient to use, and which helps get work done2001-08-30 14:58:15.0
stakeholdermust agree on requirements2001-08-30 14:57:46.0

Next userbeginning user    Upuser    Previous useruser with a disability