Insert or Drag and Drop your Image

PHÂN TÍCH VÀ ĐẶC TẢ YÊU
CẦU
Jens Martensson


NỘI DUNG
1.

Tổng quan

2.

Q rình phân tích

3.

Xác định u cầu

4.

Mơ hình hóa yêu cầu hệ thống

Jens Martensson

2


2.1. Tổng quan và đặc tả u cầu
•

Gồm các cơng đoạn:
•

Nghiên cứu tính khả thi

•

Phân tích mơ hình

•

Đặc tả u cầu.

•

Được phối hợp giữa nhóm phát triển phần mềm và khách hàng

•

Yêu cầu của khách hàng được thu thập đầy đủ và chi tiết

•

Cơng cụ: các loại sơ đồ biểu diễn được các khái niệm và mơ hình hóa được mối quan hệ giữa các đối
tượng trong hệ thống.

Jens Martensson

3



2.2. Q trình phân tích
Bao gồm các bước phân tích:
ü

Phân tích phạm vi dự án

ü

Phân tích mở rộng yêu cầu nghiệp vụ

ü

Phân tích yêu cầu bảo mật

ü

Phân tích yêu cầu tốc độ

ü

Phân tích yêu cầu vận hành

ü

Phân tích khả năng mở rộng yêu cầu

ü


Phân tích yêu cầu sẵn dùng

ü

Phân tích yếu tố con người

ü

Phân tích yêu cầu tích hợp

Jens Martensson

4


2.2. Q trình phân tích

Jens Martensson

5


2.2.1 Phân tích phạm vi dự án
•

Xác định rõ q trình nghiệp vụ mà phần mềm sẽ xử lý.

•

Một giải pháp nghiệp vụ gồm:


•

Phần triển khai phần mềm: Trong đó yêu cầu nghiệp vụ của
khách hàng được hiện thực hóa thành phần mềm cụ thể,

•

Phần thực hiện bởi con người hay chương trình: Là giai
đoạn vận hành sử dụng hệ thống

Jens Martensson

6


2.2.1 Phân tích phạm vi dự án
•

Mục đích của việc chia giải pháp nghiệp vụ thành 2 phần là:
•

Chia trách nhiệm thành những nhiệm vụ con tương ứng với việc chia
chương trình thành các module.

•

Xác định bao nhiêu vùng địa lý liên quan (chi nhánh văn phịng),

•


Ước lượng số người dùng phần mềm, thời gian phần mềm được duy trì,

•

Biết được tính chính xác của u cầu phần mềm,

•

Hiểu khách hàng mong đợi dự án được triển khai

•

Xác định được phạm vi của dự án, dự đoán ngân sách, thời gian và nguồn
nhân lực.

Jens Martensson

7


2.2.2 Phân tích mở rộng u cầu nghiệp vụ
•

Xác định u cầu nghiệp vụ:

•

Mỗi dự án sẽ có một hay nhiều yêu cầu nghiệp vụ (tác vụ) liên
quan đến việc mơ tả cơng việc cụ thể trong nghiệp vụ.


•

Một tác vụ có thể được chia nhỏ thành nhiều phần đủ để mơ tả
cơng việc chính xác nhất.

Jens Martensson

8


2.2.2 Phân tích mở rộng yêu cầu nghiệp vụ

Jens Martensson

9


2.2.2 Phân tích mở rộng u cầu nghiệp vụ
•

Xác định u cầu chất lượng:

•

Mỗi dự án có các u cầu liên quan đến khả năng đáp ứng
nhanh, bảo mật, phụ thuộc, dễ dùng …

•


Chất lượng của dự án là trên mức độ chấp nhận, và sự thỏa
mãn nhu cầu của khách hàng.

Jens Martensson

10


2.2.2 Phân tích mở rộng u cầu nghiệp vụ
•

Phân tích cơ sở hạ tầng hiện hành:
•

Giải pháp PM đưa vào, nếu phù hợp với cơ sở hạ tầng thì sẽ tốt hơn là thay thế hệ thống hiện hành.

•

Sự tương thích với cơ sở hạ tầng hiện hành sẽ đảm bảo khả thi, vì dự án cần làm việc trên phần cứng và phần mềm hiện có.

•

Nếu biết được HĐH, loại mạng đang sử dụng, thơng tin cấu hình của máy chủ, và những phần mềm khơng tương thích với
chương trình mới thì sẽ giúp việc phân tích chính xác và hiệu quả hơn.

Jens Martensson

11



2.2.2 Phân tích mở rộng u cầu nghiệp vụ
•

Phân tích ảnh hưởng kỹ thuật:
•

Nâng cấp, mở rộng chức năng cho hệ thống hiện hành hoặc thay mới. Tuy nhiên, cải thiện hệ thống cũ và tích hợp dễ dàng
hơn hệ thống mới.

•

Ví dụ: hệ thống kế tốn cũ lưu trữ dữ liệu trên MS Access. Khi nâng cấp hệ thống, có thể chuyển tồn
bộ dữ liệu sang SQL Server.

Jens Martensson

12


2.2.2 Phân tích mở rộng u cầu nghiệp vụ
•

Phân tích ảnh hưởng kỹ thuật:
•

Nên tìm hiểu sự khác biệt về giao tác, bảo mật, và những chức năng khác.

•

Nên tìm hiểu thủ tục chuyển đổi dữ liệu từ hệ thống cũ sang hệ thống mới, có kế hoạch bảo lưu khi việc thực hiện này bị lỗi.


•

Cần có biện pháp đảm bảo an toàn những dữ liệu.

Jens Martensson

13


2.2.3. Phân tích u cầu bảo mật
•

•

Xác định các vai trò người dùng của hệ thống: Một hệ thống phần mềm có nhiều mức độ bảo mật
•

Người dùng cuối: chỉ cần quyền truy xuất giới hạn.

•

Quản trị hệ thống: có quyền cao nhất.

Xử lý bảo mật phần mềm là kỹ thuật dùng để cấp quyền sử dụng với mức độ bảo mật khác nhau.

Jens Martensson

14



2.2.3. Phân tích u cầu bảo mật
•

Xác định mơi trường bảo mật phần mềm
•

Người dùng phải đăng nhập vào hệ thống để thực hiện các chức năng theo quyền được cấp, nhằm để kiểm soát quyền truy
cập các tài nguyên được chia sẽ như tập tin, dịch vụ hệ thống, CSDL.

•

Mức độ kiểm sốt của phần mềm được gọi là ngữ cảnh bảo mật.

•

Độ bảo mật của phần mềm khơng bị giới hạn bởi người dùng.

Jens Martensson

15


2.2.3. Phân tích u cầu bảo mật
•

Xác định ảnh hưởng bảo mật:
•

Nếu hệ thống cũ có sẵn cơ chế bảo mật, thì hệ thống mới nên điều chỉnh cho phù hợp với cơ chế đã có.


•

Nếu đang thực hiện hệ thống bảo mật mới, cần phân tích tác động của hệ thống trên hệ thống hiện tại:
•

Hệ thống mới có làm hỏng chức năng của phần mềm hiện tại?

•

Hệ thống mới có địi hỏi phải hỗ trợ thêm đăng nhập mở rộng?

•

Hệ thống mới có hạn chế một số người dùng những tài nguyên mà họ
được quyền truy cập trước đây?

Jens Martensson

16


2.2.3. Phân tích u cầu bảo mật
•

Kế hoạch vận hành:
•

Khi tổ chức của khách hàng thay đổi nhân sự. Những thao tác này địi hỏi hiệu chỉnh bảo mật CSDL.


•

Nếu người dùng có nhiều vị trí khác nhau, cần lên kế hoạch tái tạo bảo mật CSDL đã được lưu giữ ở các vị trí khác nhau, nhằm
tạo thuận lợi cho người dùng là có thể đăng nhập bằng thơng tin được lưu ở vị trí gần hơn so với vị trí gốc.

Jens Martensson

17


2.2.3. Phân tích u cầu bảo mật
•

Kế hoạch kiểm sốt và đăng nhập:
•

File nhật ký giao dịch trợ giúp kiểm soát hoạt động cho vấn đề bảo mật, ghi lại tất cả các giao dịch trên hệ thống.

•

Phải lập kế hoạch kiểm soát nhật ký để phát hiện các giao dịch bất thường, và có đề nghị xử lý.

Jens Martensson

18


2.2.3. Phân tích u cầu bảo mật
•


Xác định mức độ yêu cầu bảo mật
•

Việc triển khai mức độ bảo mật cho phần mềm cần được cân nhắc dựa trên tính hiệu quả và chi phí.

•

Nếu hệ thống khơng lưu trữ dữ liệu có tính nhạy cảm cao, thì chỉ cần lưu trữ thông tin về “sự xác thực của người dùng”.

•

Nếu hệ thống có lưu trữ các thơng tin cần bảo mật, thì cần có chi phí cho chức năng bảo mật và cần phải được kiểm chứng.

Jens Martensson

19


2.2.4. Phân tích u cầu tốc độ
•

u cầu về tốc độ xử lý của phần mềm: là một yêu cầu khó đối với nhóm phát triển phần mềm.

•

Tốc độ xử lý của phần mềm là sự đáp trả của hệ thống đối với
thao tác của người dùng.

•


Tốc độ của phần mềm phụ thuộc vào việc thiết kế hệ thống.

•

Đối với phần mềm phân tán, tốc độ xử lý của phần mềm còn
tùy thuộc vào số người truy cập vào hệ thống tại cùng một thời
điểm.

Jens Martensson

20


2.2.4. Phân tích u cầu tốc độ
•

Các yếu tố ảnh hưởng đến tốc độ của phần mềm
•

Tần suất giao dịch: số người sử dụng dịch vụ tại một thời điểm.

•

Băng thông: là một yếu tố ảnh hưởng đến tốc độ của phần mềm.

•

Khả năng chứa: Mức lưu trữ (bộ nhớ chính, phụ) khả năng sẵn sàng đáp ứng.

•


Nút thắt: tốc độ ổ cứng là nút thắt. Cần nhận biết nút thắt của để cải thiện chúng nhằm nâng cao tốc độ. Việc nhận biết nút thắt
có thể thực hiện bằng công cụ báo cáo hệ thống Windows NT Performance Monitor.

Jens Martensson

21


2.2.5. Phân tích u cầu vận hành
•

Khi vận hành phần mềm, chi phí triển khai và chi phí vận hành là vấn đề quan trọng cần được xem
xét như sau:
•

Chi phí triển khai có thể giảm nếu phân phối trực tuyến hoặc phần mềm tự động cài đặt, và thao tác vận hành có thể tự động
hóa.

•

Nếu phần cứng, phần mềm là thành phần được mua, không được phát triển, thì chấp thuận vận hành từ nhà xưởng hay người
ủy thác của sản phẩm.

•

Vận hành sản phẩm trung gian sẽ tiết kiệm chi phí thuê nhân viên mới hay huấn luyện nhân viên cũ để duy trì một hay nhiều
thành phần của hệ thống

Jens Martensson


22


2.2.6. Phân tích khả năng mở rộng u cầu
•

•

Theo thời gian, những yêu cầu của giải pháp ban đầu sẽ thay đổi. Nhu cầu của người dùng cũng
thay đổi. Do đó địi hỏi phần mềm cũng phải được mở rộng và cập nhật theo các yêu cầu thay đổi.
Phần mềm thiết kế tốt là phần mềm có khả năng mở rộng được và có thể uyển chuyển cải thiện mà
khơng phải xây dựng lại hoàn toàn.

Jens Martensson

23


2.2.6. Phân tích khả năng mở rộng u cầu
•

Cách đạt đến những khả năng hạn định:
•

Lưu trữ thơng tin và quy tắc nghiệp vụ vào cơ sở dữ liệu

•

Khi chức năng hay thủ tục của phần mềm cần thay đổi, thì thay đổi trong cơ sở dữ liệu mà khơng cần thay đổi mã nguồn

chương trình.

•

Đặt mã nguồn vào trong đoạn mã kịch bản (script) được làm rõ hơn khi biên dịch chương trình; đoạn script có thể bị thay đổi
một cách dễ dàng khơng địi hỏi bất kỳ biên dịch hay cài đặt lại tập tin nhị phân.

•

Chia phần mềm thành những đối tượng thành phần với nhiệm vụ riêng lẻ.

•

Nếu yêu cầu của các nhiệm vụ thay đổi, thì chỉ đối tượng tương ứng bị thay đổi và biên dịch lại mà không ảnh hưởng đến các
thành phần khác.

Jens Martensson

24


2.2.7. Phân tích u cầu sẵn dùng
•

Phần mềm có tính sẵn sàng cao là những phần mềm không lỗi, không phát sinh các hỏng hóc. Khi
một thành phần nào bị hỏng thì chỉ cần khởi động lại sẽ hoạt động bình thường.
•

Việc bảo trì có kế hoạch cũng tác động đến tính sẵn sàng của phần mềm.


•

Một máy chủ chứa các phần mềm lý tưởng ln có bản sao lưu có thể khởi động khi máy chủ bảo trì.

•

Phần mềm có độ sẵn sàng cao cần có cách luân phiên để kết nối mạng trong trường hợp mạng WAN, LAN ngưng hoạt động.

Jens Martensson

25