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. f 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.
