In my last post on business analysis, I described user stories and gave a comparison between user stories and use cases. In my today's post, I am going to describe use cases.
A use case (a case in the use of a system) is a list of steps, typically defining interactions between a role known as an "actor" and a system to achieve a goal. The actor can be a human or an external system.
There is no standard way to write a use case, and different formats work well in different cases. There are few templates to use for a use case.
Content management initiative starts with the analysis of the current situation and coming up with a solution and the strategy for this solution. This process is called business analysis. Business analysis can be defined as the discipline of identifying business needs and determining solutions to business problems.
The usual problem in content management arena is that employees spend a lot of time searching for information, re-creating information and while they are doing it, they are not being efficient and productive, and so the company looses money. Employees also use obsolete documents in their work and so the integrity of work and compliance is at risk.
How is this problem solved? By implementing a content management initiative. The first step of it is business analysis. It involves requirements gathering and development process. During this process you identify the specific needs of the business and then develop and implement the solutions to meet them. This could be for example a new content management system deployment, modification of a current content management system, integrating few content management systems, designing a search solution, etc.
In my last post on business analysis in content management, I mentioned that methods used in business analysis are: focus groups, documentation analysis, surveys, user task analysis, process mapping, stakeholders interviews, use cases, user stories, personas, storyboards, etc. In my today's post, I am going to describe user story method.
A user story is a short, simple description of a feature told from the perspective of the person who desires the new system capabilities, usually a user or a customer of the system. It is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions.
User stories are used with Agile software development methodologies as the basis for defining the functions that a business system must provide. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for a business user as that user's primary way to influence the functionality of the system being developed.
You have decided to implement a content management or a document control system. This system that you are planning to deploy is for users. Everything you create is for users. If your system meets your users' requirements, they will use it. If your system does not meet your users' requirements, they are not going to use it.
They are the ultimate designers. Design a system that confuses users and they will go somewhere else. Build the system that frustrates users and they will not use it. No matter what you do, they will find all possible excuses of why they cannot and should not use your system. Users adoption is going to be very difficult, almost impossible if you deploy a system which is not based on your users' requirements.
But who are your users? Why are they looking for information? What information are they looking for? How are they looking for information? How would they like to search for information? How would like to author this information? How would they like to use your system? and similar questions - these questions you should ask your users before you deploy any system. You ask these and similar questions during user study which should be done at the beginning of your project. This is the subject of my today's post.
