PHÂN TÍCH NGHIỆP VỤ

KINH DOANH

Bài 7:
Thu thập, tài liệu hóa và
quản lý yêu cầu

HCM – Apr-21

4/7/2021 1
 Objectives

Be able to:
Understand tasks of “Define requirements”
Explain the process for requirements
engineering
Understand some techniques in defining
requirements including investigation
techniques, Prioritisation, managing
documents .

4/7/2021 Trang 2
 AGENDA

1. Remind: Business analysis process

2. Definition and classification of
requirements
3. The problems with requirements
4. A process for requirements
engineering
5. Actors in requirements engineering
6. Requirements elicitation
7. Requirements analysis
8. Validating requirements
 AGENDA

9. The requirements document

 Content
 The requirements catalogue
10.Managing requirements
 Business analysis process

Business strategy and objectives

Investigate Consider Analyze Evaluate Define Delivering

situation perspectives needs options requirements changes

•uncover issues •analyze • identify where •examine the • gather and •Consider how
and problems stakeholders improvements potential document the
and their can be made to improvements the detailed requirements
perspectives on the business identified so far, are to be
the situation system develop some requirements delivered, the
•gap analysis: business options for changes changes
‘as is’ view vs and evaluate to the implemented
‘to be’ system them for business and the
 Define how acceptability system business
the new and feasibility benefits realized
processes
should look

4/7/2021 Trang 5
 Define Requirements

Objectives: to produce a well-formed

requirements document setting out the
business requirements for the new
business system.
Procedure
 Gather the requirements
 Document the requirements for the
new business system

4/7/2021 Trang 6
 What are Requirements?

IEEE Definition
1. a condition or capability needed by a user to solve
a problem or achieve an objective
2. a condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed document
3. a documented representation of a condition or
capability as in (1) or (2)
 Hierarchy of requirements

Types of Requirements

4/7/2021
Source: Book, pg.201 Trang 8
 Hierarchy of requirements

Types of Requirements

4/7/2021
Source: Book, pg.201 Trang 9
 Functional Requirements Examples

 The solution will automatically validate customers

against the ABC Contact Management System

 The solution will enable users to record customers sales

 The solution will enable Customer Order Fulfilment

letters to be automatically sent to the warehouse.

Question: What does “solution” mean in this context?

 Non-Functional Requirements
Examples

 Availability Requirements
 “when you need to be able to run this
process.”
 Capacity Requirements
 how many times do they operate the
process per day? How many customers are
there (over 6 years)
 Security Requirements:
 who can use these processes? Just
‘operators’ or can ‘system administrators’
use them as well? Can all operators access
any customer details or are there some that
they are not allowed to access?
4/7/2021 Trang 11
 The problems with
requirements

 Designing the solution

 Unjustified requirements: not mapped to an object,

hard to assess

 Putting in unjustified extra information

 Not putting sufficient detail in

 Protecting requirements – ego fuelled analysis!

 The problems with
requirements

duplication between requirements;

conflicts between requirements;

uncertainty amongst business users

about what they need from the new
system

inconsistent levels of detail;

4/7/2021 Trang 13
 The problems with
requirements

REASONS WHY?
 lack of terms of reference for the
project (OSCAR – Objectives, Scope,
Constrains, Authority, Resources)
 Tacit knowledge is hard to articulate
 misunderstanding

4/7/2021 Trang 14
 A process for requirements
engineering

gatheringexamining the
information and reviewing
gathered requirements
requirements to agree
requirements from
 identify overlapped,
and ‘sign off’ the
the businessconflicted, or requirements
stakeholdersduplicated
document
requirements

4/7/2021 Source: page 182 Trang 15

 A process for requirements
engineering

develop of a well-organized
requirements document

manage changes to
the requirements

4/7/2021 Source: page 182 Trang 16

 Actors in requirements
engineering

Business
Project team
representatives
• Project sponsor • Project manager
• Domain expert • Business analysts
• Business users • developer

4/7/2021 Trang 17
 Actors in requirements
engineering

Business representatives:
 project sponsor: to ensure that
business objectives are met
 domain expert: gives high-level
advice on the requirements
 Business users: apply the new
business processes and use the new
IT system

4/7/2021 Trang 18
 Actors/Stakeholders

 Project team:
 project manager: delegate tasks and
satisfy the business imperatives that
drive the project
 The business analysts: to ensure that
the requirements are well documented
and complete and align with the
business objectives
 developers: check the technical
feasibility of some of the requirements
and help the analyst appreciate the
implications of some of them

4/7/2021 Trang 19
 Requirements Elicitation

Gather the requirements

Knowledge types
 Requirements Elicitation

The process for eliciting tacit knowledge

Elicitation Techniques
 Requirements elicitation

Outputs: Requirement list

Source: Book, pg.192

4/7/2021 Trang 23
 Requirements analysis

Tasks:
 Checking congruence with business
objectives and the business case
 Checking feasibility
 Prioritization
 Structuring the requirements
 Dealing with overlapping, duplicate
and conflicting requirements

4/7/2021 Trang 24
 Requirements analysis

Quality characteristics of the

requirements:
 Clear
 Concise
 Consistent
 Relevant
 Unambiguous
 Correct
 Testable
 Traceable)
4/7/2021 Trang 25
 Examples of poor
functional requirements

1. Be able to use diary functionality

2. Be able to flag premium customers

3. Be able to track and report on sales

4. Increase accuracy of sales information

5. Allow authorised users of team-leader and above to

cancel sales orders

6. Prompt the owner of the sales order to notify the

customer of cancelled sales orders.
 Requirements analysis

Techniques:
 MoSCoW prioritisation;
 requirements organization

4/7/2021 Trang 27
 Requirements analysis - MoSCoW

Functional Requirement Prioritisation –

MoSCoW
 Must have requirement
o
 Should have requirement
 Could have requirement
o
 Wish list requirement
 Requirements analysis - MoSCoW

Functional Requirement Prioritisation Logic

 Must have: the project objectives cannot be
met without this requirement

 Should have: the project objectives can be

met without this requirement but not as well as
with it

 Could have: this requirement only maps to

one or more principles

 Wish list: this requirement does not map to

any project objectives or principles.
 Requirements analysis -
requirements organization

 Techniques: requirements organization:

 requirements structuring:
• requirements sets (e.g. functional, non-
functional, general, technical
requirements)
• links and dependencies between
requirements
• levels and hierarchical decomposition of
requirements
 requirements negotiation and conflict
analysis: discussion, prioritization,
agreement

4/7/2021 Trang 30
 Validating Requirements

Project
Stakeholders
delivery team

Review
requirements

Sign – off
requirements
document
 The requirements document

Documenting the requirements in such

way that they can form the basis for
developing, or procuring, an IT solution,
and

Managing the requirements to make

sure that they are properly controlled
 The requirements document

Content:

‘to be’shows
process
themodels
functionality of the
a description of
proposed software solution:
the business situation and
- context diagrams
drivers for the project.
4/7/2021 Trang 33
- use case diagrams
 The requirements document

Content:

Provide a superior provides

view of the data source of
a central
Provides the information about
- entity relationship modelling definitions
terminology
each individual requirement
- Class modelling
4/7/2021 Trang 34
 The requirements catalogue

 Each requirement should be documented to

define clearly what is required
 Requirements catalogue entries, elements
described for each requirement:
 Identifier
 Name
 Description
 business area
 type of requirement
 author
 source
 owner
4/7/2021 Trang 35
 The requirements catalogue

 Requirements catalogue entries, elements

described for each requirement:
 priority
 rationale/justification
 cross-referenced requirements
 cross-referenced documents
 acceptance criteria
 status/resolution
 version number and date

4/7/2021 Trang 36
 The requirements catalogue

4/7/2021 Trang 37
 Managing requirements

Well-defined and traceable

requirements are absolutely key to a
successful business change project
2 forms of traceability:
 ‘Backwards from’ traceability
• Answer question: ‘What was the source
requirement for this feature of the
solution and who raised it?’
 ‘Forwards to’ traceability
• Answer question: ‘What happened to this
requirement’
4/7/2021 Trang 38
 Managing requirements

Elements:

Source: Book, pg.211

4/7/2021 Trang 39
 Managing requirements

Elements:
 Requirements identification
• Each requirement needs to be identified
uniquely
 Cross-referencing
• All related requirements and documents
should be cross-referenced
 Origin and ownership
• The source identifies the origin of the
requirement.
• Can be the person/document
4/7/2021 Trang 40
 Managing requirements

Elements:
 Configuration management
• controlling any changes made to project
deliverables
• Levels of configuration item – individual
requirement or document
• Version numbering
 Change control
Document the Decide
Consult the
proposed
stakeholders
on the
change change
4/7/2021 Trang 41
 Managing requirements

Elements:
 Software support: provide features:
•Documentation creation and
storage
•Secure storage and access
•Documentation linkage
•Version numbering
•Examples: IBM Rational DOORS,
Serena Dimensions RM, Enterprise
Architect, etc.
4/7/2021 Trang 42
 Summarize

 Procedure of “Define requirements”

 Gather the requirements:
• Elicit and analyze the business requirements for
the new business system.
• Document and manage the requirements.
• Validate the documented requirements.
 Document the requirements for the new
business system:
• business process models;
• catalogue of business requirements;
• models of the IT processing and data;
• glossary of terms.

4/7/2021 Trang 43
 Summarize

Techniques
 Investigation techniques
 Requirements elicitation, analysis and
validation
 Requirements documentation and
management

4/7/2021 Trang 44
PHÂN TÍCH NGHIỆP VỤ
KINH DOANH

4/7/2021 45
 Exercises

Casestudy
Search 3 Requirement Managements
Software and make comparisons
between them

4/7/2021 Trang 46