Experiment No.

2
Incremental lifecycle model
It is an evolution of waterfall model. The product is designed,
implemented, integrated and tested as a series of incremental
builds .It is a popular model software evolution used many
commercial software companies and system vendor.

Applications
Incremental software development model may be applicable to
projects where:
 Software Requirements are well defined, but realization may
be delayed.
 The basic software functionality are required early
Incremental Model Phases
Advantages
• Generates working software quickly and early during the
software life cycle.
• More flexible - less costly to change scope and requirements.
• Easier to test and debug during a smaller iteration.
• Easier to manage risk because risky pieces are identified and
handled during its iteration.

Disadvanta
ges
• Each phase of an iteration is rigid and do not overlap each
other.
• Problems may arise pertaining to system architecture because
not all requirements are gathered up front for the entire
software life cycle.
Spiral lifecycle model
Spiral model is an evolutionary version of incremental
prototyping, developed by Boehm in 1988. Each iteration of the
prototype represented as a cycle in the spiral. The Spiral
software development model is a risk-oriented.

Applications
Spiral software development model may be applicable to
projects where:
 The projects requirements are very difficult
 Where new technologies are used
The aim of customer communication is to establish effective
communication between developer and customer.
The planning objectives are to define resources, project
alternatives, time lines and other project related information.
The purpose of the risk analysis phase is to assess both
technical and management risks.
The engineering task is to build one or more representations of
the application.
The construction and release task – to construct, test, install
and provide user support (e.g., documentation and training).
The customer evaluation task - to obtain customer feedback
based on the evaluation of the software representation created
during the engineering stage and implemented during the install
stage.

Advantages
• High amount of risk analysis
• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.

Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.

• Project's success is highly dependent on the risk analysis

phase.
• Doesn’t work well for smaller projects
Rapid Application Development
RAD is a linear sequential software development process model
that emphasis an extremely short development cycle using a
component based construction approach. If the requirements are
well understood and defines, and the project scope is constraint,
the RAD process enables a development team to create a fully
functional system with in very short time period.

RAD model has the following phases:

1. Business Modeling: The information flow among business

functions is defined by answering questions like what
information drives the business process, what information is
generated, who generates it, where does the information go,
who process it and so on.
2. Data Modeling: The information collected from business
modeling is refined into a set of data objects (entities) that are
needed to support the business. The attributes (character of
each entity) are identified and the relation between these data
objects (entities) is defined.
3. Process Modeling: The data object defined in the data
modeling phase are transformed to achieve the information
flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting or
retrieving a data object.
4. Application Generation: Automated tools are used to
facilitate construction of the software; even they use the 4th
GL techniques.
5. Testing and Turn over: Many of the programming
components have already been tested since RAD emphasis
reuse. This reduces overall testing time. But new components
must be tested and all interfaces must be fully exercised.
Advantages

• RAD reduces the development time and reusability of

components help to speed up development.
• All functions are modularized so it is easy to work with.
Disadvantages

• For large projects RAD require highly skilled engineers in the

team.
• Both end customer and developer should be committed to
complete the system in a much abbreviated time frame.
• If commitment is lacking RAD will fail.
• RAD is based on Object Oriented approach and if it is
difficult to modularize the project the RAD may not work
well.
What is Requirements Elicitation?
Requirements elicitation is the process of identifying the sources
of requirements for a new system and obtaining those
requirements from those sources.

Potential sources of requirements include users, documents,

regulators and even legacy software code.

Requirements elicitation is a crucial part of the Requirements

Gathering, Documentation and Analysis Process.

It is a very challenging activity that requires focus and skill from

the business analyst.

Whatever elicitation technique you choose and however you

implement the technique, you need to do whatever it takes to
understand what the real needs of your customers are.

There are many requirements elicitation techniques that may be

used in various situations depending on the level of
requirements as well as the type of stakeholder.

Each requirements elicitation technique has its advantages and

disadvantages.
It is a good idea to gain a mastery of many different elicitation
techniques so that you can use a combination of them on the job
to successfully draw out your stakeholder needs.

Preparing to Elicit Requirements

Planning your elicitation activities ensures that you:

1. Understand your stakeholders.

2. Use the right elicitation techniques for each stakeholder or
stakeholder group.
3. Accurately prioritize the stakeholders and assign the right
level of involvement.
4. Allocate adequate time and resources to the requirements
gathering activities.
5. Adequately prepare the stakeholders for the elicitation
sessions.
6. Gain the trust and cooperation of your stakeholders.
Requirements Elicitation Techniques
Brainstorming
Brainstorming sessions are used to let the stakeholders come up
with creative ideas or new approaches to a problem

Workshops
Workshops are facilitated meetings with multiple stakeholders.
Interviewing
Interviews are in-person, one-on-one meetings where the
business analyst asks questions to get information from the
stakeholder.

With an interview you can quickly obtain a lot of requirements

from one person. However, you still need to examine those
requirements to make sure they do not conflict with other
stakeholder needs.

Surveys
Surveys are used to gather information anonymously from the
stakeholders.

Documentation Review
This is the process of obtaining requirements from written
documentation such as manuals.

Prototyping
This is the use of partially finished versions of the software that
have been created to help validate requirements.
Focus Groups
Focus Groups are group interviews with potential and/or actual
users where the business analyst raises issues and questions to
obtain information from the stakeholders.

Focus groups are a collaborative technique that lets you gather a

lot of information. It includes a measure of brainstorming which
is good when the users don’t know what they really want or
need from the system.

Observation
Observation is when the business analyst watches the users
performing their daily tasks and asks questions about the tasks
and work. This technique gives you the advantage of actually
seeing what the users do as they work as opposed to what they
tell you they do.

Observation helps the analyst develop a real understanding of

the user’s on the job issues.

A good business analyst should have excellent skills choosing

and using the right elicitation technique for each situation.