To better understand how the librarians, go about their daily lives I would first like to
observe them. Not in a National Geographic, type of way, but I would like to shadow
a librarian to see what sections she uses the most and how easy it is for her to find
exactly what they’re looking for. Secondly, I’d like to interview the librarians one by
one, because each answer in unique. I’m not a fan of group interviews because people
usually tend to get shy about what they find difficult. Lastly, I’d like to send
questionnaires to the librarians, so that they could do it in their own time and
anonymously. Having anonymous answers has its perks because people usually tend to
be blunter. I’d record the librarians answers using user stories and use cases. When
using user stories I would create two word documents. One document will contain
positive stories and the other would state the negative stories. This will help define
what needs to be worked on first. When using Use cases, I would prefer to do them
on an excel sheet. I would do the same thing for excel sheets when it comes to
dividing them between negative or positive. The only difference would be that in the
extensions part of the use case, I would include my observations of how I see the
librarian going about that specific topic. One on one interviews with each librarian
would be a good one to use for this. There are probably few librarians on staff for this
size of a library and getting with each one to find out what functionality the program
would need and what type of automation would be needed such as automatically
tracking the person checking out the book, how long they have had it, e-mail reminders
for overdue books etc. This information could also be obtained with brainstorming, or a
focus group comprised of the librarians to discuss the programs needed functions.
During the interview I would write user stories laying out what the individual person
would want from the system being developed. This would be quick notes about what
functions they are looking for in the system and what they would want to see the
system do for them. These could be used during testing to see if the functionality the
user wants is working as they outlined. Another way to record it would be as a use
case. Explaining how they would want the system to not just track when the book was
checked out and back in, but by who, how long they had it, when it should be
returned, and including an e-mail notification system to notify if the books are overdue
and what charges are incurred. It could also have details explaining what happens to
the book when it is returned such as information on where it goes so it is put in the
correct bin to be put back on the shelves, or to contact another person if there is a
waiting list for the book. l A library's infrastructure of programs and personnel is its
most asset, providing the foundation for everything it does and aspires to do, which is
why assessment is so vitally important. Librarians use a variety of research methods to
make decisions and to improve performance. Research can be broadly defined as the
careful, systematic, patient study and investigation in some field of knowledge,
undertaken to discover or establish facts or principles. The 3 methods that I would use
when it comes to gathering information from a library are observations, interview, and
existing record reviews. When observing a library, I would watch how the librarians
work in their day-to-day activity. Watching how others work gets you a better
understanding of how librarians work and how they use the system. Next, I would
interview one of the librarians like how they are able keep track of books using the
system? Or how do you know when someone is borrowing books and when it’s
supposed to be returned? I’m sure these are the things that is an important part of
being a librarian. Lastly, I would investigate record reviews. Records that are reviewed
in research may be either public or private. An example would be researching and
collecting information about a disease from patient medical records. Researching and
collecting information based on records is another way of understanding how systems
work. You could either ask someone about it or look through records. These are ways
that can help you gather information on what you need to know and do. To record the
collected information, I would use my phone to record the interview questions I asked,
so that I can listen to it and understand how system works. Another method I would
use is by having written notes that you have jotted down in your notebook. That way
if there’s something you don’t understand you could always research online to get a
better understanding on what you don’t get.
Methods to gather information from the university's librarians.
Listen to Customers (and Users)
People develop skills in what the app does, its workings of it, and its design. Problems
to be solved quickly are often and a not clearly defined explanation that a computer
will solve the issue. Listening to the people as much as I can on what is being said
and ideas that can be implemented. Focus is key to solving the problem instead of the
solutions from the people's perspective so that the necessities are flexible.
Use the Five Ws (and One H)
People have trouble describing what needs to be done. Help them by asking the five
Ws and an H (who, what, when, where, and why) and one H (how).
Study Users
Interviews are fantastic to get information but sometimes it's not the best because
sometimes people will not give out the information that is being asked. Questions can
be hard to answer that the dev team will find important to them.
Copy Existing Systems
Replacing systems with a new one by using replacing existing ones can be of use for
the requirements. This approach is linear.
Clairvoyance
People will look at the goals, see it through, and start increasing the required parts.
Brainstorm
Using the copy and clairvoyance approach is great but its downfall is not likely to
have innovative solutions. Being creative is revolutionary!
Methods to record the information that is being gathered.
UML
User Stories
Using stories to explain what the system is doing with the user.
Use Cases
Interactivity between actors either from users or different parts of the application.
Prototypes
A mockup that allows users to see what its design feels like and its behavior from the
descriptions from stories and cases.
Requirements Specification
Writing a simple and easy-to-learn specification for the software to fill out forms.
Suppose I was to help a library to automate the 1,000 books that they have that cover
5 subjects, I can't imagine what those subjects would be. In that case, I first want to
interview with focus groups of those of different roles to determine what type of
automation they are looking for and how or who will be the author and customer of
the system itself. From there I would probably want to start brainstorming and thinking
of ways to get a basic prototype out to see what the conscious of the concept is. I
would probably give a survey to see what everyone’s thoughts is and if it's looking
good then I may go to complete the final product.
The best way I can foresee taking down the information is to keep my stakeholders
informed and show how I am progressing in finishing this project. I could also make
sure that if they think something is more important than what others are calling for,
then I can create a list that shows prioritize requirements.
In order to efficiently collect and record information in a research project which would
automate the university's library it is important to first identify the specific
requirements. I would gather requirements by means of interviews, user observations,
and use cases. This information is then used to create requirements and specification
documents for the project.
First, I would interview stakeholders in the project to get their feedback about the
project and find out what their specific requirements would be. These could include
what they want the new system to do and how they want to use it. I would also
interview end users of the system to find out about the features they think the system
should have and how they would prefer to use the system. If appropriate, I would also
interview people who have experience using the system currently to get feedback on
any problems they have encountered and how the system could be improved. This
would ensure that the new system meets the requirements of the users who will be
using it. It could also be used to make recommendations on any new features or
functionalities that would be useful to add.
I would observe the current use of the system and carry out detailed user tests on a
sample of users to find out the specific features and functions that they would like to
see in the system. 2 methods to document requirements includes Prioritizing
Requirements and Talk to the Right Stakeholders and Users. I would use the 3 methods
of 1) user observation, 2) user surveys in a workshop, and 3) brainstorming in a
workshop. I have some experience with these and had success. The user observation
would look like it sounds, visually observing the librarians at the front desk during a
work shift, noting how they are doing their work. The user surveys in a workshop
would be written questions for them to answer about how they would like the
automation to work. Lastly the brainstorming in a workshop would be gathering any
and all ideas on a large format like a white board.My two methods of recording the
information would be the written papers from the surveys and digitally capturing
(pictures) of the brain storming activities. I believe both of these would fall under the
Design Tools method. The follow-up to confirm what I captured vs. what the librarians
wanted or needs expressed will be a critical step. During the requirement gathering
process I would use a few different methods to gather information and record that
information in a way the makes requirements clear and covers everything that the
clients need.
One method I would use is Document Analysis. This method is used for examining the
existing system being used within the library and taking a look at the requirements for
that system to determine what this system was created for.
Method two would be interviewing the librarians to determine what their goals and
expectations are for the system.Method three would be Observation. I would use this
method to observe the current system being used to get a better understanding of the
system and its steps while also looking for potential points to improve. As far as the
recording methods go there are two, I would use in this case. The first one would be
the UML (Unified Model Language) because it will allow me to record the information
in a way that will show how certain parts of the system should work. It works by
creating diagrams of two categories and then breaking them down into specific types
with a set of rules. The process isn't perfect but does a good job of showing how the
system should work based on the requirements. Next, I would use user stories to record
the information. This way I can record the information from the librarians in a way
that shows how they would want to do something with the system. In order to properly
create an application for automation purposes for the university library some of the top
methods in which to gather information from the librarians are the following.
1. Interviewing. Interviewing the librarians give you the opportunity to find out what
they have in place now system-wise and also what they personally want to have
improved. By doing either group interviews or individual or both, you are able to know
first-hand what things work as they should and what doesn't work and what ways the
new application can approve the librarian's efficiency making their job easier.
2. User observation. By setting side-by-side observation, you can see firsthand the
current application and functionality of the system they have in place. This allows you
to know what steps the librarians make and what possible shortcuts or shorter processes
could allow them to automate their current process. Also allows you to see if they are
using an older legacy system or could possibly update to more current means of
storage like AWS or Microsoft Azure for cloud storage for maintenance and updates.
3. Document analysis. Document analysis allows you to see how the librarians
currently document their work and the books and if there are discrepancies with how
they are currently doing their documentation. This allows for your application when
created to take into consideration the documentation portion and allow for improvement
on ways to keep track of the books and what's owed etc.
Two ways that I would record the information would be with a Microsoft word
document and an excel spreadsheet. The word document would allow for notes to be
entered and prioritized based on categories. The excel spreadsheet will allow for the
number of books the library holds, categories, and graphs on usage along with late
turn-ins, etc.
