Unit II: Requirements

Engineering & Analysis

1
 Users Vs System Requirements
Users Requirements System Requirements

• Written for customers. • Written for implementation team

(designers, developers, testers, etc.)

• Written in Natural language. • Written in Technical language.

• Describes services and features of the • Describes detail description of features

system. and services.

• May include diagrams and tables. • May include system models and system
designs. E.g. Algorithms, flowcharts etc.

• Understandable by users who don’t have • Understandable by implementation team

technical knowledge. who have technical knowledge.

• Users requirements are for clients/users, • System requirements are for system
client managers etc architect, system designers, software
developers etc.
2
 Tools of Requirement Engineering
1) Observation reports.
2) Questionnaires (interviews, surveys, polls).
3) Use cases.
4) User stories (user experiences).
5) Requirement workshop.
6) Mind mapping.
7) Prototyping.

3
Software used in Requirements Engineering

1) Xebrio.
2) Jira.
3) Doc sheets.
4) Requirements hub.
5) Spira Team.

4
Establishing Ground Work

1) Identifying stakeholders –
• Each and every person associated with the
product.
• Each and every person directly/indirectly
benefited from the product.
• E.g. – business operation managers, product
managers, marketing people, customer,
consultants, product engineers, software
engineers, developers, testers, maintenance
engineers, support engineers etc. 5
Establishing Ground Work

2) Recognizing multiple viewpoints –

• Because of many stakeholders system requirements
will be examined from various perspective.
• Each stakeholder contributes different data to
requirements.
• There may be a contradiction in requirements.
• Decision- maker (requirement engineer/project
manager) can select consistent requirements.
• Decision –maker selects accurate and quality
requirements.
6
Establishing Ground Work

3) Working towards collaboration-

• Different stakeholders have different opinions on
set of requirements.
• All stakeholders should work together to develop
successful system.
• Requirement engineer identifies common
requirements and conflict requirements.
• At the end project head/requirement engineer
decides which requirements should be accepted.
7
Establishing Ground Work

4) Asking the First Questions- (for identifying

stakeholders)
The first set of questions focuses on the customers,
stakeholders as well as overall project goal and benefits.
• Who is the person/organization behind the request
for this work?
• Who will make use of the solution?
• What is the economic value of the successful
solution?
• Is there a different source for the solution? (is there
any similar kind of system exists?) 8
Establishing Ground Work

4) Asking the First Questions- (for understanding

problem and solution)
• How will you characterized ‘good’ output produced
by a successful solution?
• To what problems will this solution be applied?
• Can you describe the business environment in which
the solution will be used?
• Will there be any special performance issues or
constrains that will influence how the solution is
approached?
9
 Requirements Engineering Tasks
• The process of collecting software requirements from
the customer, analyze & document them is
requirement engineering.
• Requirement engineering builds a bridge to design and
construction.
• Requirement engineering provides appropriate
mechanism for understanding what customer wants,
analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution, validating
the specifications.
• Requirement engineering consists 7 tasks-
Requirements Engineering Tasks
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management
 Inception

• It’s the first step/task of requirement analysis.

• Basic things regarding the projects like who want the
solution, who are the stakeholders, what exactly
customer need and what is the aim of the project.
• Inception enhances collaboration between customer
and developer.
( Basically these are the activities which we perform in
Establishing Groundwork).
 Elicitation
• This phase focuses on gathering the requirements.
• Right people must be involved in this phase.
• Following 3 problems may occur in this phase-
1. Problems of Scope -
customers/users specify unnecessary technical details
that may confuse rather than overall system objectives.
2. Problems of Understanding –
When customers/ users are not completely sure of
what is needed, don’t have complete understanding of
problem domain.
3) Problem of Volatility –
Requirements change over the time which causes
difficulty in developing the project.
 Elaboration
• The information obtained from the customer during
Inception and Elicitation is expanded and refined
during elaboration.
• This task focuses on developing refined requirements
model.
• Elaboration is driven by the creation and refinement of
user scenarios
 Negotiation
• Negotiation between developer and customer about
project cost, delivery time and available resources is
done.
 Specification

• Specification can be a written document, a set of

graphical models, a fundamental mathematical
model, prototype etc.
• In this task requirement engineer constructs the
final work product i.e. SRS.
• SRS document include user, system, functional,
non – functional requirement.
• SRS document is written in natural language.
 Validation

• SRS document is checked for errors.

• Additional requirements can be added in this
phase.
 Requirements
Management

• Requirements for the computer based systems

change throughout the life of the system.
• Requirements management is the set of activities
that help the project team identify, control and
track requirements and change requirements at
any point as the project proceeds.
 Software Requirements Specification
• SRS is a document that mention complete description
about how the system is expected to perform,
behavior of the system, functional and non –
functional requirements of the system.
• SRS document is written in natural language.
• It is written by Requirement Engineer.
• SRS document acts as an agreement between
customer and development team.
• SRS document is signed off at the end of requirement
engineering phase.
• Users of SRS- Customer, Development team,
Maintenance team.
 Need of SRS Document
• It structures and formalizes all project requirements.
• It helps the developer to develop the product as per
the customer need/requirements.
• It provides all necessary information to all team
members.
• It minimizes all possible misunderstanding between
development team and the customer.
• It allows estimating the required development time
and the budget.
 Structure of SRS Document
1) Introduction –
i. Purpose.
ii. Intended audience.
iii. Scope.
iv. Definition.
v. References.
 Structure of SRS Document
2) Overall Description –
i. User Interface.
ii. System Interface. (server required)
iii. Software & Hardware Requirements.
iv. Constraints.
 Structure of SRS Document
3) System Features and Requirements –
i. Functional Requirements.
ii. Use cases/ Sequence diagram.
iii. External Interface Requirement.
iv. Database Requirement.
v. Non-Functional Requirements.
 Characteristics of good SRS Document
1) Correctness - All functional & non-functional
requirements are mentioned accurately.
2) Completeness - It should contain all features,
functions, performance, external interface etc.
3) Consistency - Format of SRS should be
followed properly.
4) Unambiguousness - should not be any
confusion about any requirement.
5) Modifiability - changes should be easily done.
 Characteristics of good SRS Document
6) Verifiability – SRS should be verified from
customer and stakeholders.
7) Traceability – Requirements should have
different numbers so that they can be
traceable.
8) Design independence – It should mention
different design.
9) Testability – it should be testable as per user
requirements.
10)Understandable by the customer – should be
 SRS – Student’s Online Feedback
1) Introduction –

1.1 Purpose –
 Students can give online feedback of subject teachers .
 This document gives detail functional and non-functional
requirements for online student feedback system.
 The purpose of this document is that the requirements mentioned in
it should be utilized by software developers to implement the
system.

1.3 Intended Audience –

 Students, Teachers, HODs, Principal.
SRS – Student’s Online Feedback
1.3 Scope –
 This system allows the students to provide quick feedback of
different subjects.
 In future Teacher’s can also give their feedback regarding facilities.

1.4 Overview –
 This system provides an easy solution to college staff and students
for maintaining feedback.

1.5 Definitions –
 HOD – Head of Department.
 SRS – Student’s Online Feedback
2) Overall Description – This online feedback system
replaces the traditional, manual feedback system by
which lot of paper work will be reduced.
2.1 User Interface -
 There should be different sections for Students, Staff, HOD and
Principle.

2.2 Software Requirements –

 Online student feedback system.

2.3 Hardware Requirements –

 The system should be embedded in all desktops.
 SRS – Student’s Online Feedback
2.4 Constrains – (Limitations/Conditions)
 Teachers/ HOD should not have an access to edit student feedback.
 System should be developed within 6 months.

3) System’s Functions Requirements –

3.1 Functional Requirements –
 Student Login
 Staff Login
 HOD login
 Principal Login
 There should be teachers database containing Name, Photo, Subject
and other details.
 SRS – Student’s Online Feedback
3) System’s Functions Requirements –
3.2 Database Requirements –
 The feedback data should be transferred to the database server.

3.3 Non-Functional Requirements –

 Security – students and teachers should be provided separate
passwords.
 Availability – System should be available during college hours.
 Reusability – The same system will be used in each semester.
 SRS – Hospital Management System
1) Introduction –
1.1 Purpose –

1.2 Scope –
 Methods of Requirement Elicitation
1) Interviews –
• Discussion with the customer.
• Interviews can be of two types – open minded
or Structured.
• In open minded interviews questions are asked
context free.
• In structured interviews agenda is pre-set.
• This is old method of gathering requirements.
 Methods of Requirement Elicitation
2) Brain Storming –
• Group discussion which leads to ideas very
quickly.
• Helps to promote creative thinking.
• Very popular now a days & being used in most
of the organizations.
 Methods of Requirement Elicitation
3) Delphi Technique –
• Participants write the requirements on the
paper.
• Then requirements are exchanged among the
participants to get revised set of requirements.
 Methods of Requirement Elicitation
4) FAST (Facilitated Application Specification
Technique) –
• Used for large projects.
• This approach encourages creation of teams of
customers and developers
• Everyone is asked to prepare a list of –
i. Produced by the system
ii. Used by the system
iii. List of service, constrains and performance
creation.
 Methods of Requirement Elicitation
5) QFD ( Qualify Functional Deployment) –
• It emphases to incorporate the requirements of the customer
with importance.
• Value indicating degree of the importance is assigned to each
requirement.
• Thus customer determines the importance of requirements on
the scale of 1-5.
i. 5 points – very important
ii. 5 points - important
iii. 5 points – not important but nice to have
iv. 5 points – not important
v. 5 points – not realistic
 Methods of Requirement Elicitation
6) Use Case Approach –
• Use case diagrams are graphical representation to show the
system at different levels.
• It describes sequence of events from users perspective.
• These are structured description of user requirements.