Unit3

♣ Requirement Gathering or Fact Finding Techniques

1. Initiating a Process of Requirement Gathering: -

The most commonly used requirement gathering technique is to conduct a meeting or
interview.
We can say to get the requirements of our customer communication must be initiated.
 The analyst start by asking context free questions i.e. a set of questions that will lead to a
basic
understanding of the problem.
Analyst and customer arrange one meeting, in that meeting customer gives the software
requirement,
based on that requirement analyst asks some question to customer for better
understanding the
requirement and overall goals and the benefits e.g. the analyst can ask following
questions.
 Who is behind the request for this system?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that customer require.

The next set of questions enables the analyst to gain better understanding of the problem
and the customer to voice about the solution. The second set of questions can be how can
you characterize good output that would be generated by a successful solution of
software.
 What problems will this solution address?
 Can you describe the environment in which the solution will be used?
 Will special performance issues or constraints affect to way the solution approach?

Dr. Krishna Jariwala Page-1

 Unit3
The final set of questions focuses on the effectiveness of the meeting, it is
called Meta questions.
 Can anyone else provide additional information?
 Should I ask anything else about the problem?
 Are my questions relevant to the problem that customer have?
 Am I asking too many questions?

2. FAST (Facilitated Application Specification Technique): -

In this technique or approach joint team of customers & developers who work
together to identify the
problem, purpose and elements of the solution.
In that team one expert from each field included like Analyst side(one expert from
developers side , one
from tester side , one from designer side etc.) same way the experts from the customer
side from each
department are included in the meeting.
Each experts note-own some points in meting based on points they prepares one report
and finally reports
are submitted to leader of the team.
After collecting the all the reports from the experts analyst or (team leader) will prepares
an agenda for
software development means make schedule.
FAST has been used predominantly by the information system but the technique affects
quotient for
improved communication in applications of all kinds. The basic guidelines for FAST
approach are,

Dr. Krishna Jariwala Page-2

 Unit3
1) Meeting is conducted and attempted by both software engineers and customers.
2) Rules for preparation and participation are established.
3) An agenda is suggested that is formal enough to cover all important points.
4) Facilitate controls the meeting.
5) Definition mechanism is used it when it can be a worksheet or an electronic bulletin
board.
6) The goal is to identify the problem, proposed elements of the solution, negotiate
different approaches and specify a preliminary set of solution requirements.
Initial meetings between the developer and customer occur and basic questions and
answers help to
establish the scope of the problem and the overall perception of the solution
Out of these initial meetings the developer and customer write one or two page product
request. Meeting
place, time and date for FAST are selected and a facilitator is chosen.
Attendees from both the development and customer organization are invited to attempt.
The product
request is distributed to all attendees before the meeting date while reviewing the request
in the days before
the meeting each FAST attendees is use to make the list of objects that are part of the
environment
surrounds the system, other objects that are to be produced by the systems and objects
that are used by the
system. To perform its function list of constraints i.e. cost size and sometimes business
rule of policy,
performance criteria are also developed.
Each person on the FAST team develop the list which is describe about objects describes
for e.g. safe

Dr. Krishna Jariwala Page-3

 Unit3
home system might include smoke detectors, window & doors sensor, motion detector
and alarm, an event
from which a sensor has been activated, a control panel and so on.
 Services can be setting the alarm, monitoring the sensor dialing the phone, reading
display.
In a similar fashion each FAST develop list of constraints as a FAST meeting being the
first topic of
discussion is the need and justification for the new product at the FAST.
After the mini specifications are computed each FAST attendees makes a list of
validation criteria for the
product or system.
Finally one or more participants is assigned the task of writing the complete specification
using all inputs
from the FAST meeting and later on all requirement point of view from all members and
refinement is
prepared for development of a design.

3. QFD (quality Function Deployment): -

QFD is a quality management technique that translates the need of the customer into
technical requirement for software. QFD defines requirement in a way that maximizes the
customer specification. QFD constraint on maximizing customer satisfaction from the
software engineering process. QFD identifies three types of requirements. (1) Normal
Requirements, (2) Expected Requirements and (3) Exciting Requirements.
1. Normal Requirements: -
The objectives and goals that are defined a product or system during meetings with the
customer if these requirements are presents then the customer is satisfied. Examples of

Dr. Krishna Jariwala Page-4

 Unit3
normal requirements might be requested types of graphical display, specific system
functions and define level of performance.
2. Expected Requirements: -
These requirements are implicit to the product or system and may be so fundamental that
the customer does not explicit state them their absence then it is a cause of significant
dissatisfaction examples of expected requirements are base of human machine interaction,
overall operational correctness and reliability and software installation.
3. Exciting Requirements: -
These features go beyond the customers expectation proves to be very satisfying when
present. E.g. word processing software is requested with standard function, the delivered
product contains a number of page layout capabilities.

In meeting with the customer function deployment is used to determine the value of each
function i.e. required for the system information deployment identities both the data objects
& events that the system must consume and produced. Task deployment examines the
behavior of the system or product within the given environment.
QFD uses customer interviews and observation surveys and examination of historical data
as row data for the requirement gathering activity. Those data are then translated into a
table of requirement and this table is called customer voice table.

♣ Software Requirement Specification

Software requirement specification (SRS) is produced at the end of analysis task. The
following is the general outlines for SRS.
The Introduction states the goals and objectives of the software, describing it in the
context of the computer based system.
The Information Description provides a detailed description of the problem that software
must solve.

Dr. Krishna Jariwala Page-5

 Unit3
A description of each function required to solve the problem is presented in the Functional
Description. A processing narrative is provided for each function; design constraints are
stated and justified; performance characteristics are stated.
The Behavioral Description section examines the operation of the software as a
consequence of external events and internally generated control characteristics.
The most important section of SRS is Validation Criteria.
The Bibliography contains references to all documents that relate to the software. These
include other software engineering documentation, technical references, vendor literature,
and standards.
The Appendix contains information that supplements the specification. Tabular data,
detailed description of algorithms, charts, graphs, and other material are presented as
appendixes.

Characteristics of SRS
The final output of the requirement analysis phase is the software requirements
specification document it is also known as SRS document. To properly satisfy the basic
goals and SRS should contain different types of the requirements following are some of the
desirable characteristics of SRS.
1). Correct
An SRS is correct if every requirement if every requirement included in the SRS represents
something required in the final system.
2). Complete
An SRS is complete if every this software is supposed to do the responses of the software to
all classes of input data are specified data into SRS. Correctness ensure that what is
specified is done correctly, completeness ensures that everything is indeed specified.

Dr. Krishna Jariwala Page-6

 Unit3
3). Unambiguous (unmistakable)
An SRS is unambiguous if and only is every requirements stated or return has one and only
one interpretation.
4). Verifiable
Verification of requirements is done through reviews. It also implies that an SRS is
understandable at least by the developer, by client and by the user.
5). Consistent
An SRS is consistent if there is no requirement that conflict with another terminology can
cause in consistency. Ex Different requirements may use different terms to refer to the same
object. There may be logical conflict may be requirement causing inconsistency. Ex A
requirements stays that an event F but than other set of requirement stays that and event F
should occur before event E. In consistency in SRS can be a reflection of major problem.
6). Ranked of importance / Stability
An SRS is ranked for an importance a stable if for each requirement the importance and
stability of a requirements reflect a terms of expected change stability of a requirement
reflects in futures. Writing and SRS is an interactive process, when the requirement systems
are specified.
7). Modifiable
They are later modified as the needs of the clients change. SRS should be easy to modify.
SRS is modifiable if its structures and style are such that any necessary change can be made
easily while continuing completeness and consistency.
8). Traceable
An SRS is traceable if the origin of each of its requirement is clear and if it fulfill the
reference in of each requirement in feature development should be traceable to some design
and code element and back word traceability requirement. If be possible to trace design and
code element to the requirement. They support traceability aids verification and validation
from all this characteristics completeness is the most important requirement. One of the

Dr. Krishna Jariwala Page-7

 Unit3
most common problem is requirement specification is when some of the requirement of the
client are to specify.

♣ Effort Distribution (40-20-40 Rule)

Each of the software project estimation techniques leads to estimates of work units (e.g.,
person-months) required to complete software development. A recommended distribution
of effort across the software process is often referred to as the 40-20-40 rule. Forty percent
of all effort is allocated to front-end analysis and design. A similar percentage is applied to
back-end testing. You can correctly infer that coding (20 percent of effort) is deemphasized.
This effort distribution should be used as a guideline only. Work expended on project on
project planning rarely accounts for more than 2-3 percent of effort. A range of 20 to 25
percent of effort is normally applied to software design. Time expended for design review
and subsequent iteration must also be considered.
Because of the effort applied to software design, code should follow with relatively little
difficulty. A range of 15-20 percent of overall effort can be achieved. Testing and
subsequent debugging can account for 30-40 percent of software development effort.

Dr. Krishna Jariwala Page-8