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. zz 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. zz 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. zz
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. z
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.
