In the specific context, a wide range of methods can be used for a plan to gather
information from the university’s librarians. One method is the use of interviews so
that the librarian can be asked relevant questions. Another method to collect data
involves the use of a questionnaire. It can contain insightful questions that can help
to capture relevant details from the librarians. The final method that can be used is
documentation reviews. It can provide anin-depth insight into the current activities
and the expectations that the librarians have from the new automated system
(Overview and information gathering tools: Literacy basics, 2021).Out of the viable
methods, the two most feasible and effective methods are personal interview and
questionnaire. The personal interview is suitable since it can helpto engage with the
librarians and get a thorough idea of what they want the new automated system to
simplify for them. The use of a questionnaire can give anobjective insight into their
input. It can help to devise a concrete blue print on which the new automated
system will be based upon. These methods can simplify the data-garnering process
and influence the quality of the automated system that can be introduced in the
library, which contains 1000 books on diverse subjects. At a university’s library, the
circulation desk is where patrons come for assistance, so three methods I would use
to gather the information would include:
• Requesting information from librarians for background knowledge of the
services provided by the circulation desk. This information will allow me to
do an analysis of how the tasks are being delegated or handled, as well as
the procedures settings at the circulation desk.
• Observing the activities of patrons and librarian at the circulation desks.
Using observation, I can gather the volume and frequency of tasks/ activities
at the circulation desk. This will be helpful to categorize / prioritize the
interface /GUI design.
• Interviewing librarians and patrons for the needs of automation tasks. Each
patron that comes to the library might have different needs – from checkout,
return, pickup holds, pay fines, etc. so the services provided by the librarians
are vary for each patron. There are activities that can be completely
automated (i.e., self-checkout, extend loan time, pay fines), some activities
can be partially automated (pickup holds or request inter-library holds). So,
interviewing both librarians and patrons will help collect users’ expectations
and design of the automation system.
The two methods I think would be best to record the information in this case
would be voice recording (for interview) and a list notes using spreadsheets to
categorize and prioritize information. If I were to schedule a meeting with librarians
to discuss the functioning, I would consider an interview process, observations, and
questionnaires. For the interviews, this would be a one-on-one with the employees
and librarians that can answer my questions and get a better understanding of the
functionality of the library. Observations are when I would just monitor the overall
day-to-day activity in the library to make notes for myself of my observations, then
I would go over them with the head of the facility. Lastly, questionnaires, surveys,
and checklists are another way to gather information without the stress of having
one-on-one. Most of the time, this can shed some light of the excellent practices
being performed. Also, this can also allow individuals to not be targeted if they
highlight critical errors. For the two methods to record information, there really isn’t
a wrong answer. It depends on the person taking record of the different methods
above. Most individuals use notes and then consolidate them into a report on either
a word document or spreadsheet. Just to eliminate any confusion of what was
actually said, I would use a recording device just to simply document the words to
be later transcribed at a later time. The way I would approach the project is by:
• Methods to gather information
1. First – I would conduct interviews. For theinterview I would prepare and use
both open and closed ended information. Thefirst interviews would be with
mangers and higher level leaders. From this Iwould get a high level
understanding of what the goal of the job is and the tasksneeded to be
completed. I would also ask what the goal of the new program indetail. Next
I would conduct interviews with the librarians and supervisors tounderstand
how the tasks are completed in detail
2. Second – I would do observations of the tasks beingperformed to see first
hand what is being completed.
3. Third – I would look and review all thedocumentation I could find on the
current systems
4. Forth – I would completed follow up interviewswith selected people with
very specific closed questions on gaps in the processof information I collected.
• Methods used to record the information gathered
1. The first method I would use is taking notes
2. Second I would record the interviews and observations.That way I could go
back later to review in case I am missing notes.
The three different methods that I would use to gather information from the
librarians are, one, using questionnaires. I would have the library team and users fill
out questionnaires geared towards gathering input about what they think can be
improved about the system. Second, I would use interviews to dig deeper and get a
more individualized introspective about the current system and what the would like
to see improved on. The third approach would be documentation review. I would
review previous and current documentation about the operations of the library to see
how they operate and try to incorporate as much of what works as possible so that
integration can be smooth. I would definitely use voice recorders during interviews,
to easily reference accurate information. I would also take good old fashioned
written notes during the process and organize my note taking at the end of each
day of research for easy reference.
The following are some of the finest approaches to get information from librarians
in order to properly create an application for the university library's automation
requirements. Interviewing You are welcome to ask the librarians questions about the
systems they presently use and any areas they would want to see improved. By
conducting group, individual, or combination interviews, you may discover firsthand
what works and what doesn't. You may also discover how the new program can
increase librarian productivity and make their work easier.
User research. By putting up side-by-side comparisons, you may understand firsthand
how the system is now used and operated. This allows you to comprehend the
actions taken by the librarians, as well as any prospective efficiencies or faster
methods that would allow them to automate their current approach. It also allows
you to assess whether or not they have upgraded from an obsolete legacy system to
a more current type of storage, such as Microsoft Azure or AWS for cloud storage,
for maintenance and updates.
Documents being examined. Document analysis may be used if there are any
anomalies in the way the librarians are currently recording their work and the
volumes. This allows your program to consider the documentation component while
developing it and allows for changes in how to keep track of the books and what
is owed, among other things. I would input the information in two places: a
Microsoft Word document and an Excel spreadsheet. Notes may be added and
prioritized in the word document by utilizing categories. The spreadsheet will
contain the number of volumes the library has on hand, classifications, usage
graphs, late returns, and so on.
In this type of scenario, the methods I would use to gather requirements would be
interviews, observation, and interface analysis (assuming that there are interfaces).
Interviews would be helpful to gather various opinions and facts since each user
brings a unique perspective to the table. I would make sure to interview users from
all permission levels and all job assignments to get the fullest understanding of the
requirements of each person and position. I would also observe the users since it is
valuable to see how they currently do their job tasks and where efficiency can be
improved Finally, I would do an interface analysis. I would find out which
programs need to be able to access and exchange information with the new system.
In some cases, the information may be merely converted to the new system, but
there are times this is not possible. Through all three of these methods, user
expectations should be considered and managed.
The two methods I would use to record the information would be to prioritize
requirements and confirm, confirm, confirm. The first method of prioritizing
requirements is to attempt to determine which requirements could potentially slow
down or halt the project. Finding what the users would consider deal breakers early
in the process can help to mitigate or create fixes early in the process. The second
method I would use is the confirm, confirm, and confirm the data. No matter how
much I think I may understand the requirements, confirming that I do is extremely
important. I may have no in-depth knowledge of library functioning and the library
employees may not have in-depth knowledge of systems development. To make sure
that both sides are understanding the other, many conversations must occur, and
probing questions must be asked. Understanding the needs and requirements is one
of the most important pieces to a project like this. I would listen to the librarians
to learn what problem they are trying to solve with the automation and how they
envision it to work. Any features that they would like but you think is unnecessary,
question on what they think it’s needed. Then I would use the five W’s and one to
help the librarians answer who, what, when, where why and how. I would then
study and interview the librarians. Sometimes when asked direct questions, a user
may not give the information needed so watching their routine is important. I would
then copy the existing system that the librarians are doing manually. Automate as
much of the manual process as possible. Finally, I would brainstorm with the
librarians to gather all their ideas and then sift through each to see which of those
ideas is worth pursuing further. Once the information gathering is completed, I
would use Unified Modeling Language which lets me show how parts of the system
should function. I would also use user stories as part of recording requirements.
This way I can show the librarians how the system will automate a certain activity.
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. 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. In order to assist the librarians in automating the front desk activities, I would
definitely use Interviews, User observation and surveys to best understand the
functionality of the library as well as the desires and the end goal of the
automation.
I would use the user observation technique and surveys most likely. I would first
conduct surveys with the librarians. I would want to know what they use as their
current processes for the front desk, and I would also ask them what they would
like to be automated in the process. I think this is very important because often
people want to automate a process but do not necessarily know if that is even
possible or if they may have to change or alter the process to automate it.
Next, I would conduct user observation. I would want to see how they execute the
processes they told me about in the surveys. It is common when people describe
how things function or how they do things, that they may not explain it correctly
or leave out key details in the process that they didn't feel were vital in order for
us to automate things. The three different methods I would use to gather
information are Interviews, questionnaires/surveys, and user observation. I think the
best way to get information is a conversation. I like the openness of this approach
as I feel you can get the most information this way. It is also important to observe
how they use the system now and seeing what works and what does not. The last
is a questionnaire or survey. My go to would be an interview, there are situations
where a yes or no is best.The two different methods I would use to record the
information I gathered would be Talk to the Right Stakeholders and users and be
transparent with requirements. As above with information gathering. You need to
talk to the right people. First, you need to talk to the stakeholders. What is their
understanding of what is needed? Then you need to talk to the people who will
use it. What are they expecting? What do they want? Then you need to need to
talk to everyone and make sure your understanding of what they want is correct. I
deal with this daily at my job. I create Tableau reports. I always ask if the end
users have a sketch of what they want. I find this helps A LOT in the design
phase and it helps get us in the same page. I tend to keep it all in an excel
spreadsheet. I also use a Rocketbook for sketches and notes. The first thing I would
do is watch the librarians in their daily activities to see their workflow and the
workflow of the library. You can learn a good bit about the function of the library
or other system by observing the activity. The next thing I would like to do is
conduct interviews with the librarians to get their input about how they do their
job. I will also get their expectations of what the new automation will be and how
it will help them do their job. The last thing I would like to do is conduct a
survey of the customers of the library to get their expectations of the new system
and any suggestions or feedback of the new system. vv
I would use audio visual recording of the observed workflow and the interviews so
I could go back and review them later. I would record the survey in a computer so
they can be searched and filtered to get a good overview of the data needed to
complete the task. vv
Methods to Gather Requirements:
1. Interviews
2. Questionaries or Surveys
3. User Observation
4. Document Analysis
5. Interface Analysis
6. Workshops
7. Brainstorming
8. Role-play
9. Use Cases and Scenarios
10. Focus Groups
11. Prototyping
Methods to Document Requirements:
1. Design Tools
2. Prioritize Requirements
3. Confirm, Confirm, Confirm
4. Talk to the Right Stakeholders and Users
5. Transparent Requirements Documentation
Gathering stakeholder requirements and communicating with them throughout the
design and development of the project helps to ensure that what you provide to
them will meet their needs. Designers and developers who ignore their stakeholders
and don't include them in the process significantly increase the risks of the design
and development efforts failing.I like to focus on confirmation. I can't underscore
how important appropriate confirmation with all of the stakeholders is. Proper
communication and confirmation help to ensure that there are no misunderstandings
with the requirements definitions. It also helps to ensure that all of the stakeholders
and all of the project team members have a shared vision of the requirements and
how they will be implemented in the software application. Software engineering,
project management, project control, and implementation will run much more
smoothly, efficiently, and effectively with appropriate confirmation and
communication.
Interviewing and user observation are great ways to gather reequipments for a new
project. I did not even think about document analysis but it will have good
information about the current system and how it is spoused to operate. A excel
sheet would be a good way to get the observation and reequipment recorded. I
would think automation of the circulation desk at a library would be like self check
out at the works largest retailer. One of the many project teams that I manage is
working on a software application development project and is currently finalizing
requirements definitions. We just had a requirements review meeting this morning
and before the meeting, I took a few minutes to examine existing documents for
one of the functional areas on the project. I was able to identify some key scoping
and requirements details that really benefited the team as I shared these findings
with them in the design review meeting. It is another example to me of why the
activities we are studying in this course are so important and key to successful
software engineering.
Interviewing key users and stakeholders should always be included in the software
engineering requirements gathering process. I am glad that you are focusing on this
activity. Doing so will help you to better understand key user and stakeholder needs
and will help you to better identify their requirements and use these requirements to
create a software application design that will meet their needs.I think document
analysis would be a good way for gathering information and requirements. Based on
the information we have it seems that this library has been in place for a while
and has a system that they are currently using. Document analysis focuses on
examining the existing system to understand how it operates. It also examines the
requirements that existed when the original system was created to get a better
understanding of why the original system was designed the way it was. Conducting
an interview would be a great start to gathering information, especially when
implementing the five Ws and one H. There are no right or wrong answers but
from their perspective and respectfully listening as they share their views. It is good
to have a reflection on topics of great importance for research purposes! Being
creative and having the innovation for an outside-of-the-box perspective is a good
understanding and usage when it comes to brainstorming an idea. Focusing on
quantity and trying to hold back on criticism is essential because it creates an
environment for thought production without worries of being told that the
information is irrelevant. I agree that communication is number one when it comes
to managing a project. Performing risk management and a plan for any conflicts
that might occur. interviewing others are a great of knowing what they do at their
job and how you can benefit from them. I can agree with you that by interviewing
someone, it would allow you to focus on what they do at their job, so that you
know what to do depending on the task that is given to you. The interview enables
the employer to determine if an applicant's skills, experience and personality meet
the job's requirements. It also helps the employer assess whether an applicant would
likely fit in with the corporate culture. Part of brainstorming is experimenting with
what is most effective for your team and with the emergence of remote
brainstorming, there are many new exercises that teams can conduct to find new
ideation methods says .Embracing new brainstorming methods, including
asynchronous collaboration, is something that is vital when moving forward and
helps everyone approach innovation with an open mind.
