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