Requirements Engineering Techniques

Debark University
Department of cs
OBJECT ORIENTED SYSTEM ANALYSIS & DESIGN
Jan, 2020
21
/ 20
/2
5 B Y S H I M E L S T. 1
02
CHAPTER 3 – REQUIREMENT
ENGINEERING,
Introduction
Requirement engineering
 Requirement engineering process model
Requirements elicitation
 Requirement gathering techniques
Requirement analysis
 Functional & non-functional requirements
Requirement specification
Requirement validation
21
/ 20
/2
02
INTRODUCTION
Object Oriented Analysis, mainly involves
 Determine user’s need and system requirements
 The process known as ‘Requirement Engineering’
 Determine what to build (system modeling)
 Problem domain models
 Functional
 Essential Use Case Model
 Structure
 Class Responsibility Card Model
 Behavior
 Decision Table/Tree
21
/ 20
/2
02
REQUIREMENT ENGINEERING PROCESS
MODEL
21
20
02/2
5/
(suggested
B Y by
S H I MBray)
E L S T. 4
CONT’D…
Requirement engineering activities
 Elicitation, Analysis, Specification, HMI design
Requirement documents, prepared at the end

 Requ. Definition, System Spec., HMI Spec.
Important, distinction between

 Problem domain (described by requirement doc.)
 Current (problematic) version of the problem domain
 Solution domain (described by specification doc.)
projected future version, the system to be built
21
/ 20
/2
02
REQUIREMENT ELICITATION
Characteristics system analyst should have:
 Impertinence
Find the best organizational solution
 Impartiality
Question everything
 Relaxation of constraints
 Attention to detail
 Reframing
View the organization in new ways
21
/ 20
/2
02
CONT’D…
Deliverables
 Information collected from users
 Existing documents and files
 Computer-based information
 Understanding of organizational components
Business objective
Information needs
Rules of data processing
Key events
21
/ 20
/2
02
CONT’D…
Deliverables of Requirement Elicitation
21
/ 20
/2
02
REQUIREMENT GATHERING
TECHNIQUES
Traditional Methods
 Interview
 Questionnaire
 Observation
 Business document
Modern Methods
 Joint application design
 Prototyping
21
/ 20
/2
02
TRADITIONAL METHODS
21
/ 20
/2
02
CONT’D…
Interviewing
 Interview questions
Open-Ended
No pre-specified answers
Close-Ended
Respondent is asked to choose from a set of
specified responses
 Preparation is key
 Interviews cost more but yield more information
21
/ 20
/2
02
CONT’D…
Guidelines for Effective Interviewing
21
/ 20
/2
02
REQUIREMENTS GATHERING TECHNIQUES
Interview has five basic steps

1. Selecting interviewees
2. Designing interview questions
3. Preparing for the interview
4. Conducting the interview
5. Post-interview follow-up
21
/ 20
/2
02
CONT’D
A.Selecting interviewees:- Based on information needed and often good
to get different perspectives
Managers
Users
Ideally, all key stakeholders
Types of questions
Closed-Ended Questions (how many telephone orders are received per
day)
Open-Ended Questions (what do you think about the current system)
Probing Questions (why? Can you give me an example)
21
/ 20
/2
02
CONT’D…
B. Designing interview questions

Unstructured interview (Broad, roughly defined
information)
Structured interview (More specific information)
Questioning strategies.
21
/ 20
/2
02
CONT’D…
21
/ 20
/2
02
CONT’D
C. Interview Preparation Steps

Prepare general interview plan:- List of question and
Anticipated/expected answers and follow-ups
Confirm areas of knowledge
Set priorities in case of time shortage
Prepare the interviewee
Schedule
Inform of reason for interview
Inform of areas of discussion
21
/ 20
/2
02
CONT’D
D. Conducting the interview

Appear professional and unbiased
Record all information
Check on organizational policy regarding tape
recording
Be sure you understand all issues and terms
Separate facts from opinions
Give interviewee time to ask questions
Be sure to thank the interviewee
End
5/ 20
21 on time
18
B Y S H I M E L S T.
/2
02
CONT’D…
Conducting the interview practical tips
Don’t worry, be happy
Pay attention
Summarize key points
Be succinct
Be honest
Watch body language
E. Post-Interview Follow-Up
Prepare interview notes
Prepare interview report
Look25/20for
21 gaps and new questions B Y S H I M E L S T. 19
/
02
CONT’D…
Administering Questionnaires
 Mostly closed-end questions, as well as open-end
 D/f sampling techniques to choose respondents
Convenient, Random, Purposeful, Stratified
Sample should be representative of all users
 Can be administered in person, over the phone,
company intranet, and internet
 Must be carefully designed
 Questionnaires are more cost-effective
21
/ 20
/2
02
QUESTIONNAIRE STEPS
1. Selecting participants:- Using samples of the population
2. Designing the questionnaire:- Careful question selection
3. Administering the questionnaire:- Working to get good
response rate
4. Questionnaire follow-up:- Send results to participants
21
/ 20
/2
02
CONT’D…
Comparison of Interviews and Questionnaires
21
/ 20
/2
02
CONT’D…
Directly Observing Users
 Used to supplement interviews
 Often difficult to obtain unbiased data
 People often work differently when being observed
Analyzing Business Document
 Organizational direction
 Values of organization
 Special information processing circumstances
 Rules for processing data
21
/ 20
/2
02
MODERN METHODS
Joint Application Design (JAD)
 Introduced by IBM in 1970
 Brings key users, managers, systems analysts, IS
development team together
 Used to collect requirements from key people
simultaneously
 Conducted off-site and in many sessions
 Deliverables
Documentation detailing existing system
Features of proposed system
21
/ 20
/2
02
JOINT APPLICATION DESIGN (JAD)
JAD Key of ideas
Allows project managers, users, and developers to work
together
May reduce scope creep by 50%
Avoids requirements being too specific or too vague
Joint Application Design (JAD) Important Roles
Facilitator:- sets the meeting agenda and guides the
discussion
Scribe: - assist the facilitator by recording notes,
making copies, etc.
Project
25
/ 20
21 team, users, and management
25
B Y S H I M E L S T.
/
02
CONT’D…
Joint Application Design (JAD) Setting
U-Shaped seating
Away from distractions
Whiteboard/flip chart
Prototyping tools
e-JAD
21
/ 20
/2
02
21
/ 20
/2
02
CONT’D…
Typical Room Layout for JAD Session
21
/ 20
/2
02
CONT’D…
Prototyping
 Quickly converts basic requirements to working version of the system to be developed
 Repetitive process, user may ask requirements modified or generate additional requests
 Used to develop concrete specifications for the ultimate system or final system to be
developed
Most useful when:
 User requests are not clear
 Few users are involved in the system
21
/ 20
/2
02
CONT’D…
 Designs are complex and require concrete form
 Communication problems b/n analysts and users
 CASE Tools are readily available to build prototype
Drawbacks
 Tendency to avoid formal documentation
 Difficult to adapt to more general user audience
 Sharing data with other systems is often not considered
21
/ 20
/2
02
CONT’D…..
4.Document analysis
Provides clues about existing “as-is” system
Typical documents
 Forms
 Reports
 Policy manuals
Look for user additions to forms
Look for unused form elements
5. Observation
Users/managers often don’t remember everything they do
Checks validity of information gathered other ways
Behaviors change when people are watched
Careful
02
1 not to ignore periodic activities
/2 31
25 B Y S H I M E L S T.
Weekly … Monthly … Annual
02
/
CONT’D…
Criteria to select the appropriate tool
21
/ 20
/2
02
WHAT IS A REQUIREMENT?
Requirement
 Features of system or system functions used to fulfill
system purpose
Requirement must be
 Actionable, measurable, testable, related to business needs
or opportunities, detail enough for system design
Focus on user’s needs & domain properties
 Requirements definition document
 Written for stakeholders (client and users)
Focus on solution domain
 Requirements specification document
 Written for technical staff (developers)
21
/ 20
/2
02
TYPES OF REQUIREMENT
User requirements
 Statements in natural language of services system provides & its operational constraints
(high level)
 Written for customers
System requirements
 Setting out detailed descriptions of the system’s functions, services & operational
constraints
 Written for technical staff & defines what should be implemented, may include models
21
/ 20
/2
02
FUNCTIONAL & NON-FUNCTIONAL
REQUIREMENT
Requirements can be mainly categorized as,
 Functional and non-functional
Functional requirements
 Relates directly to a process the system has to perform or information it needs to
contain
Non-functional requirements
 Refers to behavioral properties that the system must have, mainly such as performance
& usability
 Impose constraints on design or implementation
 Different types of non-functional requirements
21
/ 20
/2
02
CONT’D…
E.g., Functional requirements
21
/ 20
/2
02
FUNCTIONAL REQUIREMENT
21
/ 20
/2
02
CONT’D…
Different types of non-functional requirements
Requirement type Example
Operational • The system should be able to fit in a pocket or purse
• The system should be able to integrate with the existing
inventory system.
Performance • Any interaction between the user and the system should
not exceed 2 seconds.
• The system should receive updated inventory information
every 15 minutes.
Security • Only direct managers can see personnel records of staff
• Customers can see their order history only during business
hours.
Cultural & Political • The system should be able to distinguish between United
States and European currency
• The system shall comply with insurance industry
21 standards.
/ 20
/2
02
NON-FUNCTIONAL REQUIREMENT
CLASSIFICATION
Non-functional
requir ements
Product Organisational External

requir ements requir ements requir ements
Efficiency Reliability Portability Inter oper a bility Ethical

requir ements requir ements requir ements requir ements requir ements
Usa bility Deli very Implementa tion Standar ds Leg islative

requir ements requir ements requir ements requir ements requir ements
Perfor mance Space Pri vacy Safety

requir ements requir ements requir ements requir ements
21
/ 20
/2
02
REQUIREMENTS MEASURES
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
21
/ 20
/2
02
REQUIREMENTS DEFINITION
DOCUMENT
Introduction
 Purpose of the document
• Problem domain analysis
 Description of existing system
 Major functions (objectives, process/activities)
 Key players (users role)
 Business rules (eligibility requirements)
 Data requirements (input and output)
Requirements (focus on user’s need & domain

properties)
 Functional requirements
 Non-functional requirements
21
/ 20
/2
02
REQUIREMENTS SPECIFICATION
Invention & definition of behavior of a new system

(soln. domain), w/c produces the required effects
in the problem domain
Start from a knowledge of problem domain & the
required effects determined by elicitation &
analysis
Generally involves modeling
Results in the system specification document
 Precise expression of requirements, may include models
IEEE 830-1998 is recommended to prepare SRS

21
/ 20
/2
02
REQUIREMENT SPECIFICATION DOCUMENT
Introduction
 Purpose
 Scope
 Definitions, Acronyms and Abbreviations
 References
 Overview
General Description
 Product perspective
 Product functions a rd
 User characteristics
ta nd
 Constraints 8 S
 19 9 i ne
Assumptions and dependencies
3 0- u tl
E 8 SO
IEE SR
21
/ 20
/2
02
CONT’D…
Specific Requirements
 External interface requirements
 Functional requirement
 Performance requirements
 Logical database requirements
 Design constraints
 Software system attributes
security, availability, maintainability,
transferability
 Other requirements
21
/ 20
/2
02
REQUIREMENT VALIDATION
Performed at every stage of requirement
process
 Elicitation
Check back with the elicitation sources

“So, are you saying that . . . . . ?”
 Analysis
Domain description & requirements correct?

 Specification
Defined system requirement meet user

requirements with the assumptions of domain?
Conformity to well-formedness rules, standard?
21
/ 20
/2
02
CONT’D…
Objectives
 Clarifies requirements document is acceptable description of the system to be
implemented
 Checks a requirement document for completeness consistency, feasibility, and
testability.
 Conformance to standards
 Requirement conflict
 Technical errors
 Ambiguous requirement
21
/ 20
/2
02
VALIDATION TECHNIQUES
Simple checks
Prototyping
Functional test design
User manual development
Reviews and inspections
 Walkthroughs
 Formal inspections
 Checklists
Model-Based
 First-order logic
 Behavioural models
21
/ 20
/2
02
REVIEWS AND INSPECTIONS
A group of people read & analyze requirements
to look for potential problems;
 Meet to discuss the problems
 Agreed on actions to address these problems
A widely used requirements validation

technique
 Lots of evidence of effectiveness of the technique
Can be expensive
 Careful planning and preparation
 Pre-review checking
 Need appropriate checklists
21
/ 20
/2
02
TYPICAL REVIEW / INSPECTION STEPS
21
/ 20
/2
02
PROBLEM CATEGORIZATION
Requirements clarification
 The requirement may be badly expressed or may have accidentally omitted information
Missing information
 Some information is missing from the requirements document
Requirements conflict
 There is a significant conflict b/n requirements
 The stakeholders involved must negotiate to resolve the conflict
21
/ 20
/2
02
CONT’D…
Unrealistic requirement
 The requirement does not appear to be implementable with the technology available or
given other constraints on the system
 Stakeholders must be consulted to decide how to make the requirement more realistic
21
/ 20
/2
02
CONT’D…
Advantages
 Effective (even after considering cost)
 Allow finding sources of errors (not only symptoms)
 Requirements authors are more attentive when they know their work will be closely
reviewed
Encourage them to conform to standards

 Familiarize large groups with the requirements
 Diffusion of knowledge
21
/ 20
/2
02
CONT’D…
Risks
 Reviews can be dull and draining (need to be limited in time)
 Time consuming and expensive (but usually cheaper than the alternative)
 Personality problems
 Office politics
21
/ 20
/2
02

Requirements Engineering Techniques

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Engineering Techniques

Uploaded by

Copyright:

Available Formats

Debark University

OBJECT ORIENTED SYSTEM ANALYSIS & DESIGN

Requirement documents, prepared at the end

Important, distinction between

Interview has five basic steps

B. Designing interview questions

C. Interview Preparation Steps

D. Conducting the interview

Product Organisational External

Efficiency Reliability Portability Inter oper a bility Ethical

Usa bility Deli very Implementa tion Standar ds Leg islative

Perfor mance Space Pri vacy Safety

Requirements (focus on user’s need & domain

Invention & definition of behavior of a new system

IEEE 830-1998 is recommended to prepare SRS

Check back with the elicitation sources

Domain description & requirements correct?

Defined system requirement meet user

A widely used requirements validation

Encourage them to conform to standards

You might also like