0% found this document useful (0 votes)
43 views28 pages

Lecture 03: Requirements Engineering - I: Course Leader(s)

The document discusses the requirements engineering process and activities. It describes what requirements are, the stages of requirements engineering which include inception, elicitation, elaboration, negotiation, specification, and validation. It also discusses analyzing models, functional and non-functional requirements, and prioritizing requirements.

Uploaded by

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

Lecture 03: Requirements Engineering - I: Course Leader(s)

The document discusses the requirements engineering process and activities. It describes what requirements are, the stages of requirements engineering which include inception, elicitation, elaboration, negotiation, specification, and validation. It also discusses analyzing models, functional and non-functional requirements, and prioritizing requirements.

Uploaded by

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

Lecture 03 : Requirements Engineering –I

CSC210A Software Development Fundamentals


B. Tech. 2017

Course Leader(s):
Ms.Sahana.P.Shankar
[email protected]
Ms. Supriya, M. S.
[email protected]

1 1
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Lecture Objectives

• At the end of this lecture, student will be able to


– Indicate the nature of requirements in software
engineering
– Describe the requirement engineering process
– Discuss the activities and tasks of requirements
engineering
– Identify the functional and non-functional requirements

2 2
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Lecture Contents
• Requirements
• Requirements engineering
• Analysis models
• Stages in requirements engineering

3 3
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirement

• Requirement is an expression of desired behavior

• A requirement deals with


– Objects or entities
– The state they can be in
– Functions that are performed to change states or object characteristics

• Requirements focus on the customer’s needs, not on


the solution or implementation
– Designate what behaviour, without saying how that behaviour will be
realised

4 4
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirement Process

Figure shows the process of determining the


requirements for a proposed software system

5 5
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirement Process contd.

• Performed by
– The requirement analyst or system analyst

• The final outcome is


– A Software Requirements Specification (SRS)
document
• SRS is used to communicate to other software
developers (designer, testers, maintainers)

6 6
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirements Engineering

• Requirements Engineering (RE)


– The broad spectrum of tasks and techniques that lead to an
understanding of requirements

• RE lead to an understanding of
– What the business impact of the software will be
– What the customer wants
– How end users will interact with the software

7 7
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirements Engineering Tasks
• Inception - Establish a basic understanding of the
problem and the nature of the solution

• Elicitation - Draw out the requirements from


stakeholders

• Elaboration (Highly structured) - Create an analysis


model that represents information, functional, and
behavioral aspects of the requirements

• Negotiation - Agree on a deliverable system that is


realistic for developers and customers
8 8
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirements Engineering Tasks

• Specification - Describe the requirements formally or


informally

• Validation - Review the requirement specification for


errors, ambiguities, omissions, and conflicts

• Requirements management - Manage changing


requirements

9 9
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Inception
• At project’s inception software engineers ask a set of
questions that establish
– Basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired
– The effectiveness of preliminary communication and
collaboration between the customer and the developer

10 10
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Elicitation
• Elicit requirements from customers, users and others
– Find out from customers, users and others what the product
objectives are
– What is to be done
– How the system or product fits into business needs
– How the system or product is used on a day to day basis

11 11
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirement Elicitation - Stakeholders
• Clients: pay for the software to be developed
• Customers: buy the software after it is developed
– Sometimes the customer and the user are the
same
• Users: use the system
• Domain experts: familiar with the problem that the
software must automate
• Market Researchers: conduct surveys to determine
future trends and potential customers
• Lawyers or auditors: familiar with government, safety,
or legal requirements
12 12
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Requirement Elicitation - Stakeholders
• Software engineers or other technology experts:
ensure that the product is technically and
economically feasible
• Lawyers or auditors: familiar with government, safety,
or legal requirements
• Software engineers or other technology experts:
ensure that the product is technically and
economically feasible

13 13
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Means of Eliciting Requirements
• Interviewing stake holders
• Reviewing available documentations
• Observing the current system (if one exists)
• Apprenticing with users to learn about user's task in
more details
• Interviewing user or stakeholders in groups
• Brainstorming with current and potential users

14 14
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Resolving Conflicts
• Different stakeholder has different set of
requirements
– potential conflicting ideas

• Need to prioritize requirements


• Prioritization might separate requirements into three
categories
1. essential: absolutely must be met
2. desirable: highly desirable but not necessary
3. optional: possible but could be eliminated

15 15
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Prioritizing Requirements - Example
• A credit card billing system
1. essential: system must be able to list current charges,
sum them and request payment by a certain date
2. desirable: system may separate the charges by
purchase type, to assist the purchaser in
understanding buying patters
3. optional: system may print the credits in black and
the debits in red

16 16
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Why Requirement Elicitation is Difficult?
• Problem of understanding by customers
– Not completely sure of what is needed
– Have a poor understanding of the capabilities and
limitations of the computing environment
– Don’t have a full understanding of their problem domain
– Have trouble communicating needs to the system engineer
– Omit detail that is believed to be obvious
– Specify requirements that conflict with other requirements
– Specify requirements that are ambiguous or not able to
test

17 17
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Why Requirement Elicitation is Difficult?
Contd.
• Problems of scope
– The boundary of the system is ill-defined
– Customers/users specify unnecessary technical detail that may
confuse rather than clarify objectives
• Problems of volatility
– Requirement change over time

18 18
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Types of Requirements
• Functional requirement
– Describes required behavior in terms of required activities, such
as reactions to inputs, and the state of each entity before and
after an activity occurs

• Quality requirement or non-functional requirement


– Describes some quality characteristic that the software must
posses
– Describe the non-functional features such as Reliability,
Performance, availability, and maintainability

19 19
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Functional Requirements
• Functionality
– What will the system do?
– When will the system do it?
– Are there several modes of operation?
– What kind of computation/data transformation must be
performed?
– What are the appropriate reactions to possible stimuli?
• Data
– For both input and output, what should be the format of the
data?
– Must any data be retained for any period of time?

20 20
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Non-functional Requirements

• Performance
• Usability and human factors
• Security
• Reliability and availability
• Maintainability
• Precision and accuracy
• Time to delivery/cost

21 21
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Elaboration
• Focuses on developing a refined technical model of
software functions, features, and constraints using
the information obtained during inception and
elicitation
• Create an analysis model that identifies data,
function and behavioral requirements
• Driven by the creation and refinement of user
scenarios that describe how the end-user will
interact with the system
• End result defines informational, functional and
behavioral domain of the problem
22 22
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Negotiation
• Agree on a deliverable system that is realistic for
developers and customers
• Requirements are categorized and organized into
subsets
• Relations among requirements identified
• Requirements reviewed for correctness
• Requirements prioritized based on customer needs

• Negotiation about requirements, project cost and


project timeline
• There should be no winner and no loser in effective
negotiation
Faculty of Engineering & Technology
23
©Ramaiah University of Applied Sciences
23
Specification
• Specification - Different things to different people
• It can be
– Written Document
– A set of graphical models
– A formal mathematical models
– Collection of usage scenario
– A prototype
– Combination of above
• The formality and format of a specification varies
with the size and the complexity of the software to
be built
– For large systems, written document, language descriptions, and
graphical models may be the best approach
– For small systems or products, usage scenarios 24 24
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Validation
• Requirements Validation - formal technical review
mechanism that looks for
– Errors in content or interpretation
– Areas where clarification may be required
– Missing information
– Inconsistencies (a major problem when large products or
systems are engineered)
– Conflicting or unrealistic (unachievable) requirements

25 25
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Characteristics of Requirements
• Correct
– Should ensure that they conform to customer’s understanding of
requirements

• Consistent
– Are there any conflicting requirements?

• Clear and Unambiguous


– Has only one possible interpretation
– A reader can easily understand the meaning of the requirement

• Complete
– Specifies required behavior and output for all possible inputs in all
possible states under all possible constraints
26 26
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Characteristics of Requirements contd.
• Feasible
– Does a solution to the customer’s needs even exist?

• Relevant
– Is every requirement relevant?

• Testable
– Suggest acceptance tests that would clearly demonstrate
whether the eventual product meets the requirements

• Traceable
– Are the requirements organized and uniquely labeled for
27 27
easy reference?
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences
Summary
• Requirement is an expression of desired behavior

• Requirements analysis is iterative involving domain


understanding, requirements collection, classification,
structuring, prioritization and validation

• Functional requirement describes the required


behavior in terms of required activities

28 28
Faculty of Engineering & Technology ©Ramaiah University of Applied Sciences

You might also like