Scribd
Upload
59 views4 pages

Assignment 1

Eliciting requirements is a complex process that requires understanding user needs and having a strong relationship between customers and developers. There are several key activities and methods used in requirements elicitation including interviews, brainstorming sessions, facilitated application specification technique, and quality function deployment. The success of elicitation depends on the skills of all parties involved.

Uploaded by

muhammad Asim
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
59 views4 pages

Assignment 1

Eliciting requirements is a complex process that requires understanding user needs and having a strong relationship between customers and developers. There are several key activities and methods used in requirements elicitation including interviews, brainstorming sessions, facilitated application specification technique, and quality function deployment. The success of elicitation depends on the skills of all parties involved.

Uploaded by

muhammad Asim
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Eliciting requirements is one of the most complex, error-prone, and

communication-intensive aspects of software development. It can only be effective


if there is a strong customer-developer relationship. It is important to understand
what the users really need.

Elicitation of requirements activities:

The following tasks are part of the requirements elicitation process. Here is a list of
a few of them –

• Understanding of the general environment in which the devices are used.

• The specific aspects of the customer issue to which the method will be applied
must be known.

• Device interaction with external specifications.

• In-depth analysis of user requirements.

• Define the device development constraints.

Requirements elicitation Methods:


There are a number of requirements elicitation methods. Few of them are listed
below:

 Interviews
 Brainstorming Sessions
 Facilitated Application Specification Technique (FAST)
 Quality Function Deployment (QFD)
 Use Case Approach

The success of an elicitation technique used depends on the maturity of the


analyst, developers, users, and the customer involved. 

Interviews:
The aim of performing an interview is to learn about the customer's software
preferences.
Since it is difficult to interview every stakeholder, members from various
organisations are chosen based on their knowledge and reputation.

Interviews may be unstructured or formal.

1. There is no pre-determined agenda in open-ended interviews. To better


understand the issue, ask context-free questions.

2. An agenda of reasonably open questions is planned for a formal interview. For


some interviews, a proper questionnaire is developed.

2. Brainstorming Sessions:

This is a group strategy that aims to stimulate a large number of new ideas while
also creating a forum for people to express their opinions.

• To handle group prejudice and disputes, a highly qualified facilitator is needed.

• Every suggestion is written down so that everybody can see it.

• Finally, a document is created that contains a list of specifications and, if


possible, their priority.

3. Facilitated Application Specification Technique: 


Its goal is to close the expectation gap, or the gap between what developers
believe they can create and what customers believe they will get.

For gathering specifications, a team-oriented approach is built.

Each participant is asked to make a list of items that are:

1. Part of the system's environment

2. Produced by the system

3. The device makes use of

Of member makes a list, which is then combined, obsolete entries are removed,
the team is split into smaller sub-teams to create mini-specifications, and
eventually a draught of specifications is written with all of the meeting's inputs.
4. Quality Function Deployment: 
Consumer loyalty is a top priority in this strategy, because it focuses on the
conditions that are most important to the customer.

There are three categories of specifications listed –

• Normal requirements – This is where the user and the proposed software's


purpose and objectives are addressed. • Expected requirements – They are so
evident that the consumer does not need to clearly mention them. For example,
typical requirements for an outcome management system would be entry of
points, measurement of performance, and so on. For instance, security against
unauthorised entry.

• Exciting requirements – It contains functions that go beyond and above the


customer's needs and, when available, are very rewarding.Example – when
unauthorized access is detected, it should backup and shutdown all processes.

The following are the main stages in this procedure:

1. Identify all partners, including users, creators, and consumers.

2. Make a list of all of the customer's conditions.

3. Each requirement is given a numerical value showing its significance.

4. Finally, the specifications are classified as follows: • It is feasible to


accomplish • It should be withheld and why • It is difficult to achieve and should
be dropped off

5. Use Case Approach:

This method incorporates text with images to help people interpret the criteria
better.

The usage cases explain a system's 'what' rather than its 'how.' As a result, they
just have a functional picture of the method.

Actor, use cases, and use case diagram are the three main components of the use
case architecture.
1. Actor – An individual entity that exists independently of the system but
communicates with it. An actor may be a human, a computer, or something else
entirely. A stick figure is used to depict it. Actors may be either principal or
secondary.

• Primary players – Achieving a target necessitates the support of the system.

Secondary actor – It is an actor from which the system needs assistance.

Use cases – 
They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.

Use case diagram – 


A use case diagram graphically represents what happens when an actor interacts
with a system. It captures the functional aspect of the system. 

A stick figure is used to represent an actor.

An oval is used to represent a use case.

A line is used to represent a relationship between an actor and a use case.

You might also like