CHAPTER 6 REQUIREMENTS ENGINEERING (RE)

󾠳

CHAPTER 6: REQUIREMENTS
ENGINEERING (RE)
⇒ Chủ động nắm bắt nhu cầu của khách hàng hơn là hỏi họ có yêu cầu gì cho phần
mềm.

RE process

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

1


Phương pháp tuần tự

Phương pháp lặp lại tăng dần thường áp dụng cho các dự án Agile.

Feasibility studies (Case khả thi)
Chúng ta sẽ nghiên cứu và quyết định có nên đầu tư vào dự án này hay không.

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

2


Một số cách nghiên cứu ngắn:
Hệ thống có đóng góp được gì cho mục tiêu ban đầu của tổ chức hay khơng.
Hệ thống có nên được phát triển dựa trên các cơng nghệ hiện có được hay
khơng.
Hệ thống có thể được tích hợp với các hệ thống khác được hay khơng.

Hệ thống có thể được phát triển trong phạm vi ngân sách và đúng tiến độ.
Hệ thống có cạnh tranh được với những hệ thống tương tự trên thị trường hay
không.

Interviews in practice
Phỏng vấn những người dùng tiềm năng.

Uses-case Diagrams
Chức năng: mơ hình hóa

Uses-case
Uses case miêu tả một loạt các hành động được thực hiện bởi actor để tạo ra kết
quả trực quan cho các actor khác.

Types of Use Case Relationships

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

3


Sự khác biệt giữa include và extend:
Include

Extend

Khi làm 1 case thì phải làm thêm 1 case

Khi làm 1 case thì có thể hoặc khơng phải

khác, khi kết hợp vào case chính thì

làm thêm 1 case khác khi kết hợp vào

mainflow của case include phải chung

case chính thì main flow của case extend

main flow của case chính.

là alternative flow của case chính.

Thu 23/06/2022

Requirements validation
Validation make sure the requirements reflect what the customer wants.
Những dự án mới khi cần đưa ra yêu cầu phần mềm thì chúng ta phải khảo sát, mị
mẫm như cầu của khách hàng chứ chúng ta thể nào phải ánh đúng yêu cầu của
người dùng.
Người ta sẽ làm những chức năng đơn giản, nhưng nội dung nhỏ để thăm dò thị
trường.
Đối với những dự án tin học lớn dành cho những cơ quan, trường học,… thì yêu
cầu phần mềm gần như đã rất rõ ràng.

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

4


Requirements checking

Validity: Tính đúng đắn của phần mềm.
Verifiability: Khả năng kiểm thử phần mềm.
Consistency: Phần mềm phải đồng nhất, hệ thống phải tương thích với các nền
tảng hiện có.
Completeness: Phần mềm có đáp ứng đủ yêu cầu hay chưa.
Realism: Phần mềm phải thực tế vì đơi khi khách hàng u cầu những chức
năng rất cao siêu, công nghệ hiện tại chưa có đủ khả năng đáp ứng.

Requirements reviews
Regular reviews cần được tổ chức trong khi xác định các yêu cầu.
Hình thức review có thể formal hoặc informal.
Các hình thức liên lạc hiệu quả có thể giúp cho việc giải quyết vấn đề có thể được
hồn thành từ những giai đoạn đầu.

Formal review process
Step:
1. Plan: What, Who, When, How, Why
2. Hold an overview meeting.
3. Each member reads and finds errors in requirements
4. Hold a review meeting/record errors.
5. Authors fix errors found.
6. Follow-up until all errors are fixed.

Informal review process
Gửi tài liệu cho các thành viên, ai phát hiện ra lỗi thì sửa.

Review Record
No

Title

Description

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

Severity (Độ nghiêm trọng)

5


Requirements Management
Một quá trình quản lý các thay đổi trong suốt quá trình làm đồ án.

Requirements change
Thay đổi thay xu hướng mới.
Thay đổi theo độ đáp ứng của công nghệ hiện tại.
Thay đổi theo độ ưu tiên.
Dựa trên các môi trường kỹ thuật của doanh nghiệp.

Requirements engineering processes
Common activies:
Requirements elicitation (rút trích, thu thập)
Requirements analysis (phân tích từ các dữ liệu khác nhau)
Requirements validation

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

6

Requirements managements

Feasibility studies (Case khả thi)
Đầu tư
Dựa vào những yêu cầu gì, thu thập thơng tin và viết các báo cáo.
Ai sử dụng ứng dụng này ? Thị trường ra sao ?
Công nghệ nào ?
Kĩ năng cần thiết ?
Thời gian, kế hoạch
Ngân sách

Requirements elicitation and analysis
Tìm hiểu về các ứng dụng trong lĩnh vực
Các dịch vụ mà hệ thống đó có thể cung cấp
Những ràng buộc vận hành
Tham gia bởi rất nhiều bên khác nhau

Problems of requirements analysis
Các stakeholders không biết những thứ họ cần
Stakeholders đưa ra những yêu cầu của riêng họ
Những xung đột về yêu cầu của các stakeholders
Các tổ chức và yếu tố chính trị ảnh hưởng
Thay đổi yêu cầu phần mềm (thay đổi luật, chính sách,…)

Process activities
Tìm ra các yêu cầu
Phân loại yêu cầu và tổ chức
Sắp xếp thứ tự ưu tiên và thương lượng

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

7


Ghi lại các yêu cầu

Requirements discovery
Thu thập dữ liệu
Các nguồn thơng tin khác nhau

Types of viewpoint
Interator viewpoints: Góc nhìn của người dùng tương tác trực tiếp với hệ thống
Indirect viewpoints: Góc nhìn tương tác gián tiếp
Domain viewpoints: góc nhìn của những người liên quan đến nghiệp vụ

Viewpoint identification
Dịch vụ hệ thống
Tiêu chuẩn quy định

Interviewing
Phỏng vấn những người dùng tiềm năng
Khám phá ra yêu cầu của khách hàng bằng cách phỏng vấn, xác nhận với người
dùng
Lắng nghe khách hàng
Không áp những u cầu mình muốn

Use Case Diagrams
Mơ hình hố u cầu phần mềm
Đặc tả yêu cầu phần mềm

Use Cases
Viết ra những hành động của Actors và cho ra những kết quả quan sát được

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

8


Description of Use Cases
Một chuỗi các dòng chảy sự kiện
Một dịng chảy chính (Main flow/Basic flow) và nhiều dịng chảy phụ (Alternative
flows)

Scenarios
Một trong những dòng chảy khả thi, xảy ra thực tế
User story = Scenario

Types of Use Case Relationship
Association
Generalization
Include: Khi làm 1 case thì phải làm thêm 1 case khác, khi kết hợp vào case
chính thì main flow của case include phải chung main flow của case chính
Extend: Khi làm 1 case thì có thể hoặc khơng phải làm thêm 1 case khác, khi kết
hợp vào case chính thì main flow của case extend là alternative flow của case
chính
Example: Khi login thì làm một relationship với một use case riêng để tránh login
dependency vào các use case khác, gây nên khó hiểu, nên có một pre-condition

Requirements validation
Reflect what the customer wants.

Error in requirements result problems in design, code and test.
Requirements error costs are high.
Fixing errors caused by incorrect requirements after delivery is much
higher than in early stages.

Requirements checking
Validity (Kiểm chứng, độ chính xác)

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

9


Mò mẫm những requirements ban đầu → Làm những features cơ bản → Dị
thị trường.
Khơng phản ánh đúng thị trường, fail.
Verifiability (Khả năng kiểm thử phần mềm)
Yêu cầu phải cụ thể
Consistency (Đồng nhất)
Các u cầu có conflict.
Conpleteness (Độ hồn thiện)
Tất cả các u cầu có hồn thiện.
Realism (Thực tế)
Cài đặt được, chạy được trên thực tế
Rất khó vì nhiều u tố ảnh hưởng

Requirement validation techniques
Requirements reviews
Most common approach
Manual analysis of the requirements

Prototyping
Using an executable model
Test-case generation
Check testability

Requirements reviews
Requirements are defined
Requirements analysts, designers, developers, testers
May be formal (Strict reviews) or informal (Many ways to reviews: send
documents, share docs to fix immediately, walkthrough the docs and feedback)
Resolve problems at an early stage

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

10


Formal review process
Được xác định bởi công ty
1. Plan: what, who (Moderator, Authors, Reviewers), when, how, why
2. Hold an overview meeting
3. Each member reads and finds errors in requirements
4. Hold a review meeting/record errors
5. Authors fix errors found
6. Follow-up until all errors are fixed

Review Record

Requirements management
Process of managing changing requirements during the project

Requirements change
New and changed business needs
Better understanding
Priority from different viewpoints changes
Business and technical environments change

Requirements change management

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

11


Change request
Change analysis and costing
Change implementation

Key points
Feasibility study, requirements elicitation and analysis, requirements specification
and requirements management.

CHAPTER 6: REQUIREMENTS ENGINEERING (RE)

12