CÔNG NGHỆ PHẦN MỀM

Phân tích và đặc tả yêu cầu

Nội dung
I. Đại cương về phân tích và đặc tả yêu cầu
II. Các loại yêu cầu
III. Xác định và đặc tả yêu cầu
IV. Thẩm định yêu cầu
V. Các phương pháp đặc tả yêu cầu
I. Đại cương
Phân tích yêu cầu là khâu kỹ thuật đầu tiên
Bên phát triển và khách hàng phối hợp thực hiện
Tìm hiểu xem cần làm gì
II. Các loại yêu cầu
Yêu cầu chức năng
Mô tả các chức năng (dịch vụ) mà phần mềm sẽ cung
cấp. Gồm
Yêu cầu chức năng nghiệp vụ
Công việc có thật trong thế giới thực, có 4 loại
nghiệp vụ thông dụng trong các lĩnh vực: lưu trữ,
tra cứu, tính toán, kết xuất
Yêu cầu chức năng hệ thống
Công việc phát sinh do sử dụng máy tính như:
phân quyền, sao lưu/phục hồi, cấu hình, báo động
nhắc nhở.
Các loại yêu cầu (tt)
Yêu cầu phi chức năng
Các ràng buộc về chất lượng, môi trường,
chuẩn sử dụng, qui trình phát triển…
Đặc thù theo từng khách hàng do đó rất khó
phân tích
Ví dụ:
Yêu cầu về sản phẩm
Yêu cầu của tổ chức

Yêu cầu ngoài

Các loại yêu cầu (tt)
• Yêu cầu phi chức năng
III. Xác định và Đặc tả yêu cầu
Qui trình xác định yêu cầu (tt)
Mục tiêu của quy trình xác định yêu cầu là đưa ra
các tài liệu yêu cầu của hệ thống.
Quy trình xác định yêu cầu biến đổi phụ
thuộc vào miền ứng dụng, con người và tổ chức
xây dựng yêu cầu.
Tuy nhiên, những quy trình này vẫn có chung
một số hoạt động sau: phát hiện yêu cầu, phân
tích yêu cầu, đánh giá yêu cầu và quản lý yêu
cầu.
Qui trình xác định yêu cầu (tt)
Trong thực tế, các yêu cầu luôn luôn thay
đổi, thậm chí ngay khi đang xây dựng hệ thống.
Người ta thường sử dụng mô hình xoắn ốc để xác
định các yêu cầu.
Qui trình xác định yêu cầu (tt)
Quy trình thu thập và phân tích
yêu cầu
Quy trình thu thập và phân tích yêu
cầu
Thu thập yêu cầu (Requirements discovery)
Phải trao đổi với khách hàng thu thập hết các yêu cầu của họ.
Phân loại và quản lý yêu cầu (Requirements
classification and organisation)
Tổ chức phân loại, gom nhóm các yêu cầu sao cho dễ quản lý.
Sắp xếp và điều chỉnh yêu cầu (Prioritisation and
negotiation)
Sắp xếp thứ tự các yêu cầu và điều chỉnh các yêu cầu mâu
thuẫn.
Đặc tả yêu cầu (Requirements specification)
Đặc tả (Tài liệu hóa) các yêu cầu để chuyển qua giai đoạn kế
tiếp.
Các phương pháp thu thập yêu cầu
Chiến lược thu thập
 Gồm các yếu tố sau:
Các nguồn thông tin thu thập.
Các phương pháp áp dụng cho mỗi nguồn thông tin.
Các khó khăn
Khách hàng chỉ có khái niệm mơ hồ
Khách hàng hay thay đổi yêu cầu
Các yêu cầu có tính đặc thù
Hệ thống nhiều người dùng
Người đặt hàng có thể khác người dùng thật sự
Các phương pháp thu thập (tt)
Các nguồn thu thập
Các người dùng hệ thống.
Các sổ sách, tài liệu.
Các chương trình máy tính.
Các tài liệu mô tả quy trình, nghiệp vụ.
Các thông báo, biểu mẫu.
Các phương pháp thu thập (tt)
Phương pháp thu thập
 Nghiên cứu tài liệu
 Quan sát
 Phỏng vấn
 Bảng câu hỏi
 Làm bản mẫu
Các phương pháp thu thập (tt)
Nghiên cứu tài liệu
 Đây là một sự quan sát gián tiếp, giúp cho người
phân tích nắm được những quy trình hoạt động.
 Thông qua việc nghiên cứu:
 Các chứng từ giao dịch
 Các sổ sách
 Các tài liệu tổng hợp
 Việc nghiên cứu tài liệu thường kết hợp với phỏng
vấn ở mức thấp (mức thao tác, thừa hành)
Các phương pháp thu thập (tt)
Quan sát
 Quan sát trực tiếp tại nơi làm việc một cách thụ
động
 Có thể nhìn thấy các chức năng được thực hiện như
thế nào.
 Thường mất nhiều thời gian (Có thể quay phim ?!)
 Người bị quan sát thường khó chịu do đó cần sự hợp
tác của mọi người.
Các phương pháp thu thập (tt)
Phỏng vấn
 Tổ chức phỏng vấn các nhân viên trụ cột tại các
mức trong tổ chức
 Mang tính nghệ thuật (kinh nghiệm) hơn là kỹ
thuật
 Phải có 1 mục đích rõ ràng khi phỏng vấn
 Phải xác định những TT còn thiếu cần phỏng
vấn
 Phải tìm hiểu thuật ngữ kỹ thuật của người
được phỏng vấn
 Phải phác thảo danh sách các câu hỏi cần phỏng
Các phương pháp thu thập (tt)
 Câu hỏi trong phỏng vấn
 Câu hỏi mở và câu hỏi đóng
 Trật tự các câu hỏi:
 Thu hẹp dần: từ những câu hỏi khái quát 
tập trung vào một chủ điểm, chi tiết nhất định
 Mở rộng dần: ban đầu đề cập một vài việc cụ
thể  mở rộng dần phạm vi
Các phương pháp thu thập (tt)
 Khi phỏng vấn
 Cần trình bày mục tiêu của buổi phỏng vấn
 Cố gắng đặt người phỏng vấn vào trạng thái thoải
mái
 Tóm tắt những điểm mà người được phỏng vấn đã
trình bày
 Giải thích mục đích của việc ghi chép và ghi âm nếu sử
dụng
 Phỏng vấn ngắn gọn, chỉ kéo dài trong 20–30 phút
 Tóm tắt những điểm chính vào cuối cuộc phỏng vấn
 Đăng ký phỏng vấn với người sẽ được phỏng vấn tiếp
theo.
Các phương pháp thu thập (tt)
 Hạn chế của phỏng vấn
 Người được phỏng vấn có thể từ chối hợp tác
 Người phỏng vấn có thể không hiểu được một
số thuật ngữ chuyên môn.
Các phương pháp thu thập (tt)
Bảng câu hỏi
 Là phương pháp phổ biến trong thống kê
 Là hình thức phỏng vấn không giáp mặt
 Thích hợp khi chi phí để phỏng vấn nhiều
người là cao.
 Các câu hỏi đơn giản, tỷ lệ trả lời không cần
cao
 Để xác nhận số liệu thu thập được từ nơi
khác
Các phương pháp thu thập (tt)
 Hạn chế của phiếu thu thập
 Người trả lời khó tránh hiểu nhầm trong
trả lời
 Chỉ cung cấp thông tin ngắn gọn
 Tỷ lệ trả lời bảng câu hỏi thường thấp
 Người đưa ra câu hỏi phải hiểu biết nhiều
thông tin về hệ thống
Các phương pháp thu thập (tt)
 Trong quá trình thiết kế phiếu thu thập nên:
 Đưa ra những câu hỏi đơn giản, rõ ràng,
không thiên lệch
 Dạng câu hỏi có nhiều lựa chọn (câu hỏi
đóng)
 Có ý tưởng rõ ràng về thông tin mà phiếu yêu
cầu
 Đảm bảo câu hỏi ở mức hiểu và trong phạm
vi quan tâm của người trả lời
 Tránh dạng câu hỏi rẽ nhánh
Làm bản mẫu
Dùng để thu thập và thẩm định yêu cầu của người sử
dụng.
Các bước làm bản mẫu
1. Đánh giá yêu cầu phần mềm và xác định liệu
phần mềm cần xây dựng có xứng đáng để làm
bản mẫu không.
2. Với một dự án chấp thuận được, người phân tích
xây dựng một cách biểu diễn vắn tắt cho yêu cầu..
3. Sau khi đã duyệt xét mô hình yêu cầu, tạo ra một
đặc tả thiết kế vắn tắt cho bản mẫu.
Các bước làm bản mẫu (tt)
4. Phần mềm bản mẫu đựợc tạo ra và kiểm
thử.
5. Khách hàng đánh giá và làm mịn yêu cầu.
6. Lặp lại các bước 4 và 5 cho tới khi tất cả
các yêu cầu đã được thu thập đầy đủ và
chính xác.
Lợi ích của làm bản mẫu
 Đội ngũ phát triển phần mềm có thể tìm ra
đựơc các yêu cầu không đầy đủ hoặc
không kiên định khi họ phát triển bản mẫu
 Sự hiểu lầm giữa khách hàng và nhà phát
triển có thể được nhận thấy rõ khi các chức
năng của hệ thống được trình diễn.
 Vấn đề thiếu sót các yêu cầu người dùng,
tính dễ sử dụng có thể được thấy ngay.
Hạn chế của làm bản mẫu
 Các đặc điểm hệ thống quan trọng có thể nằm
ngoài bản mẫu.
 Các yêu cầu phi chức năng như độ tin cậy, tính
mâu thuẫn và độ an toàn không được biểu thị đầy
đủ trong bản mẫu.
 Do tính chưa hoàn thiện (về chức năng/hiệu
năng), người dùng có thể không dùng bản mẫu y
như cách dùng một hệ thống thực đang hoạt
động.
 Chi phí cao nếu không tận dụng được các bản
mẫu.
Đặc tả yêu cầu
Các yêu cầu thu thập được phải đường trình bày lại
sao cho:
Rõ ràng và dễ hiểu đối với khách hàng (dễ thuyết phục ký
kết hợp đồng)
Đầy đủ và chi tiết vì đây là nguồn thông tin duy nhất dành
cho nhóm thiết kế.
Do đó việc đặc tả chính xác yêu cầu rất quan trọng
Có 2 phương pháp sau:
Phi hình thức: Dùng ngôn ngữ tự nhiên
Hình thức: Hình ảnh, biểu đồ
Đặc tả yêu cầu (tt)
Tài liệu đặc tả yêu cầu
Tài liệu đặc tả yêu cầu là những yêu cầu
chính thức về những gì cần phải thực hiện bởi
đội phát triển hệ thống.
Tài liệu đặc tả yêu cầu nên bao gồm cả các định
nghĩa về yêu cầu của người sử dụng và yêu cầu hệ
thống.
Tài liệu đặc tả yêu cầu không phải là tài liệu thiết
kế hệ thống. Nó chỉ thiết lập những gì hệ thống
phải làm, chứ không phải mô tả rõ làm như thế
nào.
Đặc tả yêu cầu (tt)
Cấu trúc tài liệu đặc tả yêu cầu (IEEE 830)
1. Giới thiệu
1.1. Mục đích của tài liệu yêu cầu
1.2. Phạm vi của sản phẩm
1.3. Các định nghĩa, từ viết tắt
1.4. Các tham chiếu
1.5. Mô tả cấu trúc tài liệu
Đặc tả yêu cầu (tt)
2. Mô tả chung
2.1. Giới thiệu chung về sản phẩm
2.2. Các chức năng của sản phẩm
2.3. Đặc điểm của người sử dụng
2.4. Các ràng buộc
2.5. Giả thiết và các phụ thuộc
Đặc tả yêu cầu (tt)
3. Đặc tả yêu cầu:
3.1. Yêu cầu về giao diện.
3.2. Yêu cầu chức năng
3.3. Yêu cầu hệ thống
3.4. Ràng buộc thiết kế
3.5. Yêu cầu khác
4. Phụ lục và chỉ mục
IV. Thẩm định yêu cầu
Liên quan đến việc kiểm tra tính đúng đắn, tính
đầy đủ, tính hiện thực và kiểm tra được của yêu
cầu.
Cụ thể là trả lời các câu hỏi sau:
1. Còn yêu cầu nào của người dùng chưa kể đến?
2. Có gì mâu thuẫn giữa các yêu cầu?
3. Tất cả chức năng, ràng buộc đã đủ chưa?
4. Có thực hiện được không?
5. Có thể kiểm tra yêu cầu như thế nào?
Thẩm định yêu cầu (tt)
Các kỹ thuật để thẩm định yêu cầu
1. Rà soát lại các yêu cầu
 Cùng với khách hàng phân tích lại cận thận và có
hệ thống các yêu cầu
2. Làm bản mẫu
Biểu diễn các yêu cầu thu thập được qua bản mẫu
vừa giúp khách hàng thẩm định lại yêu cầu và có thể
phát hiện thêm các yêu cầu mới.
3. Tạo ca kiểm thử (Test case)
Quản lý yêu cầu
Yêu cầu có thể thay đổi do:
Người trả tiền cho phần mềm và người sử dụng
phần mềm hiếm khi là một.
Môi trường nghiệp vụ & kỹ thuật thay đổi
Quản lý thay đổi yêu cầu

Gán định danh cho các yêu cầu

Phân tích yêu cầu và các thay đổi của yêu cầu.
Phân tích sự thay đổi và chi phí thay đổi.
Khi chấp nhận thay đổi thì thực hiện thay đổi sao
cho dễ dàng.
V. Phương pháp đặc tả yêu cầu
Hướng cấu trúc
Biểu đồ phân rã chức năng (FDD/BFD)
Biểu đồ luồng dữ liệu (DFD)
Biểu đồ thực thể kết hợp (ERD)
Hướng đối tượng
Use-case
Biểu đồ lớp (Class Diagram)
.
Biểu đồ phân rã chức năng
Function Decomposition Diagram (FDD)
Xác định phạm vi của hệ thống
Phân hoạch chức năng
Tạo nền tảng cho thiết kế kiến trúc hệ thống
 +

Biểu đồ phân rã chức năng (tt)

Ví dụ về FDD
QL tài chính QL tài chính

QL vốn đầu tư Lập kế hoạch QL ngân sách

Phân bổ vốn Kế hoạch Phân bổ

đầu tư dài hạn ngân sách

Kế hoạch Sử dụng
QL các dự án
ngắn hạn ngân sách
 +

Biểu đồ phân rã chức năng (tt)

Ý nghĩa của FDD
 FDD cho phép xác định các chức năng cần
nghiên cứu trong tổ chức
 Biết được vị trí của mỗi công việc trong hệ
thống. Tránh dư thừa hay trùng lắp
 Là cơ sở để xây dựng sơ đồ luồng dữ liệu
 Là cơ sở để nghiên cứu cấu trúc các chương
trình hệ thống
 +

Biểu đồ phân rã chức năng (tt)

Biểu đồ phân rã chức năng – các nguyên tắc
 Nguyên tắc thực chất
Mỗi chức năng được phân rã là một bộ phận
thực sự tham gia thực hiện các chức năng đã
phân rã ra nó.
 Nguyên tắc đầy đủ
Việc thực hiện các chức năng ở mức dưới trực
tiếp phải đảm bảo thực hiện được chức năng ở
mức trên.
 +

Biểu đồ phân rã chức năng (tt)

Quy trình xây dựng FDD
 Bước 1: Khảo sát, tìm hiểu tổ chức, các chức
năng nghiệp vụ của tổ chức.
 Bước 2 : Mô tả hoạt động của các chức năng
dưới dạng văn bản
 Bước 3 : Dựa vào văn bản mô tả chức năng (ở
bước 2) vẽ sơ đồ FDD
 +

Biểu đồ phân rã chức năng (tt)

Biểu đồ phân rã chức năng (tt)
 Chú ý
 FDD chỉ cho chúng ta biết hệ thống cần phải làm
gì chứ không chỉ ra hệ thống phải làm như thế nào
 FDD không phân biệt chức năng hành chính hay
chức năng quản lý. Tất cả chức năng đều quan
trọng và cần xử lý như nhau.
 +

Biểu đồ phân rã chức năng (tt)

Ví dụ 1: Quản lý bán hàng

 Để quản lý bán hàng, trước hết cty phải tìm kiếm thị trường.
Sau khi đã tìm kiếm được khách hàng, cty thực hiện việc ký kết
hợp đồng và cuối cùng là giao hàng.
 Để tìm kiếm thị trường, cty phải quảng cáo và giới thiệu sản
phẩm.
 Trong khi ký kết hợp đồng, phải thỏa thuận phương thức thanh
toán và phương thức giao hàng
 Để thực hiện hợp đồng cty phải thực hiện việc giao hàng bằng
cách vận chuyển đến địa chỉ của khách hàng và thu tiền của
khách hàng.
 +

Biểu đồ phân rã chức năng (tt)

Quản lý bán hàng

Tìm kiếm thị

Ký kết hợp đồng Giao hàng
trường

Quảng cáo sản Thỏa thuận PT

Vận chuyển hàng
phẩm thanh toán

Giới thiệu sản Thỏa thuận PT

Thu tiền
phẩm giao hàng
 +

Biểu đồ phân rã chức năng (tt)

Ví dụ 2: Quản lý tín dụng
 Phòng tín dụng của ngân hàng có nhiệm vụ cho vay và thu nợ.
 Khi khách hàng đến vay tiền bộ phận cho vay phải nhận đơn
vay của khách hàng sau đó duyệt đơn xem có đủ điều kiện cho
vay hay không rồi chuyển sang bộ phận trả lời đơn. Bộ phận
trả lời đơn sẽ trả lời khách hàng là từ chối hay chấp nhận cho
vay. Nếu chấp nhận thì cho vay và đồng thời ghi vào sổ nợ.
 Khi khách hàng đến trả tiền thì dựa vào sổ nợ, bộ phận thu nợ
phải xác định kỳ hạn trả nợ của từng khách hàng. Nếu trả đúng
hạn thì chuyển sang bộ phận xử lý nợ trong hạn. Ngược lại
chuyển sang bộ phận xử lý nợ quá hạn. Cả 2 bộ phận nầy đều
phải ghi vào sổ nợ
 +

Biểu đồ phân rã chức năng (tt)

Quản lý tín dụng

1. Cho vay 2. Thu nơ

2.1. Xác định kỳ

1.1. Nhận đơn
hạn

2.2. Xử lý trong
1.2. Duyệt vay
hạn

1.3. Trả lời 2.3. Xử lý quá hạn

1.4. Ghi sổ nợ 2.4. Ghi sổ nợ

Biểu đồ luồng dữ liệu
Mô hình luồng dữ liệu là một công cụ mô tả mối quan hệ thông tin
giữa các công việc.
Việc xây dựng mô hình luồng dữ liệu là rất cần thiết nhằm mục
đích:
 Bổ sung khiếm khuyết của sơ đồ chức năng nghiệp vụ bằng
việc bổ sung các luồng thông tin nghiệp vụ.
 Cho ta cái nhìn đầy đủ hơn về các mặt hoạt động của hệ thống.
 Là một trong số các đầu vào cho quá trình thiết kế hệ thống.
Dùng để xác định nhu cầu thông tin ở mỗi chức năng, cung cấp
bức tranh tổng thể của hệ thống và thiết kế sơ bộ về thực hiện các
chức năng
Là phương tiện giao tiếp giữa người phân tích và người sử dụng.
Biểu đồ DFD (Data Flow Diagram)
 Được xây dựng từ 4 phần tử chính
 Tác nhân: Người, tổ chức, hệ thống khác
 Chức năng xử lý: Thực hiện chức năng nào đó, tiêu
thụ và tạo ra thông tin
Dữ liệu hay thông tin: Vào hoặc ra khỏi chức năng
 Kho dữ liệu: Lưu trữ dữ liệu được sử dụng bởi
nhiều chức năng xử lý

Kho Dữ Liệu
Chức năng
Tác nhân
xử lý
Dữ liệu

Chức năng
xử lý
50
 +

Biểu đồ luồng dữ liệu (tt)

Ví dụ về DFD: Quản lý tín dụng
 Sơ đồ ngữ cảnh (Mức 0)

Tiền trả
Đơn vay
Khách hàng Tiền vay Quản lý tín Khách hàng
Trả lời
dụng
 +

Biểu đồ luồng dữ liệu (tt)

Ví dụ về DFD: Quản lý tín dụng
 Sơ đồ mức 1
Khách hàng
Khách hàng

Tiền vay Tiền trả

Đơn vay

1.0 2.0
Cho vay Thu nợ

TT đối
Trả lời TT tiền vay chiếu Tiền còn nợ

Khách hàng D1 Sổ nợ
 +

Biểu đồ luồng dữ liệu (tt)

Ví dụ về DFD: Quản lý tín dụng
 Sơ đồ mức 2 của 1.0
1.1 Đơn đã kiểm tra 1.2
Nhận đơn Duyệt vay

Đơn vay Đơn đã duyệt

Khách hàng 1.4 1.3

Ghi sổ nợ Trả lời
Hóa đơn tiền
vay
TT tiền vay Trả lời Tiền vay

D1 Sổ nợ
Khách hàng
 +

Biểu đồ luồng dữ liệu (tt)

Ví dụ về DFD: Quản lý tín dụng
 Sơ đồ mức 2 của 2.0
2.2
Xử lý trong
Nợ trong hạn hạn TT nợ trong hạn

2.1 TT đối
chiếu 2.4
Xác định kỳ D1 Sổ nợ
hạn Ghi nợ

Tiền trả 2.3

Nợ ngoài hạn Xử lý ngoài TT nợ ngoài hạn
hạn
Khách hàng
Biều đồ thực thể kết hợp
Entity Relationship Diagram (ERD)
Mô tả mối quan hệ vốn có của thế giới thực
Thực thể
Mối quan hệ giữa các thực thể

Phân tích dữ liệu độc lập với xử lý

Biểu đồ thực thể kết hợp (tt)
Các ký hiệu
ERD
Biểu đồ thực thể kết hợp (tt)
Lực lượng tham gia mối quan hệ
Mối quan hệ
NHÂN VIÊN Làm việc cho ĐƠN VỊ

Thể hiện mối quan hệ

NHÂN VIÊN làm việc cho ĐƠN VỊ

Nv1
Đv1
Nv2
Nv3
Nv4
Đv2
....

59
Biểu đồ thực thể kết hợp (tt)
Xác định thực thể và mối quan hệ
Thực thể:
Là các danh từ (trong các câu mô tả yêu cầu)
Có các thuộc tính khóa (xác định duy nhất)

Mối quan hệ:

Hoạt động xẩy ra giữa các thực thể
Có nghĩa với hoạt động của hệ thống

Là động từ
Biểu đồ thực thể kết hợp (tt)
Các bước mô hình hóa với ER
Xác định các thực thể và các thuộc tính của
chúng
Xác định các mối quan hệ giữa các thực thể
Mô tả các thực thể, các thuộc tính và các
mối quan hệ
 +

Từ điển dữ liệu
Mục đích
 Là một tư liệu tập trung về mọi tên gọi của mọi
đối tượng được dùng trong hệ thống. Cụ thể:
Mức Logic:
 Các luồng dữ liệu, các giao dịch, các sự kiện.
 Các chức năng xử lý.
 Các thực thể, các thuộc tính…
Mức vật lý:
 Các bảng, các chương trình, mô đun, thủ tục…
 +

Từ điển dữ liệu (tt)

Nội dung của từ điển dữ liệu
 Là tập hợp các mục từ. Mỗi mục từ gồm:
 Tên gọi và các tên đồng nghĩa.
 Đặc điểm về cấu trúc
 Đặc điểm về bản chất.
 Đặc điểm về chi tiết.
 Đặc điểm về liên hệ
 Tuy nhiên nội dung có thể thay đổi tùy vào loại
đối tượng
 +

Từ điển dữ liệu (tt)

Định nghĩa luồng dữ liệu
Tên luồng dữ liệu : Hóa đơn
Tên đồng nghĩa : Hóa đơn kiêm phiếu xuất
Vị trí (từ/đến)
Từ : Lập hóa đơn
Đến : Giải quyết bán hàng
Hợp thành : Tên khách hàng
Ngày hóa đơn
Ngày
Tháng
Năm
Các khoản bán hàng
Tên hàng
Số lượng
Thành tiền
Giải thích : Giải trình tiền ntrả cho một đơn mua hàng
Lập ngày: 1/1/09 Người lập: XYZ
 +

Từ điển dữ liệu (tt)

Định nghĩa dữ liệu sơ cấp
Tên dữ liệu sơ cấp : Ngày mở tài khoản
Mô tả : Là ngày mở tài khoản của một khách hàng
Tên đồng nghĩa : Ngày TK
Hợp thành : Ngày + Tháng + Năm
Mẫu tin, bảng liên quan : bảng Khách Hàng
Các xử lý liên quan : Biên tập đơn hàng
Xây dựng bảng Khách Hàng
Đặc điểm dữ liệu : tổng số ký tự : 6, kiểu ký tự số
Các giá trị (miền có thể) : khuôn dạng DDMMYY
năm >= 05
ngày phải <= ngày hiện tại.
Lập ngày: 1/1/09 Người lập: XYZ
 +

Từ điển dữ liệu (tt)

Định nghĩa bảng
Tên bảng : Nhân viên
Mô tả : Chứa thông tin về các nhân viên trong đơn vị.
Tên đồng nghĩa : Không
Hợp thành : Mã số NV
Ho tên NV
Ngày bắt đầu công tác
Lương
Phòng
Tổ chức : Tuần tự theo Mã số NV
Các xử lý liên quan : Cập nhật nhân viên
Tìm kiếm nhân viên
Lập ngày: 1/1/09 Người lập: XYZ
 +

Từ điển dữ liệu (tt)

Định nghĩa chức năng xử lý
Tên chức năng : Kiểm tra đơn hàng
Lưu đồ :

Mô tả : Kiểm tra và biên tập một đơn hàng từ khách

hàng , đối chiếu với tài khoản của khách, đưa ra
đơn hàng hợp lệ để xử lý tiếp hay đơn hàng không
hợp lệ để trả lại cho khách hàng
Vào : Đơn hàng, tài khoản của khách hàng
Ra : Đơn hàng hợp hay không hợp lệ.
Lập ngày: 1/1/09 Người lập: XYZ