m

er as
co
American International University–Bangladesh

eH w
DEPARTMENT OF COMPUTER SCIENCE

o.
rs e
ou urc
Assignment on Requirement Collection
o
aC s
vi y re

Course: Software Requirement Engineering

Section: B
ed d
ar stu
sh is

Group Members List:

Th

Sl. Name Id
01 AKTER, RAJANA 18-36629-1
02 NOBIN, HASIBUL HASAN 17-34558-2

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 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.

To designing and building an elegant computer program that solves the wrong problem serves no one's
needs. That's why it's important to understand what the customer wants before you begin to design and
build a computer-based system. The hardest single part of building a software system is deciding what to

m
build. There is no such part of the work so cripples the resulting system if done wrong. No other part is

er as
more difficult to rectify later. Many software developers argue that things will become clear as they

co
build, that project stakeholders will be able to understand need only after examining early iterations of

eH w
the software, that things change so rapidly that any attempt to understand requirements in detail is a

o.
waste of time, that the bottom line is producing a working program, and that all else is secondary.
rs e
Requirements Engineering establishes a solid base for design and construction. Without it, the resulting
ou urc
software has a high probability of not meeting customer's needs.
o
aC s

If we are going to implement the proper requirement engineering then we have to encompass seven
vi y re

distinct tasks. And those are known as inception, elicitation, elaboration, negotiation, specification,
validation, and management. For our given project here we are going to discuss elicitation part. It seems
simple enough- ask the customer, the users, and the others what the objectives for the system or
ed d

product are, what is to be accomplished, how the system or product fits into the needs of the business,
ar stu

and finally, how the system or product fits into the needs of the business, and finally, how the system or
product fits into the needs of the business, and finally, how the system or product is to be used on a day-
to-day basis. But it isn't simple- it's very hard. An important part of elicitation is to establish business
sh is

goals. Your job is to engage stakeholders and to encourage them to share their goals honestly. Once the
goals have been captured, a prioritization mechanism should be established, and a design rationale for a
Th

potential architecture (that meets stakeholder goals) can be created.

Requirements elicitation (also called requirements gathering) combines elements of problem solving,
elaboration, negotiation, and specification. In order to encourage a collaborative, team-oriented
approach to requirements gathering, stakeholders work together to identify the problem, propose
elements of the solution, negotiate different approaches, and specify a preliminary set of solution
requirements.

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 We have to arrange meetings (either real or virtual) are conducted and attended by both software
engineers and other stakeholders.

We have to fix the rules for preparation and participation among developers and stakeholders.

We have to create an agenda that is formal enough to cover all important points but informal enough to
encourage the free flow of ideas.

We have to choose a facilitator (can be a customer, a developer, or an outsider), who controls the
meeting.

We have to create a definition mechanism (can be work sheets, flip charts, or wall stickers or an
electronic bulletin board, chat room, or virtual forum).

Our main goal is to identify the problem, propose elements of the solution, negotiate different

m
er as
approaches, and specify a preliminary set of solution requirements.

co
eH w
We are going to generate product request during our inception. The we are going to select a suitable
meeting place, time, and date for the participation of stakeholders and the software team members. We

o.
rs e
are going to make a product request and that is going to distributed among all the attendees before the
ou urc
meeting date. Everyone could contribute to this narrative during the requirements-gathering meeting
and considerably more information would be available. The attendees need to make a list of objects that
are part of the environment that surrounds the system, other objects that are to be produced by the
o

system, and objects that are used by the system to perform its function. In addition, each attendee is
aC s

asked to make another list of services (processes or functions) that manipulate or interact with the
vi y re

objects. Finally, list of constraints (e.g., cost, size, business rules) and performance criteria (e.g., speed,
accuracy) are also developed. The attendees are informed that the lists are not expected to be
exhaustive but are expected to reflect each person's perception of the system. We are going to pinned
ed d

the list of objects to the walls of the room using large sheets of paper, stuck to the walls using adhesive-
ar stu

backed sheets, or written on a wall board. Alternatively, the lists may have been posted on a group
forum, at an internal website, or posed in a social networking environment for review prior to the
meeting. We could share our motivations or desires by using these platforms or ways. Ideally, each listed
sh is

entry should be capable of begin manipulated separately so that lists can be combined, entries can be
deleted, and additions can be made. At this stage, critique and debate are strictly prohibited. Aldous
Th

Huxley said that "Facts do not cease to exist because they are ignored". We have to avoid the impulse to
shoot down a customer's idea as "too costly" or "impractical". The idea here is to negotiate a list that is
acceptable to all. To do this, we must keep an open mind. After individual lists are presented in one topic
area, the group creates a combined list by eliminating redundant entries, adding any new ideas that
come up during the discussion, but not deleting anything. After we create combined lists for all topic
areas, discussion- coordinated by the facilitator- ensues. The combined list is shortened, lengthened, or
rewarded to properly reflect the product or system to be developed. The objective is to develop a
consensus list of objects, services, constraints, and performance for the system to be built. To further
explanation we have created a mini-specifications for entries on the list or by creating a use case that
involves the object or service. The mini-specs are presented to all stakeholders for discussion. Additions,

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 deletions, and further elaboration are made. It can uncover new objects, services, constraints, or
performance requirements that will be added to the original lists. During all discussions, the team may
raise an issue that cannot be resolved during the meeting. An issues list is maintained so that these ideas
will be acted on later. We have to look at the nonfunctional system requirements such as accuracy, data
accessibility, security. as stakeholders enunciate these concerns, we have must consider them within the
context of the system to be built. Among the questions that must be answered (Can we built the system?
Will this development process allow us to beat our competitors to market? Do adequate resources exist
to build and maintain the proposed system? Will the system performance meet the needs of our
customers?) The answers to these and other questions will evolve over time. Quality function
deployment is a quality management technique that translates the needs of the customer into technical
requirements for software. QFD defines requirements in a way that maximizes customer satisfaction. we
have to work within the context of QFD (QFD is a quality management technique that translates the
needs of the customer into technical requirements for software). QFD uses customer interviews and

m
er as
observation, surveys, and examination of historical data such as problem reports as raw data for the

co
requirements gathering activity. These data are translated into a table of requirements- called the

eH w
customer voice table- that is reviewed with the customer and other stakeholders. As requirements are

o.
gathered, an overall vision of system functions and features being to materialize. The work products

rs e
produced as a consequence of requirements elicitation will vary depending on the size of the system or
ou urc
product to be built. product works includes a statement of need and feasibility, a bounded statement of
scope for the system or product, a list of customers, users, and other stakeholders who participated in
requirements elicitation, a description of the system's technical environment, a list of requirements and
o

the domain constraints that applies to each, a set of usage scenarios that provide insight into the use of
aC s

the system or product under different operating conditions, and any prototypes developed to better
vi y re

define requirements. Each of these work products is reviewed by all people who have participated in
requirements elicitation. Within the context of an agile process, requirements are elicited by asking all
stakeholders to create user stories. Requirements elicitation is service-oriented development focuses on
ed d

the definition of services to be rendered by an application. We got to implement Use Cases so that the
ar stu

actor's point of view can be cleared. A use case tells a stylized story about how an end user interacts
with the system under a specific set of circumstances.
sh is
Th

First of all, we have to introduce ourselves if the attendees don't know each other. We have to review
the agenda, remind attendees of the session objectives, and address any preliminary questions or
concerns attendees have. During the elicitation session, we have to keep the discussion focused on its
objective. We have to prepare questions to guide the conversation. Based on their answers we have to
suggest ideas. we have to propose ideas because a creative BA suggests ideas and alternatives during
elicitation. BAs can think outside the mental box that limits people who are too close to the problem
domain. We have to show patience, giving verbal feedback, and inquiring when something is unclear and
paraphrasing (restating the main idea of a speaker’s message to show your understanding of that
message). We have agreed on some basic operating principles. We have to decide the starting and

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 ending on time, returning from breaks promptly, silencing electronic devices, holding one conversation
at a time, expecting everyone to contribute and focusing comments and criticism on issues rather than
individuals. After the rules are set, we have to ensure that each and every one follow them. One person
known as facilitator must make sure that note taking, time keeping, scope management, ground rule
management, making sure everyone is listening covered by people in the workshop. A scribe might
record what's going on, while someone else watches the clock. We need to create a clear plan and
workshop agenda ahead of time, and communicate them to participants so they know the objectives
and what to except and can prepare accordingly. We have to ensure that proposed user requirements lie
within the current project scope. We have to keep each workshop focused on the right level of
abstraction for the session's objectives. Groups can be easily dive into distracting detail requirements
discussions. Those discussions consume time that group should spend on developing a higher-level
understanding of user requirements. The facilitator will have to reel in the elicitation participants
periodically to keep them on topic. We have to watch out off-topic discussion, such as design
explorations, during elicitation sessions. We have to keep the participants focused on the session

m
er as
objectives, while assuring them that they'll have future opportunities to work through other issues that

co
arise. During elicitation discussion quality attributes, business rules, user interface ideas, and more

eH w
information will surface. We have to organize the information on flipcharts-parking lots-so you don't lose
it and to demonstrate respect for the participant who brought it up. We could not effort distracted into

o.
rs e
discussing off-topic details unless they turn out to be showstoppers. Describe what will happen with the
ou urc
parking lot issues following the meeting. We need to allocate a fixed period of time to each discussion
topic. When closing a timeboxed discussion, summarize status and steps and steps before leaving the
topic. We have to keep our group small. Because small groups can work much faster than larger teams.
o

Those who have Knowledge, experience, and have the authority to make decisions only they can
aC s

participate in elicitation workshops. We have to keep everyone engaged. We have to try to re-engage the
vi y re

person who is out of the process. And we got to take their opinion about if there is any. A focus group is
a representative group of users who convene in a facilitated elicitation activity to generate input and
ideas on a product’s functional and quality requirements. WE have to create focus group sessions and it
has to interactive, allowing all users a chance to voice their thoughts. Focus groups must be facilitated.
ed d

We will need to keep them on topic, but without influencing the opinions being expressed. We might be
ar stu

want to record the session so we can go back and listen carefully to comments. We could not expect
quantitative analysis from focus groups, but rather a lot of subjective feedback that can be further
evaluated and prioritized as requirements are developed. Participants in focus groups normally do not
sh is

have decision-making authority for requirements. When we ask users to describe how they do their jobs,
they will likely have a hard time being precise—details might be missing or incorrect. Often this is
Th

because tasks are complex and it’s hard to remember every minute detail. The task can be so habitual
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 aren’t suitable for every user or every
task. To avoid disrupting the users’ regularly assigned work activities, limit each observation time to two
hours or less. We have to select important or high-risk tasks and multiple user classes for observations. If
we use observations in agile projects, have the user demonstrate only the specific tasks related to the
forthcoming iteration. By observing a user’s workflow in the task environment BA can validate
information collected from other sources, to identify new topics for interviews, to see problems with the
current system, and to identify ways that the new system can better support the workflow. The BA must
abstract and generalize beyond the observed user’s activities to ensure that the requirements captured

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 apply to the user class as a whole, not just to that individual. A skillful BA can also often suggest ideas for
improving the user’s current business processes. Questionnaires are a way to survey large groups of
users to understand their needs. They are inexpensive, making them a logical choice for eliciting
information from large user populations, and they can be administered easily across geographical
boundaries. The analyzed results of questionnaires that we get for our survey could be used as an input
to other elicitation techniques. For example, we might be using a questionnaire to identify users’ biggest
pain points with an existing system, then use the results to discuss prioritization with decision makers in
a workshop. We can also use questionnaires to survey commercial product users for feedback. Preparing
well-written questions is the biggest challenge with questionnaires. There are many tips are available for
writing questionnaires, and we are going to follow the most important ones here:

■ We have to provide answer options that cover the full set of possible responses.

■ We have to make answer choices both mutually exclusive and exhaustive.

m
■ We should not phrase a question in a way that implies a “correct” answer.

er as
co
■ If we are going to use scales, we got to use them consistently throughout the questionnaire.

eH w
■ We should consider consulting with an expert in questionnaire design and administration to ensure

o.
that we ask the right questions of the right people.
rs e
ou urc
■ We have to test a questionnaire before distributing it. It’s frustrating to discover too late that a
question was phrased ambiguously or to realize that an important question was omitted.
o

■ We shouldn’t ask too many questions or people won’t respond.

aC s

Interface analysis is an independent elicitation technique that entails examining the systems to which
vi y re

your system connects. System interface analysis reveals functional requirements regarding the exchange
of data and services between systems. Context diagrams and ecosystem maps are an obvious choice to
begin finding interfaces for further study. In fact, if we find an interface that has associated requirements
ed d

and that is not represented in one of these diagrams, the diagrams are incomplete. For each system that
ar stu

interfaces with ours, identify functionality in the other system that might lead to 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. We should also discover existing
functionality that you do not need to implement in your system. Through system interface analysis, we
sh is

may be learning that multiple systems pass orders to the order-management system, which performs the
Th

validation, so we don’t need to build this function. Document analysis entails examining any existing
documentation for potential software requirements. The most useful documentation includes
requirements specifications, business processes, lessons learned collections, and user manuals for
existing or similar applications. Documents can describe corporate or industry standards that must be
followed or regulations with which the product must comply. For packaged-solution implementations,
the vendor documentation mentions functionality that our users might need, but you might have to
further explore just how to implement it in the target environment. Comparative reviews point out
shortcomings in other products that you could address to gain a competitive advantage. Problem reports
and enhancement requests collected from users by help desk and field support personnel can offer ideas
for improving the system in future releases. Document analysis is a way to get up to speed on an existing
system or a new domain. Doing some research and drafting some requirements beforehand reduces the

https://www.coursehero.com/file/67846488/assignmentSREdocx/
 elicitation meeting time needed. Document analysis can reveal information people don’t tell us, either
because they don’t think of it or because they aren’t aware of it. We should use the results of this
analysis as input to user interviews.

To perform elicitation session we can divide the activities into three categories known as prepare for
elicitation, perform elicitation activities and follow up after elicitation.

These activities consist of many different tasks or set of activities. decide on elicitation scope and
agenda, prepare resources and prepare questions and straw man models defined in the prepare for
elicitation section. Perform elicitation session should described in the perform elicitation activities
section. And lastly Follow up after elicitation is made of organize and share notes and document open
issues.

m
Enterprise resource planning (ERP) is a process used by companies to manage and integrate the

er as
important parts of their businesses. ERP software applications are important to companies because they

co
help them to implement resource planning by integrating all of the processes needed to run their

eH w
companies with a single system. We all know that our elicitation techniques are divided into several

o.
categories known as interviews, workshops, focus groups, observations, questionnaires, system interface

rs e
analysis, user interface analysis, document analysis. We have described all of these steps for our project
ou urc
how we are going to work in these steps. But we don't need to follow questionnaires stage. Because of
our clarification about system requirement we don't need to continue such process during requirement
gathering. The reason the user interface is not coming into the frame is this corporate software have
o

going to had a specific requirement to interact with the system. We don't need to map the different user
aC s

perspective to this user interface analysis. Though we have describe these two topic along with the
vi y re

others to understand how these individual phase works, these are not required for this elicitation.
Whenever we are planning elicitation on our project, we have to keep some scope in our mind, and
those are elicitation objectives, elicitation strategy and planned techniques, schedule and resource
estimates, documents and system needed to independent elicitation, expected products of elicitation
ed d

efforts and elicitation risks. This is how we can run elicitation process and meet our objectives.
ar stu
sh is
Th

https://www.coursehero.com/file/67846488/assignmentSREdocx/

Powered by TCPDF (www.tcpdf.org)