Requirement Analysis &

Specification

UNIT -2

1
Types of Requirements
Types of Requirements

Known Unknown Undreamed

Requirements Requirements Requirements

Stakeholder: Anyone who should have some direct or indirect

influence on the system requirements.
--- User
--- Affected persons

Requirements

Functional Non-Functional

2
Types of Requirements
Functional requirements describe what the software has to
do. They are often called product features.
Non Functional requirements are mostly quality
requirements. That stipulate how well the software does,
what it has to do.
Availability
Reliability
For Users
Usability
Flexibility

Maintainability
Portability For Developers
Testability

3
Types of Requirements
User and system requirements
• User requirement are written for the users and include
functional and non functional requirement.
• System requirement are derived from user requirement.
• The user system requirements are the parts of software
requirement and specification (SRS) document.

4
Types of Requirements
Interface Specification
• Important for the customers.

TYPES OF INTERFACES

• Procedural interfaces (also called Application

Programming Interfaces (APIs)).
• Data structures
• Representation of data.

5
Feasibility Study
Is cancellation of a project a bad news?
As per IBM report, “31% projects get cancelled before they
are completed, 53% over-run their cost estimates by an
average of 189% & for every 100 projects, there are 94
restarts.

How do we cancel a project with the least work?

CONDUCT A FEASIBILTY STUDY

6
Feasibility Study
Technical feasibility

• Is it technically feasible to provide direct communication

connectivity through space from one location of globe to
another location?

• Is it technically feasible to design a programming

language using “Sanskrit”?

7
Feasibility Study
Feasibility depends upon non technical Issues like:

• Are the project’s cost and schedule assumption realistic?

• Does the business model realistic?

• Is there any market for the product?

8
Feasibility Study
Purpose of feasibility study

“evaluation or analysis of the potential impact of a

proposed project or program.”

Focus of feasibility studies

• Is the product concept viable?
• Will it be possible to develop a product that matches the
project’s vision statement?
• What are the current estimated cost and schedule for the
project?

9
Feasibility Study
Focus of feasibility studies

• How big is the gap between the original cost & schedule
targets & current estimates?
• Is the business model for software justified when the
current cost & schedule estimate are considered?
• Have the major risks to the project been identified & can
they be surmounted?
• Is the specifications complete & stable enough to
support remaining development work?

10
Feasibility Study

Focus of feasibility studies

• Have users & developers been able to agree on a

detailed user interface prototype? If not, are the
requirements really stable?
• Is the software development plan complete & adequate
to support further development work?

11
 Requirements Elicitation
Perhaps
• Most difficult
• Most critical
• Most error prone
• Most communication intensive
Succeed

effective customer developer partnership

Selection of any method
1. It is the only method that we know
2. It is our favorite method for all situations
3. We understand intuitively that the method is effective in
the present circumstances.
Normally we rely on first two reasons.
12
 Requirements Elicitation
1. Interviews
Both parties have a common goal
--- open ended Success of the project
Interview
--- structured

Selection of stakeholder
1. Entry level personnel
2. Middle level stakeholder
3. Managers
4. Users of the software (Most important)

13
Requirements Elicitation
Types of questions.
• Any problems with existing system
• Any Calculation errors
• Possible reasons for malfunctioning
• No. of Student Enrolled

14
Requirements Elicitation
5. Possible benefits
6. Satisfied with current policies
7.How are you maintaining the records of previous students?
8. Any requirement of data from other system
9. Any specific problems
10. Any additional functionality
11. Most important goal of the proposed development

At the end, we may have wide variety of expectations from the

proposed software.

15
Requirements Elicitation
2. Brainstorming Sessions
It is a group technique

group discussions

New ideas Quickly Creative Thinking

Prepare long list of requirements

Categorized
Prioritized
Pruned
*Idea is to generate views ,not to vet them.
Groups
1. Users 2. Middle Level managers 3. Total Stakeholders

16
Requirements Elicitation
A Facilitator may handle group bias, conflicts carefully.

-- Facilitator may follow a published agenda

-- Every idea will be documented in a way that everyone can
see it.
--A detailed report is prepared.

3. Facilitated Application specification Techniques (FAST)

-- Similar to brainstorming sessions.

-- Team oriented approach
-- Creation of joint team of customers and developers.

17
Requirements Elicitation
Guidelines
1. Arrange a meeting at a neutral site.
2. Establish rules for participation.
3. Informal agenda to encourage free flow of ideas.
4. Appoint a facilitator.
5. Prepare definition mechanism board, worksheets, wall
stickier.
6. Participants should not criticize or debate.

FAST session Preparations

Each attendee is asked to make a list of objects that are:
18
Requirements Elicitation
1. Part of environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
A. List of constraints
B. Functions
C. Performance criteria
Activities of FAST session
1. Every participant presents his/her list
2. Combine list for each topic
3. Discussion
4. Consensus list
5. Sub teams for mini specifications
6. Presentations of mini-specifications
7. Validation criteria
8. A sub team to draft specifications
19
Requirements Elicitation
4. Quality Function Deployment
-- Incorporate voice of the customer

Technical requirements.
Documented
Prime concern is customer satisfaction
What is important for customer?

-- Normal requirements
-- Expected requirements
-- Exciting requirements

20
Requirements Elicitation
Steps
1. Identify stakeholders
2. List out requirements
3. Degree of importance to each requirement.

21
Requirements Elicitation
5 Points : V. Important
4 Points : Important
3 Points : Not Important but nice to have
2 Points : Not important
1 Points : Unrealistic, required further
exploration
Requirement Engineer may categorize like:
(i) It is possible to achieve
(ii) It should be deferred & Why
(iii) It is impossible and should be dropped from
consideration
First Category requirements will be implemented as per
priority assigned with every requirement.

22
Requirements Validation

Check the document for:

 Completeness & consistency

 Conformance to standards
 Requirements conflicts
 Technical errors
 Ambiguous requirements

23
Requirements Validation

SRS document
List of problems

Validation
Organizational process
standards

Organizational Approved actions

knowledge

24
Requirements Review Process

Distribute Read
Plan review SRS documents
documents

Organize
review

Revise Follow up
document actions

25
Requirements Validation
Problem actions
• Requirements clarification
• Missing information
• find this information from stakeholders
• Requirements conflicts
• Stakeholders must negotiate to resolve this conflict
• Unrealistic requirements
• Stakeholders must be consulted
• Security issues
• Review the system in accordance to security standards

26
Review Checklists

 Redundancy
 Completeness
 Ambiguity
 Consistency
 Organization
 Conformance
 Traceability

27
Prototyping

Validation prototype should be reasonably complete &

efficient & should be used as the required system.

28
Requirements Management

• Process of understanding and controlling changes to

system requirements.
ENDURING & VOLATILE REQUIREMENTS
o Enduring requirements: They are core requirements &
are related to main activity of the organization.
Example: issue/return of a book, cataloging etc.
o Volatile requirements: likely to change during software
development lifer cycle or after delivery of the product

29
Requirements Management Planning

• Very critical.
• Important for the success of any project.

30
Requirements Change Management

• Allocating adequate resources

• Analysis of requirements
• Documenting requirements
• Requirements traceability
• Establishing team communication
• Establishment of baseline

31