Lecture 02 : Requirements Engineering –I
Course Leader
Ms. Supriya, M. S.
[Link]@[Link]
1 1
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
Lecture Contents
• Requirements
• Requirements engineering
• Analysis models
• Stages in requirements engineering
3
3
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
Requirement Process
Figure shows the process of determining the
requirements for a proposed software system
5
5
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
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
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
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
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
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
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
Requirement Elicitation -
Stakeholders
• Software engineers or other technology experts:
ensure that the product is technically and
economically feasible
13
13
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
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
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
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
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
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
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
Non-functional Requirements
• Performance
• Usability and human factors
• Security
• Reliability and availability
• Maintainability
• Precision and accuracy
• Time to delivery/cost
21
21
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
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
23
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
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
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
26
inputs in all possible states under all possible constraints 26
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
easy reference? 27
27
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
