Nhập môn công nghệ phần mềm - Nguyễn Thị Minh Tuyền - Yêu cầu phần mềm

ông. 
58 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Duyệt yêu cầu 
v Nên duyệt yêu cầu thường xuyên trong 
quá trình định nghĩa yêu cầu đang được 
hình thành. 
v Cả hai bên ký hợp đồng nên tham gia 
duyệt yêu cầu. 
v Việc duyệt yêu cầu có thể mang tính 
hình thức (với tài liệu hoàn chỉnh) hoặc 
không mang tính hình thức. Giao tiếp 
tốt giữa người phát triển, khách hàng và 
người dùng có thể giải quyết được các 
vấn đề ngay từ đầu. 
59 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Kiểm tra gì khi duyệt yêu cầu 
v Tính có thể kiểm định được (Verifiability) 
§  Về thực tiễn, có test được yêu cầu này không? 
v Tính dễ hiểu (Comprehensibility) 
§  Yêu cầu này có dễ hiểu không? 
v Tính có thể lần vết được (Traceability) 
§  Nguồn gốc của yêu cầu này có được chỉ rõ không? 
v Tính thích nghi được (Adaptability) 
§  Có thể thay đổi yêu cầu này mà không làm ảnh hưởng 
đến các yêu cầu khác không? 
60 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
www.themegallery.co
m 
Contents 
Yêu cầu chức năng và yêu cầu phi chức năng 
Đặc tả yêu cầu 
Các quy trình công nghệ yêu cầu 
Thu thập và phân tích yêu cầu 
Thẩm định yêu cầu 
Quản trị yêu cầu 
Tài liệu yêu cầu phần mềm 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Quản trị yêu cầu 
v Quản trị yêu cầu (requirements 
management) là quy trình quản trị sự thay 
đổi yêu cầu trong suốt quá trình công nghệ 
yêu cầu và phát triển hệ thống. 
v Các yêu cầu mới phát sinh khi hệ thống đang 
được phát triển và cả khi nó được đưa vào sử 
dụng. 
v Cần theo dõi những yêu cầu đơn lẻ và duy trì 
mối liên hệ giữa các yêu cầu phụ thuộc nhau 
§  Để có thể đánh giá được ảnh hưởng khi thay đổi yêu cầu. 
v Cần thiết lập một quy trình hình thức cho 
những đề nghị thay đổi và tạo mối liên hệ 
giữa yêu cầu này với các yêu cầu hệ thống. 
62 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Thay đổi yêu cầu 
v Môi trường doanh nghiệp và kỹ thuật của 
hệ thống luôn luôn thay đổi trong quá trình 
phát triển hệ thống và cả sau khi đưa hệ 
thống vào sử dụng. 
v Người chi trả cho hệ thống và người dùng 
hệ thống đó hiếm khi là một. 
§  Khách hàng hệ thống áp đặt yêu cầu vì những ràng buộc về 
mặt tổ chức và tài chính. Các yêu cầu này có thể xung đột với 
yêu cầu của người dùng cuối. Do đó, sau khi hệ thống được 
đưa vào sử dụng, những chức năng mới có thể phải được 
thêm vào để đáp ứng yêu cầu của người dùng. 
63 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Thay đổi yêu cầu 
v Những hệ thống lớn thường có một cộng 
đồng người dùng đa dạng. Những người 
dùng khác nhau có những yêu cầu khác 
nhau và độ ưu tiên cũng khác nhau, do 
đó có thể dẫn đến xung đột giữa các yêu 
cầu. 
64 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Cải tiến yêu cầu 
Time
Changed
understanding
of problem
Initial
understanding
of problem
Changed
requirements
Initial
requirements
65 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Kế hoạch quản lý yêu cầu 
v Thiết lập mức độ chi tiết về quản lý yêu cầu. 
v Trong quá trình quản lý yêu cầu, cần lập kế 
hoạch cho: 
§  Định danh yêu cầu Mỗi yêu cầu phải được đánh số duy nhất để có 
thể được tham chiếu từ các yêu cầu khác. 
§  Một quy trình quản lý sự thay đổi Đây là một tập các hoạt động để 
đánh giá mức độ ảnh hưởng và chi phí của các thay đổi. 
§  Các chính sách lần vết Những chính sách này định nghĩa mối quan 
hệ giữa các yêu cầu và giữa yêu cầu với thiết kế hệ thống. 
§  Công cụ hỗ trợ Sử dụng các công cụ hỗ trợ cho công việc quản lý 
các thay đổi về yêu cầu. 
66 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Quy trình quản lý thay đổi yêu cầu 
Change
implementation
Change analysis
and costing
Problem analysis and
change specification
Identified
problem
Revised
requirements
67 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Quy trình quản lý thay đổi yêu cầu 
v Có 3 giai đoạn chính 
§  Phân tích vấn đề và đặc tả thay đổi 
•  Trong giai đoạn này, việc thay đổi và các vấn đề được phân tích để 
kiểm tra tính hợp lệ của nó. Việc phân tích này là để trả lời người đưa 
ra yêu cầu cho việc thay đổi để quyết định xem nên chấp nhận thay đổi 
hay nên quyết định hủy bỏ yêu cầu thay đổi. 
§  Phân tích và ước lượng chi phí cho sự thay đổi 
•  Dùng thông tin lần vết và những kiến thức tổng quát về yêu cầu hệ 
thống để đánh giá hiệu ứng của sự thay đổi. Một khi hoàn thành phân 
tích này, một quyết định sẽ được đưa ra để xem liệu có nên tiến hành 
thay đổi yêu cầu hay không. 
§  Cài đặt thay đổi 
•  Sửa tài liệu yêu cầu và tài liệu cài đặt và thiết kế hệ thống nếu cần. 
Trong trường hợp lý tưởng, tài liệu nên được tổ chức sao cho việc 
thay đổi được cài đặt dễ dàng. 
68 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
www.themegallery.co
m 
Contents 
Yêu cầu chức năng và yêu cầu phi chức năng 
Đặc tả yêu cầu 
Các quy trình công nghệ yêu cầu 
Thu thập và phân tích yêu cầu 
Thẩm định yêu cầu 
Quản trị yêu cầu 
Tài liệu yêu cầu phần mềm 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Tài liệu yêu cầu phần mềm 
v Tài liệu yêu cầu phần mềm là phát biểu 
chính thức về những gì mà người phát 
triển hệ thống phải cài đặt. 
v Nên bao gồm cả định nghĩa yêu cầu 
người dùng và đặc tả yêu cầu hệ thống. 
v Đây không phải là tài liệu thiết kế, chỉ 
nên định nghĩa về cái gì hệ thống sẽ hỗ 
trợ hơn là đi vào chi tiết việc phải cài 
đặt như thế nào. 
70 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Ai sử dụng tài liệu yêu cầu? 
Use the requirements to
develop validation tests for
the system.
Use the requirements
document to plan a bid for
the system and to plan the
system development process.
Use the requirements to
understand what system is
to be developed.
System test
engineers
Managers
System
engineers
Specify the requirements and
read them to check that they
meet their needs. Customers
specify changes to the
requirements.
System
customers
Use the requirements to
understand the system and
the relationships between its
parts.
System
maintenance
engineers
71 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Tài liệu yêu cầu 
v Thông tin trong tài liệu yêu cầu phụ 
thuộc vào loại hệ thống và phương pháp 
phát triển được sử dụng. 
v Hệ thống được phát triển dần dần 
thường sẽ chứa ít chi tiết trong tài liệu 
yêu cầu. 
v Các chuẩn về tài liệu yêu cầu được thiết 
kế sẵn, ví dụ như chuẩn IEEE. Các chuẩn 
này có thể áp dụng được cho các dự án 
công nghệ hệ thống lớn. 
72 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Cấu trúc của một tài liệu yêu cầu 
Chapter Description 
Preface This should define the expected readership of the document and 
describe its version history, including a rationale for the creation of a 
new version and a summary of the changes made in each version. 
Introduction This should describe the need for the system. It should briefly 
describe the system’s functions and explain how it will work with 
other systems. It should also describe how the system fits into the 
overall business or strategic objectives of the organization 
commissioning the software. 
Glossary This should define the technical terms used in the document. You 
should not make assumptions about the experience or expertise of 
the reader. 
User requirements 
definition 
Here, you describe the services provided for the user. The 
nonfunctional system requirements should also be described in this 
section. This description may use natural language, diagrams, or 
other notations that are understandable to customers. Product and 
process standards that must be followed should be specified. 
System architecture This chapter should present a high-level overview of the anticipated 
system architecture, showing the distribution of functions across 
system modules. Architectural components that are reused should 
be highlighted. 
73 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Chapter Description 
System 
requirements 
specification 
This should describe the functional and nonfunctional requirements in 
more detail. If necessary, further detail may also be added to the 
nonfunctional requirements. Interfaces to other systems may be defined. 
System models This might include graphical system models showing the relationships 
between the system components and the system and its environment. 
Examples of possible models are object models, data-flow models, or 
semantic data models. 
System evolution This should describe the fundamental assumptions on which the system 
is based, and any anticipated changes due to hardware evolution, 
changing user needs, and so on. This section is useful for system 
designers as it may help them avoid design decisions that would 
constrain likely future changes to the system. 
Appendices These should provide detailed, specific information that is related to the 
application being developed; for example, hardware and database 
descriptions. Hardware requirements define the minimal and optimal 
configurations for the system. Database requirements define the logical 
organization of the data used by the system and the relationships 
between data. 
Index Several indexes to the document may be included. As well as a normal 
alphabetic index, there may be an index of diagrams, an index of 
functions, and so on. 
74 
Cấu trúc của một tài liệu yêu cầu 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Tổng kết 
v  Có thể sử dụng một tập các kỹ thuật để thu thập 
yêu cầu bao gồm việc phỏng vấn, xây dựng kịch 
bản, vẽ use case. 
v  Thẩm định yêu cầu là quy trình kiểm tra yêu cầu về 
tính hợp lệ, tính nhất quán, tính hoàn chỉnh, tính 
thực tế và tính có thể kiểm định được. 
v  Sự thay đổi về công việc, tổ chức và kỹ thuật dẫn 
đến sự thay đổi về yêu cầu của một hệ thống phần 
mềm. Quản trị yêu cầu là quy trình quản lý và điều 
khiển các thay đổi này. 
v  Tài liệu yêu cầu phần mềm là phát biểu được chấp 
nhận của yêu cầu hệ thống. Tài liệu này được tổ 
chức sao cho cả khách hàng và người phát triển có 
thể sử dụng được. 
75 
Nguyễn Thị Minh Tuyền Nhập môn CNPM 
Câu hỏi?