Lý thuyết Chương 4 - Nhập môn công nghệ phần mềm | Trường Đại học CNTT Thành Phố Hồ Chí Minh

lOMoAR cPSD| 40659592
Translated from English to Vietnamese - www.onlinedoctranslator.com
Chương 4 – Kỹ thuật yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 1 lOMoAR cPSD| 40659592
Chủ đề được đề cập
²Yêu cầu chức năng và phi chức năng ²Quy trình kỹ
thuật yêu cầu ²Gợi ý yêu cầu ²Yêu
cầu kỹ thuật ²Xác thực yêu cầu ²Thay đổi yêu cầu
Kỹ thuật yêu cầu
²Quá trình thiết lập các dịch vụ mà khách hàng yêu cầu từ một
hệ thống và những ràng buộc mà nó vận hành và phát triển.
²Yêu cầu hệ thống là những mô tả về các dịch vụ hệ thống và
các ràng buộc được tạo ra trong quá trình kỹ thuật yêu cầu. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 2 lOMoAR cPSD| 40659592
Một yêu cầu là gì?
²Nó có thể bao gồm từ một tuyên bố trừu tượng cấp cao về một dịch vụ
hoặc của một ràng buộc hệ thống đối với một đặc tả chức năng toán học chi tiết.
²Điều này là không thể tránh khỏi vì các yêu cầu có thể phục vụ hai mục đích chức năng
§ Có thể là cơ sở để đấu thầu một hợp đồng - do đó phải dễ dàng giải thích;
§ Có thể là cơ sở cho chính hợp đồng - do đó phải được xác định chi tiết;
§ Cả hai tuyên bố này có thể được gọi là yêu cầu.
Trừu tượng hóa yêu cầu (Davis)
“Nếu một công ty muốn ký hợp đồng cho một dự án phát triển phần mềm lớn, công ty
đó phải xác định nhu cầu của mình một cách đủ trừu tượng để giải pháp không được xác
định trước. Các yêu cầu phải được viết ra để một số nhà thầu có thể đấu thầu hợp đồng, 30/10/2014
Chương 4 Kỹ thuật yêu cầu 3 lOMoAR cPSD| 40659592
có thể đưa ra những cách khác nhau để đáp ứng nhu cầu của tổ chức khách hàng. Khi
hợp đồng đã được trao, nhà thầu phải viết định nghĩa hệ thống cho khách hàng một
cách chi tiết hơn để khách hàng hiểu và có thể xác nhận những gì phần mềm sẽ làm. Cả
hai tài liệu này có thể được gọi là tài liệu yêu cầu của hệ thống.” Các loại yêu cầu
²Yêu cầu người sử dụng
§ Các tuyên bố bằng ngôn ngữ tự nhiên cộng với sơ đồ các dịch vụ mà hệ thống cung
cấp và các ràng buộc vận hành của nó. Viết cho khách hàng. ²Yêu cầu hệ thống
§ Một tài liệu có cấu trúc đưa ra các mô tả chi tiết về chức năng, dịch vụ và các
ràng buộc vận hành của hệ thống. Xác định những gì cần được thực hiện để có
thể là một phần của hợp đồng giữa khách hàng và nhà thầu. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 4 lOMoAR cPSD| 40659592
Yêu cầu của người dùng và hệ thống
Định nghĩa yêu cầu của người dùng
1.Hệ thống Mencare sẽ lập báo cáo quản lý hàng tháng thể hiện chi phí thuốc theo
chỉ định của từng phòng khám trong tháng đó.
Đặc tả yêu cầu hệ thống
1.1Vào ngày làm việc cuối cùng của mỗi tháng, sẽ lập bảng tổng hợp các loại thuốc
được kê đơn, giá thành và cơ sở kê đơn.
1.2Hệ thống sẽ tạo báo cáo để in sau 17h30 ngày làm việc cuối cùng của tháng.
1.3Mỗi phòng khám phải lập báo cáo, trong đó liệt kê tên thuốc, tổng số đơn thuốc,
số liều kê và tổng chi phí của từng loại thuốc được kê.
1.4Nếu thuốc có sẵn ở các đơn vị liều khác nhau (ví dụ 10mg, 20mg, v.v.) thì phải tạo các báo
cáo riêng cho từng đơn vị liều.
1,5Việc truy cập vào báo cáo chi phí thuốc sẽ bị hạn chế đối với những người dùng được ủy quyền như được liệt kê trong
danh sách kiểm soát truy cập quản lý. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 5 lOMoAR cPSD| 40659592
Người đọc các loại đặc tả yêu cầu khác nhau số 8 30/10/2014
Chương 4 Kỹ thuật yêu cầu lOMoAR cPSD| 40659592
Các bên liên quan của hệ thống
²Bất kỳ cá nhân hoặc tổ chức nào bị ảnh hưởng bởi hệ thống theo
một cách nào đó và vì vậy ai có lợi ích hợp pháp ²Các loại bên liên quan § Người dùng cuối
§ Người quản lý hệ thống
§ Chủ sở hữu hệ thống
§ Các bên liên quan bên ngoài
Các bên liên quan trong hệ thống Mentcare
²Thông tin bệnh nhân được ghi nhận vào hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 7 lOMoAR cPSD| 40659592
²Các bác sĩ chịu trách nhiệm khám và điều trị người bệnh.
²Y tá phối hợp tư vấn với bác sĩ
và thực hiện một số phương pháp điều trị.
²Nhân viên lễ tân y tế quản lý bệnh nhân các cuộc hẹn.
²Nhân viên IT chịu trách nhiệm cài đặt và bảo trì hệ thống.
Các bên liên quan trong hệ thống Mentcare
²Người quản lý y đức phải đảm bảo rằng
hệ thống đáp ứng các hướng dẫn đạo đức hiện hành về chăm sóc bệnh nhân.
²Các nhà quản lý chăm sóc sức khỏe có được sự quản lý thông tin từ hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 8 lOMoAR cPSD| 40659592
²Nhân viên hồ sơ bệnh án có trách nhiệm đảm bảo thông tin hệ
thống đó có thể được duy trì và bảo quản, đồng thời các thủ
tục lưu giữ hồ sơ đã được thực hiện đúng cách.
Phương pháp và yêu cầu linh hoạt
²Nhiều phương pháp linh hoạt cho rằng việc sản xuất chi tiết yêu cầu hệ thống
là lãng phí thời gian vì yêu cầu thay đổi quá nhanh.
²Do đó, tài liệu yêu cầu luôn nằm ngoài khả năng ngày.
²Các phương pháp linh hoạt thường sử dụng các yêu cầu gia tăng kỹ thuật và có
thể thể hiện các yêu cầu dưới dạng 'câu chuyện của người dùng' (được thảo luận trong Chương 3).
²Điều này là thiết thực cho các hệ thống kinh doanh nhưng có vấn đề đối với các hệ thống
yêu cầu phân tích trước khi phân phối (ví dụ: các hệ thống quan trọng) hoặc các hệ thống
được phát triển bởi một số nhóm. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 9 lOMoAR cPSD| 40659592
Yêu cầu chức năng và phi chức năng 30/10/2014
Chương 4 Kỹ thuật yêu cầu 10 lOMoAR cPSD| 40659592
Yêu cầu chức năng và phi chức năng ²Yêu cầu chức năng
§ Tuyên bố về các dịch vụ mà hệ thống sẽ cung cấp, cách hệ thống sẽ phản
ứng với các đầu vào cụ thể và cách hệ thống sẽ hoạt động trong các tình
huống cụ thể. § Có thể nêu những gì hệ thống không nên làm. ²những yêu cầu phi lý
§ Các ràng buộc đối với các dịch vụ hoặc chức năng do hệ thống cung cấp như ràng
buộc về thời gian, ràng buộc về quy trình phát triển, tiêu chuẩn, v.v.
§ Thường áp dụng cho toàn bộ hệ thống hơn là các tính năng hoặc dịch vụ riêng lẻ. ²Yêu cầu về tên miền
§ Những hạn chế của hệ thống từ miền hoạt động 30/10/2014
Chương 4 Kỹ thuật yêu cầu 11 lOMoAR cPSD| 40659592
Yêu cầu chức năng
²Mô tả chức năng hoặc dịch vụ hệ thống.
²Phụ thuộc vào loại phần mềm, người dùng dự kiến và loại hệ thống
nơi phần mềm được sử dụng.
²Yêu cầu chức năng của người dùng có thể ở mức cao tuyên bố về
những gì hệ thống nên làm.
²Yêu cầu hệ thống chức năng nên mô tả
dịch vụ hệ thống một cách chi tiết.
Hệ thống Mentcare: yêu cầu chức năng
²Người dùng sẽ có thể tìm kiếm danh sách cuộc hẹn để tất cả các phòng khám. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 12 lOMoAR cPSD| 40659592
²Hệ thống sẽ tạo ra mỗi ngày, cho mỗi phòng khám, một danh sách
bệnh nhân dự kiến đến khám ngày hôm đó.
²Mỗi nhân viên sử dụng hệ thống sẽ có
được xác định bằng mã số nhân viên gồm 8 chữ số của người đó.
Yêu cầu không chính xác
²Vấn đề nảy sinh khi các yêu cầu chức năng không được đáp ứng
được nêu một cách chính xác.
²Những yêu cầu mơ hồ có thể được diễn giải theo nhiều cách khác nhau theo cách của
nhà phát triển và người dùng.
²Hãy xem xét thuật ngữ 'tìm kiếm' trong yêu cầu 1
§ Ý định của người dùng – tìm kiếm tên bệnh nhân trên tất cả các cuộc hẹn ở tất cả các phòng khám; 30/10/2014
Chương 4 Kỹ thuật yêu cầu 13 lOMoAR cPSD| 40659592
§ Giải thích của nhà phát triển – tìm kiếm tên bệnh nhân trong một phòng khám riêng lẻ.
Người dùng chọn phòng khám rồi tìm kiếm.
Yêu cầu đầy đủ và nhất quán
²Về nguyên tắc, các yêu cầu phải đầy đủ và nhất quán. ²Hoàn thành
§Chúng nên bao gồm các mô tả về tất cả các cơ sở cần thiết. ²Nhất quán
§ Không được có xung đột hoặc mâu thuẫn trong phần mô tả các tiện ích của hệ thống.
²Trong thực tế, do hệ thống và môi trường phức tạp, không
thể tạo ra một tài liệu yêu cầu đầy đủ và nhất quán. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 14 lOMoAR cPSD| 40659592
những yêu cầu phi lý
²Chúng xác định các thuộc tính và ràng buộc của hệ thống, ví dụ: độ tin cậy,
thời gian đáp ứng và yêu cầu lưu trữ. Các ràng buộc là khả
năng của thiết bị I/O, biểu diễn hệ thống, v.v.
²Các yêu cầu về quy trình cũng có thể được quy định bắt buộc một IDE,
ngôn ngữ lập trình hoặc phương pháp phát triển cụ thể.
²Các yêu cầu phi chức năng có thể quan trọng hơn
yêu cầu chức năng. Nếu những điều này không được đáp ứng, hệ thống có thể trở nên vô dụng. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 15 lOMoAR cPSD| 40659592
Các loại yêu cầu phi chức năng 30/10/2014
Chương 4 Kỹ thuật yêu cầu 16 lOMoAR cPSD| 40659592
Triển khai các yêu cầu phi chức năng
²Các yêu cầu phi chức năng có thể ảnh hưởng đến tổng thể kiến trúc
của một hệ thống hơn là các thành phần riêng lẻ.
§ Ví dụ: để đảm bảo đáp ứng các yêu cầu về hiệu suất, bạn có thể phải tổ
chức hệ thống để giảm thiểu thông tin liên lạc giữa các thành phần.
²Một yêu cầu phi chức năng, chẳng hạn như yêu cầu bảo mật yêu cầu,
có thể tạo ra một số yêu cầu chức năng liên quan xác định các
dịch vụ hệ thống được yêu cầu.
§ Nó cũng có thể tạo ra các yêu cầu hạn chế các yêu cầu hiện có.
Phân loại phi chức năng
²Yêu cầu về sản phẩm 30/10/2014
Chương 4 Kỹ thuật yêu cầu 17 lOMoAR cPSD| 40659592
§ Các yêu cầu xác định rằng sản phẩm được giao phải hoạt động theo một cách cụ
thể, ví dụ như tốc độ thực hiện, độ tin cậy, v.v. ²Yêu cầu về tổ chức
§ Các yêu cầu là kết quả của các chính sách và thủ tục của tổ chức, ví
dụ như các tiêu chuẩn quy trình được sử dụng, các yêu cầu thực hiện, v.v. ²Yêu cầu bên ngoài
§ Các yêu cầu phát sinh từ các yếu tố bên ngoài hệ thống và quá trình phát
triển của nó, ví dụ như yêu cầu về khả năng tương tác, yêu cầu pháp lý, v.v. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 18 lOMoAR cPSD| 40659592
Ví dụ về các yêu cầu phi chức năng trong hệ thống Mentcare Yêu cầu sản phẩm
Hệ thống Mentcare sẽ có sẵn cho tất cả các phòng khám trong giờ làm việc bình thường (Thứ Hai – Thứ Sáu, 08:30–
17.30). Thời gian ngừng hoạt động trong giờ làm việc bình thường không được vượt quá năm giây trong một ngày bất kỳ. Yêu cầu tổ chức
Người dùng hệ thống Mencare phải tự xác thực bằng thẻ nhận dạng của cơ quan y tế. Yêu cầu bên ngoài
Hệ thống phải thực hiện các điều khoản về quyền riêng tư của bệnh nhân như được quy định trong HStan-03-2006-priv. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 19 lOMoAR cPSD| 40659592
Mục tiêu và yêu cầu
²Các yêu cầu phi chức năng có thể rất khó nêu rõ các yêu cầu
chính xác và không chính xác có thể khó xác minh. ²Mục tiêu
§Mục đích chung của người dùng như dễ sử dụng.
²Yêu cầu phi chức năng có thể kiểm chứng
§Một tuyên bố sử dụng một số biện pháp có thể được kiểm tra một cách khách quan.
²Các mục tiêu rất hữu ích cho các nhà phát triển vì chúng truyền tải ý định
của người sử dụng hệ thống.
Yêu cầu về khả năng sử dụng 30/10/2014
Chương 4 Kỹ thuật yêu cầu 20 lOMoAR cPSD| 40659592
²Hệ thống phải dễ dàng sử dụng bởi nhân viên y tế và nên được tổ
chức sao cho giảm thiểu lỗi của người dùng. (Mục tiêu)
²Nhân viên y tế có thể sử dụng tất cả các chức năng của hệ thống sau bốn giờ
tập luyện. Sau khóa đào tạo này, số lỗi trung bình do người dùng có kinh
nghiệm mắc phải không được vượt quá hai lỗi trong mỗi giờ sử dụng hệ
thống. (Yêu cầu phi chức năng có thể kiểm thử)
Số liệu để xác định các yêu cầu phi chức năng Tài sản Đo lường Tốc độ
Giao dịch được xử lý/giây Thời gian phản hồi của
người dùng/sự kiện Thời gian làm mới màn hình Kích cỡ Mbyte Số lượng chip ROM Dễ sử dụng
Thời gian huấn luyện Số lượng khung trợ giúp 30/10/2014
Chương 4 Kỹ thuật yêu cầu 21 lOMoAR cPSD| 40659592 độ tin cậy
Thời gian trung bình dẫn đến hư
hỏng Xác suất không sẵn
sàng Tỷ lệ xảy ra lỗi Tính sẵn sàng Độ bền
Thời gian khởi động lại sau khi thất bại Tỷ lệ
các sự kiện gây ra lỗi Xác suất hỏng dữ liệu khi xảy ra lỗi Tính di động
Tỷ lệ câu lệnh phụ thuộc mục tiêu Số lượng hệ thống mục tiêu
Quy trình kỹ thuật yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 22 lOMoAR cPSD| 40659592
Quy trình kỹ thuật yêu cầu
²Các quy trình được sử dụng cho RE rất khác nhau tùy thuộc vào miền
ứng dụng, những người có liên quan và tổ chức phát triển các yêu cầu.
²Tuy nhiên, có một số hoạt động chung chung cho mọi tiến trình
§ Gợi ý yêu cầu; Phân tích § yêu cầu;
§ Xác nhận yêu cầu; Quản lý § yêu cầu.
²Trong thực tế, RE là một hoạt động lặp đi lặp lại trong đó những các quá trình được xen kẽ. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 23 lOMoAR cPSD| 40659592
Một cái nhìn xoắn ốc về quy trình kỹ thuật yêu cầu Gợi ý yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 24 lOMoAR cPSD| 40659592
Gợi ý và phân tích yêu cầu
²Đôi khi được gọi là gợi ý yêu cầu hoặc việc khám phá các yêu cầu.
²Bao gồm nhân viên kỹ thuật làm việc với khách hàng để tìm về miền ứng
dụng, các dịch vụ mà hệ thống sẽ cung cấp và các ràng buộc
vận hành của hệ thống.
²Có thể lôi kéo người dùng cuối, người quản lý, kỹ sư tham gia vào bảo trì,
chuyên gia tên miền, công đoàn, v.v. Đây được gọi làcác bên liên quan. Gợi ý yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 25 lOMoAR cPSD| 40659592 Gợi ý yêu cầu
²Các kỹ sư phần mềm làm việc với nhiều loại hệ thống các bên liên quan
để tìm hiểu về miền ứng dụng, các dịch vụ mà hệ thống sẽ cung
cấp, hiệu năng hệ thống được yêu cầu, các hạn chế về phần cứng, các hệ thống khác, v.v.
²Các giai đoạn bao gồm: § Phát hiện yêu cầu,
§ Phân loại và tổ chức yêu cầu Ưu tiên và đàm § phán
yêu cầu Đặc tả yêu cầu. § 30/10/2014
Chương 4 Kỹ thuật yêu cầu 26 lOMoAR cPSD| 40659592
Các vấn đề về gợi ý yêu cầu
²Các bên liên quan không biết họ thực sự muốn gì. ²Các bên liên quan thể
hiện các yêu cầu theo cách riêng của họ. ²Các bên liên quan khác nhau có
thể có xung đột yêu cầu.
²Các yếu tố tổ chức và chính trị có thể ảnh hưởng đến yêu cầu
hệ thống. ²Các yêu cầu thay đổi trong quá trình phân tích.
Các bên liên quan mới có thể xuất hiện và môi trường kinh doanh có thể thay đổi. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 27 lOMoAR cPSD| 40659592
Quá trình xác định và phân tích yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 28 lOMoAR cPSD| 40659592
Hoạt động xử lý ²Khám phá yêu cầu
§ Tương tác với các bên liên quan để khám phá yêu cầu của họ.
Yêu cầu tên miền cũng được phát hiện ở giai đoạn này.
²Phân loại yêu cầu và tổ chức
§ Nhóm các yêu cầu liên quan và tổ chức chúng thành các cụm mạch lạc. ²Ưu tiên và đàm phán
§Ưu tiên các yêu cầu và giải quyết xung đột yêu cầu. ²Yêu cầu kỹ thuật
§ Các yêu cầu được ghi lại và đưa vào vòng tiếp theo của vòng xoắn ốc. Khám phá yêu cầu
²Quá trình thu thập thông tin về nhu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 29 lOMoAR cPSD| 40659592
và các hệ thống hiện có, đồng thời chắt lọc các yêu cầu của người dùng
và hệ thống từ thông tin này.
²Tương tác là với các bên liên quan của hệ thống từ người quản lý đến cơ quan quản lý bên ngoài.
²Các hệ thống thường có nhiều bên liên quan. Phỏng vấn
²Các cuộc phỏng vấn chính thức hoặc không chính thức với các bên liên quan là một phần của hầu hết các quá trình RE. ²Các loại phỏng vấn
§ Phỏng vấn kín dựa trên danh sách câu hỏi được xác định trước
§ Các cuộc phỏng vấn mở trong đó các vấn đề khác nhau được khám phá với các bên liên quan. ²Phỏng vấn hiệu quả 30/10/2014
Chương 4 Kỹ thuật yêu cầu 30 lOMoAR cPSD| 40659592
§ Hãy cởi mở, tránh những ý tưởng định sẵn về các yêu cầu và sẵn
sàng lắng nghe các bên liên quan.
§ Nhắc người được phỏng vấn tiến hành thảo luận bằng cách sử dụng câu hỏi bàn đạp,
đề xuất yêu cầu hoặc bằng cách cùng nhau làm việc trên một hệ thống nguyên mẫu.
Phỏng vấn thực tế
²Thông thường là sự kết hợp giữa phỏng vấn kín và mở.
²Các cuộc phỏng vấn là tốt để có được sự hiểu biết tổng thể về những gì
các bên liên quan làm và cách họ có thể tương tác với hệ thống.
²Người phỏng vấn cần phải cởi mở mà không cần chuẩn bị trước những ý tưởng đã
được hình thành về những gì hệ thống nên làm
²Bạn cần nhắc người sử dụng để nói về hệ thống bằng cách đề xuất
các yêu cầu thay vì chỉ hỏi họ muốn gì.
Các vấn đề khi phỏng vấn 30/10/2014
Chương 4 Kỹ thuật yêu cầu 31 lOMoAR cPSD| 40659592
²Các chuyên gia ứng dụng có thể sử dụng ngôn ngữ để mô tả
công việc của họ không dễ hiểu đối với kỹ sư yêu cầu.
²Các cuộc phỏng vấn không tốt cho việc hiểu tên miền yêu cầu
§ Kỹ sư yêu cầu không thể hiểu thuật ngữ miền cụ thể;
§ Một số kiến thức về lĩnh vực quá quen thuộc đến nỗi mọi người cảm thấy khó diễn đạt hoặc
nghĩ rằng nó không đáng để diễn đạt. Dân tộc học
²Một nhà khoa học xã hội dành nhiều thời gian để quan sát và phân tích
cách mọi người thực sự làm việc.
²Mọi người không cần phải giải thích hay trình bày rõ ràng công việc của mình.
²Các yếu tố xã hội và tổ chức có tầm quan trọng có thể Được Quan sát. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 32 lOMoAR cPSD| 40659592
²Các nghiên cứu dân tộc học đã chỉ ra rằng công việc thường phong phú
và phức tạp hơn những gì được đề xuất bởi các mô hình hệ thống đơn giản.
Phạm vi dân tộc học
²Những yêu cầu bắt nguồn từ cách mọi người
thực sự hoạt động chứ không phải theo cách mà các định nghĩa quy trình
gợi ý rằng chúng nên hoạt động.
²Những yêu cầu xuất phát từ sự hợp tác và nhận thức
về hoạt động của người khác.
§ Nhận thức về những gì người khác đang làm sẽ dẫn đến những thay đổi trong cách chúng ta làm việc.
²Dân tộc học có hiệu quả trong việc tìm hiểu hiện tại xử lý nhưng không
thể xác định các tính năng mới cần được thêm vào hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 33 lOMoAR cPSD| 40659592
dân tộc học tập trung
²Được phát triển trong một dự án nghiên cứu kiểm soát không lưu quá trình
²Kết hợp dân tộc học với nguyên mẫu
²Phát triển nguyên mẫu dẫn đến những câu hỏi chưa được trả lời trong đó
tập trung phân tích dân tộc học.
²Vấn đề với dân tộc học là nó nghiên cứu hiện tại những thực tiễn
có thể có một số cơ sở lịch sử không còn phù hợp nữa. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 34 lOMoAR cPSD| 40659592
Dân tộc học và tạo mẫu để phân tích yêu cầu
Câu chuyện và kịch bản
²Các kịch bản và câu chuyện của người dùng là những ví dụ thực tế về cách một hệ thống có thể được sử dụng 30/10/2014
Chương 4 Kỹ thuật yêu cầu 35 lOMoAR cPSD| 40659592
²Các câu chuyện và kịch bản là sự mô tả về cách một hệ thống có thể được sử
dụng cho một nhiệm vụ cụ thể.
²Bởi vì chúng dựa trên một tình huống thực tế,
các bên liên quan có thể liên hệ với họ và có thể nhận xét về tình huống của
họ liên quan đến câu chuyện.
Chia sẻ ảnh trong lớp học (iLearn) ²
Jack là giáo viên tiểu học ở Ullapool (một ngôi làng ở phía bắc Scotland). Ông đã quyết định rằng một dự
án đẳng cấp nên tập trung vào ngành đánh bắt cá trong khu vực, xem xét lịch sử, sự phát triển và tác động
kinh tế của việc đánh bắt cá. Là một phần của hoạt động này, học sinh được yêu cầu thu thập và chia sẻ
những hồi tưởng từ người thân, sử dụng kho lưu trữ trên báo và thu thập những bức ảnh cũ liên quan
đến cộng đồng ngư dân và ngư dân trong khu vực. Học sinh sử dụng wiki iLearn để tập hợp các câu
chuyện câu cá và SCRAN (trang tài nguyên lịch sử) để truy cập các kho lưu trữ báo chí và ảnh. Tuy nhiên,
Jack cũng cần một trang chia sẻ ảnh vì anh muốn học sinh chụp và nhận xét về ảnh của nhau cũng như tải
lên bản scan các bức ảnh cũ mà các em có thể có trong gia đình.
Jack gửi email đến một nhóm giáo viên tiểu học mà anh là thành viên để xem liệu có ai có thể đề xuất một
hệ thống phù hợp hay không. Hai giáo viên trả lời và cả hai đều gợi ý anh nên sử dụng KidsTakePics, một
trang chia sẻ ảnh cho phép giáo viên kiểm tra và kiểm duyệt nội dung. Vì KidsTakePics không được tích 30/10/2014
Chương 4 Kỹ thuật yêu cầu 36 lOMoAR cPSD| 40659592
hợp với dịch vụ xác thực iLearn nên anh ấy sẽ thiết lập giáo viên và tài khoản lớp học. Anh sử dụng dịch vụ
thiết lập iLearn để thêm KidsTakePics vào các dịch vụ mà học sinh trong lớp nhìn thấy để khi đăng nhập,
các em có thể sử dụng ngay hệ thống để tải ảnh lên từ thiết bị di động và máy tính của lớp. kịch bản
²Một dạng câu chuyện có cấu trúc của người dùng ²Các kịch bản nên bao gồm
§ Mô tả tình huống bắt đầu; Mô tả về dòng sự
§ kiện bình thường; Mô tả về những gì có thể
§ xảy ra sai sót; Thông tin về các hoạt động § đồng thời khác;
§ Mô tả trạng thái khi kịch bản kết thúc. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 37 lOMoAR cPSD| 40659592
Đang tải ảnh lên iLearn) ²
Giả định ban đầu: Một người dùng hoặc một nhóm người dùng có một hoặc nhiều bức ảnh kỹ thuật số sẽ
được tải lên trang chia sẻ ảnh. Chúng được lưu trên máy tính bảng hoặc máy tính xách tay. Họ đã đăng nhập
thành công vào KidsTakePics. ²
Bình thường: Người dùng chọn tải ảnh lên và họ được nhắc chọn ảnh sẽ tải lên máy tính của họ và
chọn tên dự án mà ảnh sẽ được lưu trữ. Họ cũng phải được cung cấp tùy chọn nhập từ khóa liên
quan đến mỗi ảnh được tải lên. Ảnh đã tải lên được đặt tên bằng cách tạo sự kết hợp giữa tên
người dùng với tên tệp của ảnh trên máy tính cục bộ. ²
Sau khi hoàn tất quá trình tải lên, hệ thống sẽ tự động gửi email đến người điều hành dự án yêu cầu họ
kiểm tra nội dung mới và tạo thông báo trên màn hình cho người dùng rằng việc này đã được thực hiện. Đang tải ảnh lên ²
Cái mà có thể sai lầm: ²
Không có người điều hành nào được liên kết với dự án đã chọn. Một email được tự động tạo cho quản trị
viên trường học yêu cầu họ chỉ định người điều hành dự án. Người dùng nên được thông báo rằng có thể
có sự chậm trễ trong việc hiển thị ảnh của họ. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 38 lOMoAR cPSD| 40659592 ²
Những bức ảnh có cùng tên đã được tải lên bởi cùng một người dùng. Người dùng sẽ được hỏi xem họ
có muốn tải lên lại ảnh có cùng tên, đổi tên ảnh hoặc hủy tải lên hay không. Nếu họ chọn tải lại ảnh
lên, ảnh gốc sẽ bị ghi đè. Nếu họ chọn đổi tên ảnh, tên mới sẽ tự động được tạo bằng cách thêm một
số vào tên tệp hiện có. ²
Các hoạt động khác:Người điều hành có thể đăng nhập vào hệ thống và có thể phê duyệt ảnh khi chúng được tải lên. ²
Trạng thái hệ thống khi hoàn thành: Người dùng đã đăng nhập. Những bức ảnh được chọn đã được tải lên và
gán trạng thái 'đang chờ kiểm duyệt'. Ảnh được hiển thị với người kiểm duyệt và người dùng đã tải chúng lên.
Yêu cầu kỹ thuật 30/10/2014
Chương 4 Kỹ thuật yêu cầu 39 lOMoAR cPSD| 40659592
Yêu cầu kỹ thuật
²Quá trình viết cho người dùng và hệ thống yêu cầu trong tài liệu yêu cầu.
²Yêu cầu của người dùng cuối cùng phải dễ hiểu người
dùng và khách hàng không có nền tảng kỹ thuật.
²Yêu cầu hệ thống là yêu cầu chi tiết hơn và có thể
bao gồm nhiều thông tin kỹ thuật hơn.
²Các yêu cầu có thể là một phần của hợp đồng đối với phát triển hệ thống
§Vì vậy, điều quan trọng là chúng phải đầy đủ nhất có thể.
Các cách viết đặc tả yêu cầu hệ thống Ký hiệu Sự miêu tả 30/10/2014
Chương 4 Kỹ thuật yêu cầu 40 lOMoAR cPSD| 40659592
Ngôn ngữ tự nhiên
Các yêu cầu được viết bằng cách sử dụng các câu được đánh số bằng ngôn ngữ tự nhiên. Mỗi
câu nên diễn đạt một yêu cầu.
Cấu trúc tự nhiên ngôn Các yêu cầu được viết bằng ngôn ngữ tự nhiên trên một biểu mẫu hoặc mẫu tiêu chuẩn. ngữ
Mỗi trường cung cấp thông tin về một khía cạnh của yêu cầu. Mô tả thiết kế ngôn
Cách tiếp cận này sử dụng ngôn ngữ giống như ngôn ngữ lập trình nhưng có nhiều tính năng trừu tượng ngữ
hơn để xác định các yêu cầu bằng cách xác định mô hình hoạt động của hệ thống. Cách tiếp cận này hiện
nay hiếm khi được sử dụng mặc dù nó có thể hữu ích cho các đặc tả giao diện. ký hiệu đồ họa
Các mô hình đồ họa, được bổ sung bằng các chú thích văn bản, được sử dụng để xác định các yêu
cầu chức năng cho hệ thống; Trường hợp sử dụng UML và sơ đồ trình tự thường được sử dụng. Toán học
Các ký hiệu này dựa trên các khái niệm toán học như máy hoặc tập hợp trạng thái hữu hạn. Mặc thông số kỹ thuật
dù những đặc tả rõ ràng này có thể làm giảm sự mơ hồ trong tài liệu yêu cầu, nhưng hầu hết
khách hàng đều không hiểu đặc tả chính thức. Họ không thể kiểm tra xem nó có đại diện cho
những gì họ muốn hay không và miễn cưỡng chấp nhận nó như một hợp đồng hệ thống.
Yêu cầu và thiết kế
²Về nguyên tắc, các yêu cầu phải nêu rõ hệ thống
nên làm và thiết kế nên mô tả nó thực hiện điều này như thế nào. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 41 lOMoAR cPSD| 40659592
²Trong thực tế, yêu cầu và thiết kế không thể tách rời
§ Kiến trúc hệ thống có thể được thiết kế để cấu trúc các yêu cầu;
§ Hệ thống có thể tương tác với các hệ thống khác tạo ra các yêu cầu thiết kế;
§ Việc sử dụng một kiến trúc cụ thể để đáp ứng các yêu cầu phi chức
năng có thể là một yêu cầu về miền.
§ Đây có thể là hậu quả của một yêu cầu quy định.
Đặc tả ngôn ngữ tự nhiên
²Yêu cầu được viết dưới dạng câu ngôn ngữ tự nhiên bổ sung
bằng sơ đồ và bảng biểu.
²Được sử dụng để viết các yêu cầu vì nó mang tính biểu cảm, trực quan và
phổ quát. Điều này có nghĩa là người dùng và khách hàng có thể hiểu được các yêu cầu. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 42 lOMoAR cPSD| 40659592
Hướng dẫn viết yêu cầu
²Phát minh ra một định dạng tiêu chuẩn và sử dụng nó cho tất cả các yêu cầu. ²Sử dụng
ngôn ngữ một cách nhất quán. Sử dụng thì cho yêu cầu bắt buộc, nên
cho các yêu cầu mong muốn.
²Sử dụng tính năng đánh dấu văn bản để xác định các phần chính của yêu cầu.
²Tránh sử dụng thuật ngữ máy tính.
²Bao gồm một lời giải thích (lý do) về lý do tại sao một yêu cầu là cần thiết.
Vấn đề với ngôn ngữ tự nhiên ²Thiếu sự rõ ràng
§ Độ chính xác là khó mà không làm cho tài liệu khó đọc. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 43 lOMoAR cPSD| 40659592 ²Nhầm lẫn yêu cầu
§Các yêu cầu chức năng và phi chức năng có xu hướng bị lẫn lộn. ²Sự kết hợp các yêu cầu
§Một số yêu cầu khác nhau có thể được thể hiện cùng nhau.
Các yêu cầu ví dụ đối với hệ thống phần mềm bơm insulin
3.2 Hệ thống sẽ đo lượng đường trong máu và cung cấp insulin, nếu cần, cứ 10
phút một lần.(Sự thay đổi lượng đường trong máu tương
đối chậm nên việc đo thường xuyên hơn là không cần thiết; việc đo ít thường
xuyên hơn có thể dẫn đến lượng đường cao không cần thiết.)
3.6 Hệ thống phải chạy quy trình tự kiểm tra mỗi phút với các điều kiện được kiểm tra
và các hành động liên quan được xác định trong Bảng 1.( Quy trình tự kiểm tra có thể 30/10/2014
Chương 4 Kỹ thuật yêu cầu 44 lOMoAR cPSD| 40659592
phát hiện ra các vấn đề về phần cứng và phần mềm và cảnh báo người dùng về thực
tế là có thể không thể hoạt động bình thường.)
Thông số cấu trúc
²Một cách tiếp cận để viết các yêu cầu trong đó sự tự do của
người viết yêu cầu còn hạn chế và yêu cầu được viết một cách chuẩn mực.
²Điều này hoạt động tốt đối với một số loại yêu cầu, ví dụ: yêu cầu
đối với hệ thống điều khiển nhúng nhưng đôi khi quá cứng nhắc
để viết ra các yêu cầu về hệ thống kinh doanh.
Thông số kỹ thuật dựa trên biểu mẫu
²Định nghĩa chức năng hoặc thực thể. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 45 lOMoAR cPSD| 40659592
²Mô tả đầu vào và nguồn gốc của chúng. ²Mô tả kết quả
đầu ra và nơi chúng đi đến.
²Thông tin về những thông tin cần thiết cho tính toán
và các thực thể khác được sử dụng. ²Mô tả hành động cần
thực hiện. ²Điều kiện trước và sau (nếu thích hợp).
²Các tác dụng phụ (nếu có) của chức năng. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 46 lOMoAR cPSD| 40659592
Thông số kỹ thuật có cấu trúc về yêu cầu đối với máy bơm insulin 30/10/2014
Chương 4 Kỹ thuật yêu cầu 47 lOMoAR cPSD| 40659592
Thông số kỹ thuật có cấu trúc về yêu cầu đối với máy bơm insulin 30/10/2014
Chương 4 Kỹ thuật yêu cầu 48 lOMoAR cPSD| 40659592
Đặc điểm kỹ thuật dạng bảng
²Được sử dụng để bổ sung cho ngôn ngữ tự nhiên.
²Đặc biệt hữu ích khi bạn phải xác định một số các phương
án hành động thay thế có thể có.
²Ví dụ, hệ thống bơm insulin căn cứ vào tính toán về tốc độ thay đổi
lượng đường trong máu và thông số kỹ thuật dạng bảng giải thích
cách tính toán nhu cầu insulin cho các tình huống khác nhau.
Bảng đặc tả tính toán của máy bơm insulin Tình trạng Hoạt động
Mức đường giảm (r2 < r1) Liều tổng hợp = 0
Mức đường ổn định (r2 = r1) Liều tổng hợp = 0 30/10/2014
Chương 4 Kỹ thuật yêu cầu 49 lOMoAR cPSD| 40659592
Lượng đường tăng và tốc độ tăng Liều tổng hợp = 0 giảm dần
((r2 – r1) < (r1 – r0))
Mức đường tăng và tốc độ tăng ổn định hoặc Liều thuốc =
tăng dần ((r2 – r1) ≥ (r1 – r0))
round ((r2 – r1)/4) Nếu kết
quả được làm tròn = 0 thì CompDose = Liều tối thiểu
Trường hợp sử dụng
²Ca sử dụng là một loại kịch bản được bao gồm trong UML.
²Các ca sử dụng xác định các tác nhân trong một tương tác và các tác nhân nào mô tả chính sự tương tác đó.
²Một tập hợp các trường hợp sử dụng sẽ mô tả tất cả những gì có thể tương tác với hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 50 lOMoAR cPSD| 40659592
²Mô hình đồ họa cấp cao được bổ sung thêm mô tả chi
tiết theo bảng (xem Chương 5).
²Sơ đồ trình tự UML có thể được sử dụng để thêm chi tiết vào các trường
hợp sử dụng bằng cách hiển thị trình tự xử lý sự kiện trong hệ thống.
Các trường hợp sử dụng của hệ thống Mentcare 30/10/2014
Chương 4 Kỹ thuật yêu cầu 51 lOMoAR cPSD| 40659592
Tài liệu yêu cầu phần mềm
²Tài liệu yêu cầu phần mềm là tài liệu chính thức
tuyên bố về những gì được yêu cầu của các nhà phát triển hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 52 lOMoAR cPSD| 40659592
²Nên bao gồm cả định nghĩa về yêu cầu của người dùng và đặc tả
các yêu cầu của hệ thống.
²Nó KHÔNG phải là một tài liệu thiết kế. Trong chừng mực có thể, nó
nên đặt ra NHỮNG GÌ hệ thống nên làm hơn là nó nên làm NHƯ THẾ NÀO. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 53 lOMoAR cPSD| 40659592
Người sử dụng tài liệu yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 54 lOMoAR cPSD| 40659592
Sự biến đổi của tài liệu yêu cầu
²Thông tin trong tài liệu yêu cầu phụ thuộc vào loại của hệ
thống và cách tiếp cận phát triển được sử dụng. ²Thông thường, các hệ
thống được phát triển dần dần sẽ có ít chi tiết hơn trong tài liệu yêu cầu.
²Các tài liệu yêu cầu tiêu chuẩn đã được
được thiết kế ví dụ như tiêu chuẩn IEEE. Những điều này hầu hết có
thể áp dụng cho các yêu cầu đối với các dự án kỹ thuật hệ thống lớn.
Cấu trúc của một tài liệu yêu cầu chương Sự miêu tả Lời nói đầu
Điều này sẽ xác định lượng độc giả dự kiến của tài liệu và mô tả lịch sử phiên bản của nó, bao
gồm lý do căn bản cho việc tạo ra một phiên bản mới và bản tóm tắt những thay đổi được thực
hiện trong mỗi phiên bản. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 55 lOMoAR cPSD| 40659592 Giới thiệu
Điều này sẽ mô tả sự cần thiết của hệ thống. Nó nên mô tả ngắn gọn các chức năng của
hệ thống và giải thích cách nó sẽ hoạt động với các hệ thống khác. Nó cũng nên mô tả
cách hệ thống phù hợp với mục tiêu kinh doanh hoặc chiến lược tổng thể của tổ chức vận hành phần mềm. Bảng chú giải
Điều này sẽ xác định các thuật ngữ kỹ thuật được sử dụng trong tài liệu. Bạn không nên đưa ra giả định
về kinh nghiệm hoặc kiến thức chuyên môn của người đọc. Người dùng yêu cầu
Ở đây, bạn mô tả các dịch vụ được cung cấp cho người dùng. Các yêu cầu hệ thống phi sự định nghĩa
chức năng cũng cần được mô tả trong phần này. Mô tả này có thể sử dụng ngôn ngữ tự
nhiên, sơ đồ hoặc các ký hiệu khác mà khách hàng có thể hiểu được. Cần phải xác định rõ
các tiêu chuẩn về sản phẩm và quy trình phải tuân theo. Kiến Trúc Hệ Thống
Chương này sẽ trình bày tổng quan cấp cao về kiến trúc hệ thống dự kiến, hiển thị sự
phân bổ chức năng trên các mô-đun hệ thống. Các thành phần kiến trúc được tái sử
dụng cần được làm nổi bật.
Cấu trúc của một tài liệu yêu cầu chương Sự miêu tả Hệ thống
Điều này sẽ mô tả các yêu cầu chức năng và phi chức năng chi tiết hơn. Nếu cần thiết, chi tiết hơn yêu cầu
cũng có thể được thêm vào các yêu cầu phi chức năng. Giao diện với các hệ thống khác có thể sự chỉ rõ được xác định. Mô hình hệ thống
Điều này có thể bao gồm các mô hình hệ thống đồ họa thể hiện mối quan hệ giữa các thành phần hệ
thống với hệ thống và môi trường của nó. Ví dụ về các mô hình khả thi là mô hình đối tượng, mô hình
luồng dữ liệu hoặc mô hình dữ liệu ngữ nghĩa. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 56 lOMoAR cPSD| 40659592
Sự phát triển của hệ thống
Điều này sẽ mô tả các giả định cơ bản mà hệ thống dựa vào và mọi thay đổi được dự đoán trước do sự
phát triển của phần cứng, thay đổi nhu cầu của người dùng, v.v. Phần này hữu ích cho các nhà thiết kế hệ
thống vì nó có thể giúp họ tránh các quyết định thiết kế có thể hạn chế những thay đổi có thể xảy ra trong
tương lai đối với hệ thống. Phụ lục
Chúng phải cung cấp thông tin chi tiết, cụ thể liên quan đến ứng dụng đang được phát triển; ví
dụ: mô tả phần cứng và cơ sở dữ liệu. Yêu cầu phần cứng xác định cấu hình tối thiểu và tối ưu
cho hệ thống. Các yêu cầu về cơ sở dữ liệu xác định tổ chức logic của dữ liệu được hệ thống sử
dụng và mối quan hệ giữa dữ liệu. Mục lục
Một số chỉ mục cho tài liệu có thể được bao gồm. Ngoài chỉ mục theo bảng chữ cái thông thường,
còn có thể có chỉ mục về sơ đồ, chỉ mục về chức năng, v.v. Xác thực yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 57 lOMoAR cPSD| 40659592 Xác thực yêu cầu
²Quan tâm đến việc chứng minh rằng các yêu cầu xác định hệ
thống mà khách hàng thực sự mong muốn.
²Chi phí lỗi yêu cầu cao nên việc xác nhận rất khó khăn. quan trọng
§ Việc sửa lỗi yêu cầu sau khi phân phối có thể tốn gấp 100 lần chi phí sửa lỗi triển khai. Kiểm tra yêu cầu
²Hiệu lực. Hệ thống có cung cấp các chức năng hỗ trợ tốt
nhất nhu cầu của khách hàng?
²Tính nhất quán. Có bất kỳ xung đột yêu cầu nào không? 30/10/2014
Chương 4 Kỹ thuật yêu cầu 58 lOMoAR cPSD| 40659592
²Sự hoàn thiện. Có phải tất cả các chức năng đều được yêu cầu bởi bao gồm khách hàng?
²Chủ nghĩa hiện thực. Các yêu cầu có thể được thực hiện được không ngân sách và công nghệ sẵn có
²Kiểm chứng được. Các yêu cầu có thể được kiểm tra?
Kỹ thuật xác nhận yêu cầu ²Đánh giá yêu cầu
§Phân tích thủ công có hệ thống các yêu cầu. ²nguyên mẫu
§ Sử dụng mô hình thực thi của hệ thống để kiểm tra yêu cầu. Được trình bày trong Chương 2.
²Tạo trường hợp thử nghiệm
§Phát triển các bài kiểm tra cho các yêu cầu để kiểm tra khả năng kiểm tra. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 59 lOMoAR cPSD| 40659592 Đánh giá yêu cầu
²Nên tổ chức đánh giá thường xuyên trong khi các yêu cầu định nghĩa đang được xây dựng.
²Cả khách hàng và nhân viên nhà thầu đều phải tham gia vào đánh giá.
²Việc xem xét có thể mang tính hình thức (có đầy đủ hồ sơ) hoặc không
chính thức. Giao tiếp tốt giữa nhà phát triển, khách hàng và người
dùng có thể giải quyết vấn đề ở giai đoạn đầu. Xem lại séc
²Khả năng kiểm chứng §Yêu cầu có thể kiểm tra được trên thực tế không? ²Dễ hiểu
§Yêu cầu có được hiểu đúng không? 30/10/2014
Chương 4 Kỹ thuật yêu cầu 60 lOMoAR cPSD| 40659592 ²Truy xuất nguồn gốc
§Nguồn gốc của yêu cầu có được nêu rõ ràng không? ²Khả năng thích ứng
§ Yêu cầu có thể được thay đổi mà không ảnh hưởng lớn đến các yêu cầu khác không? Thay đổi yêu cầu 30/10/2014
Chương 4 Kỹ thuật yêu cầu 61 lOMoAR cPSD| 40659592 Thay đổi yêu cầu
²Môi trường kinh doanh và kỹ thuật của hệ thống luôn thay đổi sau khi cài đặt.
§ Phần cứng mới có thể được giới thiệu, có thể cần phải giao tiếp hệ thống với
các hệ thống khác, các ưu tiên kinh doanh có thể thay đổi (do đó cần có
những thay đổi về hỗ trợ hệ thống) và luật và quy định mới có thể được đưa
ra mà hệ thống nhất thiết phải tuân theo.
²Những người trả tiền cho một hệ thống và những người sử dụng hệ thống đó hệ thống hiếm
khi là những người giống nhau.
§ Khách hàng hệ thống áp đặt các yêu cầu vì những hạn chế về tổ chức và ngân sách. Những điều
này có thể xung đột với các yêu cầu của người dùng cuối và sau khi phân phối, các tính năng mới
có thể phải được thêm vào để hỗ trợ người dùng nếu hệ thống đáp ứng được mục tiêu của nó. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 62 lOMoAR cPSD| 40659592 Thay đổi yêu cầu
²Các hệ thống lớn thường có cộng đồng người dùng đa dạng, với nhiều
người dùng có các yêu cầu và ưu tiên khác nhau có thể
xung đột hoặc mâu thuẫn.
§ Các yêu cầu hệ thống cuối cùng chắc chắn là sự thỏa hiệp giữa chúng và theo kinh
nghiệm, người ta thường phát hiện ra rằng sự cân bằng hỗ trợ dành cho những người
dùng khác nhau phải được thay đổi. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 63 lOMoAR cPSD| 40659592
Sự phát triển của yêu cầu Quản lý yêu cầu
²Quản lý yêu cầu là quá trình quản lý thay đổi yêu cầu
trong quá trình kỹ thuật yêu cầu và phát triển hệ thống. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 64 lOMoAR cPSD| 40659592
²Các yêu cầu mới xuất hiện khi một hệ thống đang được được phát triển
và sau khi nó được đưa vào sử dụng.
²Bạn cần theo dõi các yêu cầu cá nhân và duy trì liên kết giữa các
yêu cầu phụ thuộc để bạn có thể đánh giá tác động của những
thay đổi yêu cầu. Bạn cần thiết lập một quy trình chính thức để
đưa ra các đề xuất thay đổi và liên kết chúng với các yêu cầu hệ thống.
Lập kế hoạch quản lý yêu cầu
²Thiết lập mức độ chi tiết quản lý yêu cầu
đó là điều bắt buộc.
²Quyết định quản lý yêu cầu:
§ Xác định yêu cầuMỗi yêu cầu phải được xác định duy nhất để có thể tham chiếu
chéo với các yêu cầu khác. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 65 lOMoAR cPSD| 40659592
§ Một quy trình quản lý sự thay đổiĐây là tập hợp các hoạt động đánh giá tác
động và chi phí của những thay đổi. Tôi sẽ thảo luận quá trình này chi tiết hơn ở phần sau.
§ Chính sách truy xuất nguồn gốcCác chính sách này xác định mối quan hệ giữa
từng yêu cầu và giữa các yêu cầu với thiết kế hệ thống cần được ghi lại.
§ Hỗ trợ công cụCác công cụ có thể được sử dụng bao gồm từ hệ thống quản lý yêu
cầu chuyên môn đến bảng tính và hệ thống cơ sở dữ liệu đơn giản.
Quản lý thay đổi yêu cầu
²Quyết định xem có nên chấp nhận thay đổi yêu cầu hay không
§ Phân tích vấn đề và đặc tả thay đổi
• Trong giai đoạn này, vấn đề hoặc đề xuất thay đổi được phân tích để kiểm tra xem nó có
hợp lệ hay không. Phân tích này được phản hồi lại cho người yêu cầu thay đổi, người này
có thể phản hồi bằng đề xuất thay đổi yêu cầu cụ thể hơn hoặc quyết định rút lại yêu cầu.
§ Phân tích thay đổi và chi phí 30/10/2014
Chương 4 Kỹ thuật yêu cầu 66 lOMoAR cPSD| 40659592
• Hiệu quả của thay đổi đề xuất được đánh giá bằng cách sử dụng thông tin truy xuất nguồn
gốc và kiến thức chung về các yêu cầu hệ thống. Sau khi phân tích này được hoàn thành,
quyết định sẽ được đưa ra có nên tiến hành thay đổi yêu cầu hay không.
§ Thay đổi cách thực hiện
• Tài liệu yêu cầu và khi cần thiết, thiết kế và triển khai hệ thống được sửa đổi.
Lý tưởng nhất là tài liệu nên được tổ chức sao cho có thể dễ dàng thực hiện các thay đổi.
Quản lý thay đổi yêu cầu
Xác định Đã sửa đổi vấn đề Những điểm chính 30/10/2014
Chương 4 Kỹ thuật yêu cầu 67 lOMoAR cPSD| 40659592
²Các yêu cầu đối với một hệ thống phần mềm đặt ra những gì hệ thống phải thực
hiện và xác định các ràng buộc đối với hoạt động và triển khai của nó.
²Yêu cầu chức năng là các tuyên bố về dịch vụ mà hệ thống
phải cung cấp hoặc là những mô tả về cách thực hiện một số tính toán.
²Các yêu cầu phi chức năng thường hạn chế hệ thống đang được
phát triển và quá trình phát triển đang được sử dụng.
²Chúng thường liên quan đến các đặc tính nổi bật của hệ thống
và do đó áp dụng cho toàn bộ hệ thống. Những điểm chính
²Quá trình kỹ thuật yêu cầu là một quá trình lặp đi lặp lại quá trình
bao gồm việc khơi gợi các yêu cầu, đặc tả và xác nhận. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 68 lOMoAR cPSD| 40659592
²Gợi ý yêu cầu là một quá trình lặp đi lặp lại có thể được thể
hiện dưới dạng vòng xoắn ốc của các hoạt động – khám phá
yêu cầu, phân loại và tổ chức yêu cầu, đàm phán yêu cầu và yêu cầu tài liệu.
²Bạn có thể sử dụng một loạt các kỹ thuật cho các yêu cầu
gợi ý bao gồm các cuộc phỏng vấn và dân tộc học. Câu chuyện và kịch bản của người dùng
có thể được sử dụng để tạo điều kiện thuận lợi cho các cuộc thảo luận. Những điểm chính
²Đặc tả yêu cầu là quá trình chính thức ghi lại các yêu cầu
của người dùng và hệ thống, đồng thời tạo tài liệu yêu cầu phần mềm.
²Tài liệu yêu cầu phần mềm là một tài liệu đã được thống nhất tuyên bố về các
yêu cầu của hệ thống. Nó phải được tổ chức sao cho cả khách hàng hệ
thống và nhà phát triển phần mềm đều có thể sử dụng nó. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 69 lOMoAR cPSD| 40659592 Những điểm chính
²Xác nhận yêu cầu là quá trình kiểm tra
yêu cầu về tính hợp lệ, tính nhất quán, tính đầy đủ, tính hiện thực và khả năng kiểm chứng.
²Những thay đổi về kinh doanh, tổ chức và kỹ thuật chắc chắn sẽ
dẫn đến những thay đổi về yêu cầu đối với một hệ thống
phần mềm. Quản lý yêu cầu là quá trình quản lý và kiểm soát những thay đổi này. 30/10/2014
Chương 4 Kỹ thuật yêu cầu 70