1

Quản trị yêu cầu

Tham khảo: GeekCorps 2004

9/18/2006 Requirement Management 2

Giới thiệu� Một trong những hoạt động đầu tiên � Mục tiêu: tìm cái cần xây dựng� Giao tiếp giữa người dùng và người phát triển, vì vậy

� Không có ý hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn)

� Thường dùng ngôn ngữ tự nhiên� Hợp đồng

� Các cách thức để xác định yêu cầu� Các cách thức để chuẩn hóa yêu cầu

� Scenarios, Use Cases, Mockups / Prototypes, Feature Lists

� Stakeholders� Những người quan tâm đến sản phẩm

2

Thế nào là quản trị yêu cầu ?

9/18/2006 Requirement Management 4

Thế nào là quản trị yêu cầu ?

� Là tiến trình tìm hiểu, sưu liệu và quản lý các yêu cầu.

� Sử dụng những kỹ thuật mang tính hệ thống để đảm bảo yêu cầu:� Complete (đầy đủ)� Consistent (nhất quán)� Relevant (thích đáng)

3

9/18/2006 Requirement Management 5

Thế nào là quản trị yêu cầu?

� Diễn tả bằng văn xuôi,� Tìm hiểu cái người dùng muốn

� Tổ chức thông tin này lại� Sưu liệu thông tin này� Theo vết thay đổi thông tin này� Quản lý tất cả thay đổi

� Đáp ứng nhu cầu người dùng cuối

� Thiết lập quy trình và thực hiện theo nó

9/18/2006 Requirement Management 6

Thế nào là quản trị yêu cầu?

� Hầu hết các tổ chức phát triển phần mềm đều làm việc này theo những cách thức khác nhau.

� Nhưng thường chúng không mang tính hình thức và mang tính không thống nhất từ dự án này qua dự án khác

� CMM Level 1 vs. CMM Level 2 = Định nghĩa được tiến trình quản lý yêu cầu

4

Thế nào là một yêu cầu?

9/18/2006 Requirement Management 8

Thế nào là một yêu cầu ?

� Là một khả năng của phần mềm được người dùng yêu cầu, để giải quyết một vấn đề nhằm đạt một mục tiêu nào đó.

� Thành công của dự án = sự thỏa mãn các nhu cầu.

5

9/18/2006 Requirement Management 9

Nguồn của yêu cầu: khách hàng� Phỏng vấn khách hàng

� Người trả tiền cho chúng ta� Những stakeholders

� Người sử dùng� Người quản lý

� Vấn đề:� Khách hàng có thể không biết họ muốn gì

� Phần mềm là một khái niệm trừu tượng và phức tạp� KH có thể thay đổi ý kiến� KH không có khả năng diễn tả nhu cầu theo những thuật ngữ chuyên

môn� Giao tiếp giữa người chuyên làm mềm <> người bình thường

� Các kỹ thuật� Giao diện� Hệ thống đã tồn tại

9/18/2006 Requirement Management 10

Nguồn của yêu cầu: thị trường

� Đánh giá các sản phẩm cạnh tranh� Những gì trước đây đã được thực hiện ?� Nơi nào là nơi thích hợp cho chúng ta ?� Nhưng, lưu ý tới vấn đề bản quyền, thương hiệu, bằng sáng chế …

� Tự đánh giá khả năng của chúng ta� Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh ?� Những kiến thức, kỹ năng, ý tưởng mà chúng ta có ?

� Khảo sát thị trường� Phỏng vấn khách hàng (cũ, tiềm năng,…)� Lưu ý tới những quảng cáo: tạo ra nhu cầu thị trường� Quan tâm đến xu hướng phát triển của thị trường

� Vấn đề:� Người ta không biết cái người ta muốn là gì ?

� Ví dụ: video telephones� Thị trường thay đổi nhanh chóng� Bảo mật ý tưởng

6

9/18/2006 Requirement Management 11

Nguồn của yêu cầu:các chuẩn� Các chuẩn và các hệ thống chuyển đổi

� system standards, file formats, network protocols� usability standards� domain standards

� Official standards� written by a standards body

� ANSI� ISO (e.g. Unicode)� IEEE (e.g. Posix)

� Industry standards� Wintel Platform� Java, Dot-Net� Wimp user interface� WAMP, LAMP

9/18/2006 Requirement Management 12

Các loại yêu cầu

� Chức năng� features� user interface� input / output

� Phi chức năng� Hướng người dùng

� performance� precision� reliability

� Hướng người phát triển� maintainability� reusability� interoperability

7

Những vấn đề trong quản trị yêu cầu ?

9/18/2006 Requirement Management 14

Vấn đề� Nhiều hệ thống thường

� chuyển giao trễ, và vượt ngân sách cho phép� Không đáp ứng đầy đủ yêu cầu của người dùng� Không hoạt động hiệu quả

� Bước đầu tiên để giải quyết vấn đề� � xác định nguyên nhân cốt lõi

� Ví dụ về những nguyên nhân cốt lõi� Thiếu dữ liệu người dùng� Yêu cầu và đặc tả không đầy đủ� Yêu cầu và đặc tả thay đổi

8

9/18/2006 Requirement Management 15

Tăng chi phí do yêu cầu sai hoặc thiếu sót

0.1

0.5

1

2

5

20

Requirements

Design

Maintenance

Acceptance Testing

Unit Testing

Coding

Tỷ lệ chi phí để sửa chưa theo từng giai đoạn

9/18/2006 Requirement Management 16

Ảnh hưởng của các vấn đề:

� Tái đặc tả� Redefine requirements again

� Tái thiết kế� Change models and dependencies

� Lập trình lại� Re-write code

� Test lại� Change test plan, test case, retest

� Thêm thời gian/nổ lực/tài nguyên:� Vứt sản phẩm � Khách hàng giận dữ� Tăng chi phí bảo trì

� Tài liệu cho phần thay đổi…

9

Thế nào là quản trị yêu cầu tốt ?

9/18/2006 Requirement Management 18

Quản trị yêu cầu tốt

� Ngăn:� Vượt chi phí và thời gian� Hủy dự án

� Một dự án thành công cần có các yếu tố:� Sự quan tâm của người dùng� Hỗ trợ của người quản lý� Yêu cầu rõ ràng

10

9/18/2006 Requirement Management 19

Chất lượng của yêu cầu: tính ổn định

� Ổn định� Không có mâu thuẩn� Chương trình sẽ không thể hoạt động nếu yêu cầu mâu thuẩn

� Khó đảm bảo vì� Số lượng yêu cầu lớn� Mâu thuẩn tiềm ẩn

� Ví dụ:� Section 1.2 says: “no more than 128MB of memory needed”� Section 5.8.9 says: “images should be rendered in real time”=> Có mâu thuẩn không ???

� Bản chất vấn đề: mâu thuẩn có thể dẫn tới mọi thứ…� Vấn đề:

� Khó giải thích mâu thuẩn cho khách hàng� Khách hàng muốn những thứ không thể

9/18/2006 Requirement Management 20

Chất lượng của yêu cầu: có thể quản lý được� Tài nguyên phải có thể đáp ứng các yêu cầu

� Có thể làm đúng thời gian ?� Với chi phí cho phép ?� Trong khả năng (kỹ năng) có thể?

� Quản lý rủi ro� Xếp độ ưu tiên các yêu cầu� Phải có thay thế nếu cái chính không hoạt động� Mở ra những vấn đề không thể để nói về những yêu cầu có

thể làm� Quản lý độ phức tạp

� Đừng làm mọi thứ cùng 1 lúc� Quy trình lập� prototyping

11

9/18/2006 Requirement Management 21

Chất lượng của yêu cầu: sự đặc tả� Càng chính xác và chi tiết càng tốt� Không tốt:

� “program shall be fast”� “it takes a number as input”

� Tốt:� “the program shall give a response in less than 1s”� “it takes a 16-bit signed integer as input”

� Những định nghĩa� Luôn là những ý tưởng tốt� Ví dụ: “by 'Number', we always mean a 16-bit signed integer”� Định nghĩa những thuật ngữ chuyên môn, viết tắt

� Quy tắc định nghĩa� Không định nghĩa xoay vòng (phụ thuộc)

9/18/2006 Requirement Management 22

Chất lượng của yêu cầu: không thiên vềcài đặt� Thiên về cài đặt:

� Đưa thông tin về thiết kế� Đưa thông tin về mã nguồn

� Sự dụng những thuật ngữ chuyên môn� Không dùng những từ chuyên môn kỹ thuật� Bạn muốn tập trung vào CÁI GÌ� Bỏ LÀM THẾ NÀO lại phần sau

� Ví dụ không tốt� “store the checked-out books in an array”� “calculate the square root with Newton's algorithm”

� Ví dụ Tốt:� “the library knows which books are checked out”� “return the square root with 5-digit precision”

12

9/18/2006 Requirement Management 23

Đội ngũ phát triển phần mềm

� Quản lý yêu cầu đụng đến từng cá nhân trong đội ngũ phát triển

� Nếu nhóm xác định yêu cầu làm việc tốt �ảnh hưởng đến kết quả của toàn nhóm phát triển dự án

Những kỹ năng để xác định yêu cầu ?

13

9/18/2006 Requirement Management 25

Những kỹ năng

� Sáu kỹ năng cần thiết:� Phân tích vấn đề

� Hiểu nhu cầu người dùng� Định nghĩa được hệ thống� Quản lý được phạm vi� Tinh lọc hệ thống

� Xây dựng đúng hệ thống cần thiết

Những kỹ năng làm việc ?

14

9/18/2006 Requirement Management 27

Các kỹ năng

� Giao tiếp� Phân tích/Suy luận

� Diễn giải� Lập báo cáo� Trình diễn

9/18/2006 Requirement Management 28

Những nhóm liên quan:� Account Manager

� Gặp mặt� Giới thiệu mục đích chung, giới thiệu về tổ chức kinh doanh…� Giới thiệu đội ngũ lấy yêu cầu cho đối tác khách hàng

� Facilitator � Project Manager

� Định nghĩa lịch làm việc� Giữ cho cuộc hợp luôn đi đúng hướng� Quản lý và đàm phán với khách hàng

� Note Taker� Chịu trách nhiệm ghi nhận/nắm bắt các yêu cầu

� Project Manager/Team Member� Domain Experts/Team Leads

� Technical Architect� Software Lead� UI designer� Area Specialists (Expert on Platform X, Feature Y etc)

15

9/18/2006 Requirement Management 29

Key Stakeholders:

� System End-users (người dùng cuối)� Những người sẽ dùng hệ thống sau khi phát triển

� Customer � Những yêu cầu của họ phải được thỏa mãn

� Domain experts� Cung cấp thông tin nền tảng, chuyên biệt cho việc xây dựng hệ thống

� Project Manager� Quản lý tiến trình lấy yêu cầu. Đảm bảo tính đầy đủ của yêu cầu� Thương lượng, đàm phán giữa các stakeholders

� Software engineers� Chịu trách nhiệm phát triển hệ thống

� QA Test Engineer� Chịu trách nhiệm kiểm chứng hệ thống để đảm bảo chất lượng

9/18/2006 Requirement Management 30

Chi phí cho việc xác định yêu cầu ?

16

9/18/2006 Requirement Management 31

Chi phí cho việc xác định yêu cầu ?

� Chi phí dự án:� Chiếm từ 15% đến 30% kinh phí toàn dự án

� Khi bỏ ra càng nhiều thời gian cho công đoạn xác định yêu cầu, chúng ta sẽ tiết kiệm thời gian cho:� Thiết kế� Triển khai� Kiểm chứng

9/18/2006 Requirement Management 32

Qui trình lấy yêu cầu

Requirements

eli citation

Requirements

anal ysis and

negotiation

Requirements

documentationRequirements

val idati on

Requirements

document

User needsdomain

i nformation,

exi sti ng system

information,

regulations,

standards, etc.

Agreed

requirementsSystem

specifi cation

17

9/18/2006 Requirement Management 33