1

American International University–Bangladesh

Assignment on Requirement Collection

Faculty: Abhijit Bhoumik

Group Members List: 

SL Name ID Department
01 MD. IMRAN AHMED 17-35042-2 CSE
02 ASIF AL JUBAYER 17-35983-3 SE
03 RASHED RANA 17-34604-2 SE
04 MD. YEASIN ALI 17-34925-2 SE
Question:
Suppose you are a project manager of a software company. Your company got
a big software project to develop for a poultry and frozen food company.
Project is to automate their company with an ERP (Enterprise Resource
Planning).
Now plan and describe how you can successfully collect full requirements
from the company and start development. We all know without collecting
requirements properly software cannot be developed perfectly.

Answer:
Designing and building a fancy computer program that solves the wrong problem
is of no use to anyone. That is why it is important to understand what the customer
wants before starting to design and build a computer-based system. There is no
such part of the job, so it paralyzes the resulting system if done wrong. No other
will part more difficult to rectify later time. Many software developers argue that
things will become clear as they are built, that project stakeholders will be able to
understand the need only after examining the first iterations of the software, that
things change so quickly that any attempt to understand the requirements in detail
is a waste of time. That the end result is to produce a work program, and that
everything else is secondary. Requirements engineering establishes a solid
foundation for design and construction. Without it means proper requirement, the
resulting software has a high probability of not meeting customer needs. If we are
to implement proper requirements engineering, we have to cover seven different
tasks. And those are known as initiation, obtaining, elaboration, negotiation,
specification, validation and management. For our project given here we are going
to discuss the elicitation part. It seems simple enough ask the customer, users, and
others what the goals of the system or product are, what needs to be achieved, how
the system or product fits the needs of the business, and finally how the system
works or the product is adjusted to the needs of the company and finally how the
system or the product is adapted to the needs of the company and finally how the
system or the product will be used on a day to day basis. But it is not simple, it is
very difficult. An important part of obtaining is setting business goals. Your job is
to engage stakeholders and encourage them to share their goals honestly.
Once the objectives have been captured, a prioritization mechanism must be
established and a design foundation can be created for a potential architecture that
meets the objectives of the stakeholders. Requirements gathering combines
elements of problem solving for specific problem in different way must have to
choose the best way, elaboration, negotiation, and specification. In order to foster a
collaborative and team-oriented approach to gathering requirements, stakeholders
work together to identify the problem, propose solution elements, negotiate
different approaches, and specify a preliminary set of solutions. n requirements.
We have to organize meetings whether real or virtual attended by software
engineers and other interested parties. We have to set the rules of preparation and
participation between developers and stakeholders. We have to create an agenda
that is formal enough to cover all the important points, but informal enough to
encourage the free flow of ideas. We have to choose a facilitator it can be a client,
a developer or an external who will control the meeting. We must have create a
definition that mechanism could allow worksheets, flip charts or wall stickers or an
electronic bulletin board, chat room or virtual forum or both. Our main focus is to
identify the problem clearly, propose elements of the quite better solution,
negotiate different approaches and specify a preliminary set of solution
requirements. We will generate a product request during our startup. We will then
select an appropriate meeting place, time, and date for stakeholder participation
and software team members. We will make a product request and it will be
distributed to all attendees before the date of the meeting. Everyone could
contribute to this narrative during the requirements gathering meeting and much
more information would be available. Attendees must list objects that are part of
the environment surrounding the system, other objects that will be produced by the
system, and objects that are used by the system to perform its function. In addition,
each wizard is asked to make another list of services processes or functions that
manipulate or interact with the objects. Finally, a list of constraints cost, size,
business rules and performance criteria speed, accuracy is also developed.
Attendees are informed that the lists are not expected to be exhaustive, but to
reflect each person's perception of the system. We are going to fix the list of
objects on the walls of the room with large sheets of paper, stick them to the walls
with sticky sheets or written on a wall board. Alternatively, the lists may have been
posted to a group forum, internal website, or social media environment for review
prior to the meeting. We could share our motivations or wishes using these
platforms or forms. Ideally, each entry in the list should be able to begin to be
manipulated separately so that the lists can be combined, the entries can be
removed, and additions can be made. At this stage, criticism and debate are strictly
prohibited. Aldous Huxley said that facts don’t cease to exist because they are
ignored. We need to avoid the urge to reject a client's idea as too expensive or
impractical. The idea here is to negotiate a list that is acceptable to everyone. To do
this, we must keep an open mind on the board. After individual lists are presented
in a subject area, the group creates a combined list by removing redundant entries,
adding any new ideas that come up during the discussion, but without removing
anything. After creating combined lists for all topic areas, the discussion occurs,
coordinated by the facilitator. The combined list is shortened, lengthened or
rewarded to properly reflect the product or system to be developed. The goal is to
develop a consensus list of objects, services, constraints, and performance for the
system to be built. For further explanation, we have created a mini specification for
the entries in the list or by creating a use case involving the object or service. The
mini specifications are presented to all interested parties for discussion. Additions,
deletions, and further elaboration are made. You can discover new objects,
services, constraints, or performance requirements that will be added to the original
lists. During all discussions, the team may raise a problem that cannot be resolved
during the meeting. A list of topics is maintained for action on these ideas later.
We have to consider non-functional system requirements such as accuracy, data
accessibility, security. As stakeholders voice these concerns, we must consider
them within the context of the system to be built. Among the questions to be
answered can we build the system? Will this development process allow us to
overcome? Our competitors to the market? Are there adequate resources to build
and maintain the proposed system? Will the performance of the system meet the
needs of our customers? The answers to these and other questions will evolve over
time by time. Quality function implementation is a quality management technique
that translates customer needs into technical requirements for the software. QFD
defines the requirements in a way that maximizes customer satisfaction. We have
QFD uses customer interviews and observation both, surveys, and examination of
historical data which are from previous analysis, such as problem reports, as raw
data for requirements gathering activity. This data is translated into a requirements
table, called a voice of the customer table, which is reviewed with the customer
and other interested parties. As the requirements are gathered, an overview of the
system features and functions will materialize. The work products produced as a
consequence of obtaining the requirements will vary according to the size of the
system or product to be built. Product engagements include a statement of need
and feasibility, a limited statement of the scope of the system or product, a list of
customers, users and other interested parties who participated in obtaining
requirements, a description of the technical environment of the system, a list of
requirements and the domain restrictions that apply to each, a set of usage
scenarios that provide information on the use of the system or product under
different operating conditions, and any prototypes developed to better define the
requirements. Each of these work products is reviewed by everyone who has
participated in obtaining requirements. In the context of an agile process,
requirements are obtained by asking all stakeholders to create user stories.
Obtaining requirements is a service-oriented development that focuses on defining
the services that an application must provide. We have to implement use cases so
that the actor's point of view can be clarified. A use event tells a stylized tale about
how an end user interacts with the system in a specific set of circumstances. We
have to prepare questions to guide the conversation. Based on your responses, we
have to suggest ideas. We have to come up with ideas because a creative BA
suggests ideas and alternatives during elicitation. BAs can think outside of the
mental box that limits people who are too close to the problem domain. We have to
show patience, give verbal feedback and ask when something is unclear and
paraphrase reaffirming the main idea of a speaker's message to show their
understanding of that message. We have agreed on some basic operating
principles. We have to decide to start and end on time, return from breaks
promptly, mute electronic devices, hold one conversation at a time, expect
everyone to contribute, and focus comments and criticism on issues rather than
individuals. Once the rules are in place, we have to make sure that everyone
follows them.

A person known as a facilitator should make sure note taking, time keeping, scope
management, ground rules management, making sure everyone is listening covered
by people in the workshop. A scribe can record what is happening, while another
person watches the clock. We need to create a clear plan and workshop agenda in
advance, and communicate them to the participants so they know the objectives
and what to expect and can prepare accordingly. We have to make sure that the
proposed requirements for users are within the scope of the current project. We
have to keep each workshop focused on the appropriate level of abstraction for the
objectives of the session. Groups can easily plunge into discussions of distracting
detail requirements. These discussions are time consuming that the group should
spend developing a high-level understanding of user requirements. The facilitator
will need to speak with the elicitation participants periodically to keep them on
topic. We have to be on the lookout for off topic discussions, like design
explorations, during elicitation sessions. We need to keep participants focused on
the objectives of the session, while ensuring that they will have future
opportunities to work on other issues that arise. During the elicitation discussion,
quality attributes, business rules, user interface ideas, and more information will
appear. We have to organize the information on flip charts parking lots so that it
does not lose it and to show respect for the participant who mentioned it. We
couldn't endeavor to get distracted by discussing details off topic unless they turn
out to be surprising. Describe what will happen to the parking problems after the
meeting. We need to assign a fixed time period to each discussion topic. When
closing a discussion with a period of time, summarize the status and the steps and
steps before leaving the topic. We have to keep our group small. Because small
groups can work much faster than larger teams. Those who have the knowledge,
experience and decision-making authority, only they can participate in the
elicitation workshops. We have to keep everyone engaged. We have to try to re
involve the person who is outside the process. And we have to take your opinion
on whether there is any. We have to create focus group sessions and it should be
interactive, allowing all users the opportunity to express their thoughts. Discussion
groups should be facilitated. We will have to keep them on topic, but without
influencing the opinions that are expressed. We may want to record the session so
we can go back and listen carefully to the comments. We could not expect a
quantitative analysis of the focus groups, but rather a lot of subjective feedback
that can be further evaluated and prioritized as requirements are developed.
Participants in focus groups usually do not have the authority to make decisions
about requirements. When we ask users to describe how they do their job, they
probably have a hard time being precise; details may be missing or incorrect. Often
times this is because the tasks are complex and it is difficult to remember every
detail. Homework can be so common that they don't even think about it.
Sometimes we can learn a lot by observing exactly how users perform their tasks.
Observations are time consuming, so they are not suitable for all users or for all
tasks. To avoid interrupting work activities regularly assigned to users, limit each
observation time to two hours or less. We have to select important or high-risk
tasks and multiple classes of users for observations. If we use observations in agile
projects, have the user demonstrate only the specific tasks related to the next
iteration. By observing a user's workflow in the task environment, BA can validate
information gathered from other sources, identify new topics for interviews, see
problems with the current system, and identify ways the new system can better
support the flow of work. The BA must abstract and generalize beyond the
activities of the observed user to ensure that the captured requirements apply to the
user class as a whole, not just that individual. A skilled BA can also suggest ideas
to improve the user's current business processes. Questionnaires are a way to
survey large groups of users to understand their needs what their actual preference
is. They are inexpensive, making them a logical choice for gathering information
from large user populations, and can be easily managed across geographic borders.
The analyzed results of the questionnaires that we obtain for our survey could be
used as an input for other elicitation techniques. For example, we could be using a
questionnaire to identify users biggest pain points with an existing system and then
use the results to discuss prioritization with decision makers in a workshop. We
may also use questionnaires to survey users of commercial products and obtain
feedback. Preparing well written questions is the biggest challenge with quizzes.
There are many tips are available for writing questionnaires, and we are going to
follow the most important ones here:

 We need to provide answer options that cover the full set of possible
responses.
 We have to make answer choices both mutually exclusive and exhaustive.
 We shouldn’t phrase a question in a way that implies a “correct” answer.
 If we are going to use scales, we got to use them consistently throughout the
questionnaire.
 We should consider consulting with an expert in questionnaire design and
administration to ensure that we ask the right questions of the right people.
 We have to test a questionnaire before distributing it. It’s frustrating to
discover too late that a question was phrased ambiguously or to understand
that a crucial question was omitted.
 We shouldn’t ask too many questions or people won’t respond.
Interface analysis is an independent collection technique that involves examining
the systems to which your system connects. The system interface analysis reveals
the functional requirements related to the exchange of data and services between
systems. Context diagrams and ecosystem maps are an obvious choice to start
finding interfaces for further study. In fact, if we find an interface that has
associated requirements and that is not represented in one of these diagrams, the
diagrams are incomplete. For each system that interacts with ours, identify the
functionality in the other system that could generate requirements for our system.
These requirements could describe what data to pass to the other system, what data
is received from it, and rules about that data, such as validation criteria and all
other criteria will be check. We must also discover the existing functionality that
you do not need to implement in your system. Through the analysis of the system
interface, we may know that several systems pass orders to the order management
system, which performs the validation, so we do not need to develop this function.
Document analysis involves examining any existing documentation for possible
software requirements. The most useful documentation includes requirements
specifications, business processes, collections of lessons learned, and user manuals
for existing or similar applications. The documents can describe the corporate or
industry standards that must be followed or the regulations that the product must
comply with. For packaged solution deployments, the vendor documentation
mentions the functionality our users may need, but you may need to further explore
how to implement it in the target environment. Comparative reviews point out
deficiencies in other products that you could address to gain a competitive
advantage. Problem reports and enhancement requests collected from users by
technical and field support personnel can provide ideas for improving the system in
future releases.
Document analysis is a way to get up to speed with an existing system or a new
domain. Doing a little research and writing a few requirements beforehand cuts
down on the time required for the get together meeting. Document analysis can
reveal information that people don't tell us, either because they don't think about it
or because they aren't aware of it. We should use the results of this analysis as
input for interviews with users. To carry out the elicitation session, we can divide
the activities into three categories known as preparing for elicitation, performing
preparation and follow up activities after collection. These activities consist of
many different tasks or sets of activities. Decide on the scope and agenda of the
elicitation, prepare resources, and prepare the straw man questions and models
defined in the preparation for elicitation section. Conducting the elicitation session
should be described in the conducting elicitation activities section. And finally,
post fetch follows up is done to organize and share notes and document open
issues. Enterprise resource planning ERP is a process that companies use to
manage and integrate the important parts of their businesses. ERP software
applications are important to companies because they help them implement
resource planning by integrating all the processes necessary to run their companies
in a single system. We all know that our procurement techniques fall into several
categories known as Interviews, Workshops, Focus Groups, Observations,
Questionnaires, System Interface Analysis, User Interface Analysis, Document
Analysis. We have outlined all of these steps for our project and how we are going
to work through these steps. But it is not necessary to follow the questionnaire
stage. Due to our clarification on the system requirements, you do not need to
continue this process during requirements gathering. The reason the user interface
is out of the frame is that this corporate software will have a specific requirement
to interact with the system. We don't need to map the different user perspective to
this user interface analysis. Although we have described these two topics along
with the others to understand how these individual phases work, they are not
required for this elicitation. Whenever we are planning elicitation in our project,
we have to have some scope in our mind, and those are the elicitation objectives,
the elicitation strategy and planned techniques, the schedule and resource
estimates, the necessary documents and system. For independent obtaining, the
expected products of elicitation efforts and provocation risks. This is how we can
run the procurement process and achieve our goals.
END