0% found this document useful (0 votes)
17 views

Requirement Engg

Approach to software engineering

Uploaded by

Jazib Zahra
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views

Requirement Engg

Approach to software engineering

Uploaded by

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

Best Software Economics

Through
REQUIREMENTS ENGINEERING
Techniques for gathering requirements
Stakeholder Analysis

Brainstorming

One On One Interview

Group Interview

Document Analysis

Focus Group

Interface Analysis

Observation Social Analysis

Prototyping
Techniques for gathering requirements
Facilitated sessions

Joint Application Development (JAD)

Questionnaire

Survey

Use cases and scenarios (UCD)

Reused Requirements

Request for proposals (RFPs)

Reverse Engineering
1- Stakeholder Analysis
Stakeholder analysis Benefits
identifies all the users and 1. Ensures that all relevant
stakeholders who may stakeholders are considered
influence or be impacted
by the system. This helps 2. All important
stakeholders are captured,
ensure that the needs of all
and yet that irrelevant
those involved are taken actors are not included
into account

Drawbacks
There is a danger that too
much time is spent on
identifying roles and
relationships.
2- Brainstorming
It is utilized in requirements
elicitation to gather good number
Basic Rules
of ideas from a group of people. 1. Start out by clearly
Usually brainstorming is used in stating the objective
identifying all possible solutions of the brainstorming
to problems and simplifies the session.
detail of opportunities. 2. Generate as may
ideas as possible.
3. Let your imagination.
4. Do not allow
criticism or debate
while you are
gathering
information.
5. Once information is
gathered, reshape
and combine ideas.
2- Brainstorming
Benefits Risks
1. Generate a variety
of ideas in a short 1. The risk of having a bad
time session

2. Produce new and 2. Making staff scared to


creative ideas say their ideas because
they were criticized in
the session

3. Problems normally
occur if
you only use traditional
brainstorming
techniques.
3-One On One Interview
The most common
technique for gathering
Benefits
requirements is to sit down
with the clients and ask • Privacy of everyone
them what they need. The
• in-depth a
discussion should be
planned out ahead of time stakeholder’s thoughts
based on the type of and get his or her
requirements you’re point of view
looking for Risks &
Drawbacks
• Time Consuming
• Misunderstandings
4- Group Interview
If there are more then one
Benefits
person during interview
usually 2 or 4 these people • we can get hidden
must be on same level . requirements
Less time required. • uncover a richer set of
requirements in a shorter
period of time
• Uncover ambiguities

Risks & Drawbacks

• Not relaxed environment


• Conflicts
• The allotted time have been
exhausted
5-Facilitated sessions
In a facilitated session, you bring a
larger group (five or more) together
for a common purpose. In this case, Benefits
you are trying to gather a set of
• Less Time
common requirements from the group
in a FASTER MANNER than if you • Reach Group Of
were to interview each of them People
separately. • Brainstorming
sessions (virtual or
face-to-face)
Risks &
Drawbacks
• More Expensive
• need for extra
facilities to allow for
group work etc
• Handouts, readings
6-Joint Application Development (JAD)
JAD sessions are similar to general Benefits
facilitated sessions. However, the
group typically stays in the session • group typically stays
until the session objectives are in the session until
completed. For a requirements JAD the session objectives
session, the participants stay in are completed
session until a complete set of • participants stay in
requirements is documented and session until a
agreed to. complete set of
requirements
• documented and
agreed to
Risks &
Drawbacks
• takes time to build
• more costly to build
7- Questionnaire
Questionnaires are much more
informal, and they are good tools to Benefits
gather requirements from
stakeholders in remote locations or • Less cost
those who will have only minor input • Reach Large No of
into the overall requirements. Peoples
Questionnaires can also be used when • The responses are
you have to gather input from dozens, gathered in a
hundreds, or thousands of people. standardized
Risks & way
Drawbacks
• Difficult filling for
users
• participants may
forget important issues
• Stockholders may not
be willing to answer
the questions
8- Survey
When gathering information from Benefits
many people: to many to interview
with time constraints and less budget: • Less cost
a questionnaire survey can be used. • Reach Large No of
The survey insists the users to choose Peoples
from the given options agree / • A detailed critical
disagree or rate something. Do not inspection
think that you can make a survey on
your own but try to add meaningful
Risks &
insight in it. A well designed survey
Drawbacks
must give qualitative guidance for
characterizing the market. It should • Difficult filling for
not be utilized for prioritizing of users
requirements or features. • participants may
We observe by visiting the real site forget important
of the project domain. issues
• Stakeholders may not
be willing to answer
the questions
Difference between questionnaire
and survey?
The Oxford dictionary defines them as quoted below:

survey:
1 a general view, examination, or description. 2 an investigation
of the opinions or experience of a group of people, based on a
series of questions. 3 an act of surveying. 4 a map or report
obtained by surveying.

Questionnaire:
noun a set of printed questions, usually with a choice of answers,
devised for a survey or statistical study.
9-Prototyping
Benefits
Prototyping is a relatively modern
technique for gathering requirements. • prototypes can be ideal
In this approach, you gather reduce design risk
preliminary requirements that you use • it is more practical
to build an initial version of the • Screen mock-ups
solution — a prototype. You show this • Using animation tools
to the client, who then gives you • provides an
additional requirements. You change understanding of
the application and cycle around with functionality
the client again. This repetitive process Risks &
continues until the product meets the Drawbacks
critical mass of business needs or for • takes time to build
an agreed number of iterations. • more costly to build
• false sense of security
10- Document Analysis
Document Analysis is an
important gathering Benefits
technique. Evaluating the
• validating the requirement
documentation of a present completeness.
system can assist when • Chunks of information are
making AS-IS process mostly buried in present
documents and also when documents
• A beginning point for
driving the Gap documenting all current
Analysis for scoping of the requirements.
migration projects. Risks & Drawbacks

• Time Consuming
• Conflicts
• Exhausted
• Not Found Real Figures
11-Interface Analysis
Interface for any software product will either be human or
machine. Integration with external devices and systems is
another interface. The user centric design approaches
are quite effective to ensure that you make usable
software. Interface analysis- analyzing the touch points
with another external system- is vital to ensure that you do
not overlook requirements that are not instantly visible to
the users.
12- Focus Group Benefits

A focus group is actually • Managed process with


particular participants
gathering of people who are • refine and validate the
customers or users already elicited
representatives for a product to requirements
• Allows analyst to rapidly
gain its feedback. The feedback obtain a wide variety of user
can be collected about views and possibly a
consensus.
opportunities, needs, and Risks & Drawbacks
problems to determine • following the crowd and
requirements or it can be some people think that
collected to refine and validate focus groups are at best
unproductive
the already elicited requirements. • end up with is with least
common denominator
features.
• Recruitment effort to
• Assemble groups. Dominant
participants may influence
group disproportionately
13-Observation / Social Analysis
Social analysis is also known as Benefits
Observation. Observation is the
• The ability to record and
method of collecting
report all findings that
requirements by observing the are true
people doing their normal work. • it is more practical
This method is generally used to • no long calculation has
find the additional requirements to be done
needed by the user, when the user
is unable to explain their Risks & Drawbacks
expected requirements from the • The viewer's or
new product and problems with researcher's own
the existing product perception
• few trials/studies/or
objects observed to
make an end conclusion
• results may contain
human error
14- Use cases and scenarios
Use cases are basically stories that
describe how discrete processes work. Benefits
The stories include people (actors) and • provide the best return
describe how the solution works from on invested effort
a user perspective. Use cases may be • explain how that system
easier for the users to articulate, will be implemented
although the use cases may need to be • Each use case provides
distilled later into the more specific a set of scenarios that
detailed requirements. convey how the system
should interact
Risks & Drawbacks

• Poor identification of
structure and flow
• Time-consuming to
generate
• Scenario management is
difficult
15- Requirements Reuse
In the field of software
engineering reusing the Benefits
requirements of the existing
system is common method of • Reused
requirements elicitation. Using requirements are
the existing knowledge to already validated
and analyzed thus
develop the new product has
reducing the time of
many advantages that include testing
low cost and less time. Though
Risks &
each product has their own Drawbacks
type of stake holders and users,
there is still number of • Some time proposed
situations that the reusing of product is
completely different
the requirements take places form the existing
product
16- Request for proposals (RFPs)
If you are a vendor, you may
receive requirements through an
RFP. This list of requirements is
there for you to compare against
your own capabilities to
determine how close a match you
are to the client’s needs.

The RFP presents preliminary


requirements for the commodity
or service, and may dictate to
varying degrees the exact
structure and format of the
supplier's response. Effective
RFPs typically reflect the strategy
and short/long-term business
objectives, providing detailed
insight upon which suppliers will
be able to offer a matching
17-Reverse Engineering
Is this a last resort or starting point? When a
migration project is not having enough
documentation of the current system, reverse
engineering will determine what system does? It
will not determine what the thing went wrong with
the system and what a system must do?
A critical activity for any ERP implementation is
gathering business requirements

Often we spend too much time and effort focusing


on gathering requirements that do not support key
business results and then gloss over the key
business activities because of implementation time
constraints. Prioritizing business results is an
activity that we need to initiate before gather
requirements, not during fit/gap when expectations
are harder to manage and negotiate.
Effectiveness of method used
for Requirements Elicitation
Selecting Appropriate Techniques
Interview JAD Question- Document Observation
naires Analysis
Type of As-is, As-is, As-is, As-is As-is
information improves, improves, improves
to-be to-be
Depth of info High High Medium Low Low
Breadth of info Low Medium High High Low
Info Low High Low Low Low
integration
User Medium High Low Low Low
involvement
Cost Medium Low- Low Low Low-
medium medium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the new system 26

You might also like