THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM - Chương 1: Tổng hợp và phân tích các yêu cầu phần mềm ppt

z Các tiêu thức để đánh giá một đặc tả: tính nhất quán, tính thân thiện, dễ sử dụng z Trong đặc tả phải nêu được cả business requirement, phạm vi ứng dụng, giới hạn của ứng dụng z Trong

Trang 2

Chương 1 Tổng hợp và phân tích các yêu cầu phần mềm

1 Các vấn đề và khái niệm trong yêu cầu phần mềm

2 Phát hiện các yêu cầu phần mềm (Software Elicitation)

3 Phân tích yêu cầu phần mềm và xây dựng các đặc tính xác

định chất lượng yêu cầu và các yêu cầu khác

Trang 3

1.4 Đặc tả các yêu cầu phần mềm

z Không phụ thuộc các yêu cầu phần mềm được

tìm ra, được xây dựng như thế nào, cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này.

z Các tiêu thức để đánh giá một đặc tả: tính nhất

quán, tính thân thiện, dễ sử dụng

z Trong đặc tả phải nêu được cả business

requirement, phạm vi ứng dụng, giới hạn của ứng dụng

z Trong đặc tả phải nêu được đầy đủ các user

requirement, sử dụng các mẫu (template) của các trường hợp sử dụng của từng yêu cầu.

Trang 4

Các điểm lưu ý khi đặc tả yêu cầu phần mềm (SRS):

(1) Làm theo và sử dụng các mẫu đặc tả: nên quy định

một mẫu đặc tả chung trong tổ chức của chúng ta,

sử dụng một số mẫu (template) nào đó: IEEE 830

-1998 Lưu ý rằng hoàn toàn có quyền sử đổi, quyđịnh lại các biểu mẫu nếu như điều đó là cần thiết

(2) Xác đinh rõ nguồn gốc của yêu cầu phần mềm trong

đặc tả: để có thể tất cả biết được tại sao lại phát sinhcác yêu cầu phần mềm này, chúng ta nên chỉ rõ tạisao nó lại có- từ NSD, yêu cầu chức năng hệ thống,

do quy chế, hay do các nguồn khác

Trang 5

(3) Đặt nhãn (label) cho từng yêu cầu phần mềm: chúng

ta nên thống nhất quy ước cách đặt nhãn (tên) chocác yêu cầu - nên đặt nhãn làm sao nhãn của cácyêu cầu mang càng nhiều các thông tin về các yêucầu đó càng tốt

(4) Ghi lại các nguyên tắc của công việc (business rule):

các nguyên lý hoạt động của hệ thống, của các thaotác, công việc cần được miêu tả

Trang 6

(5) Nên tạo ra ma trận theo dõi các yêu cầu phần mềm

(requirements traceability matrix): điều này rất có íchtrong quá trình phân tích các yêu cầu, quá trình thiết

kế, lập trình và kiểm thử các chức năng của hệthống Ma trận này cũng rất có ích giúp cho chúng taliên kết các chức năng với các yêu cầu phần mềmliên quan Nên sử dụng thường xuyên ma trận trongsuốt thời gian phát triển phần mềm

Trang 7

1.4.1 Ghi lại các nguyên tắc của công việc (Record business

rule)

z Khi NSD miêu tả cho chúng ta một hoạt động nào đó

chỉ được thực hiện trong những diều kiện nhất định, do những tác nhân nhất định, v.v tức là chúng ta đã cómột nguyên tắc công việc

z Nguyên tăc công việc là tập hợp các các nguyên tăc

hoạt động của quá trình thực hiện công việc

z Chúng ta có nghĩ vụ phải xây dụng các yêu cầu hệ

thống về mặt chức năng để đáp ứng các nguyên tắccông việc này - tuy nhiên không nền đồng nhất yêu cầuchức năng với nguyên tắc công việc

z Trong SRS nên tập hợp và đặc tả tất cả các nguyên tắc

của công việc vào một mục riêng.

Trang 8

1.4.2 Đặc tả các yêu cầu phần mềm theo mẫu

z Có thể nó đặc tả yêu cầu phần mềm (SRS) được

coi như: đặc tả chức năng hệ thống, sự thoả thuận

về chức năng, đặc tả hệ thống.

z SRS là cơ sở cho mọi hoạt động của dự án: phân

tích, thiết kế, lập kế hoạch, viết mã, kiểm thử, v.v.

z Khi đặc tả yêu cầu phần mềm có thể sử dụng các

công cụ:

• Văn bản (textual document)

• Mô hình đồ hoạ (graphical models)

• Các ngôn ngữ đặc tả hình thức

z Các điểm lưu ý:

• Tất cả các yêu cầu phần mềm phải được đua vào đặc tả.

• SRS được xây dựng trước khi phân tích và xây dựng

phần mềm

Trang 9

1 Gán nhãn các yêu cầu phần mềm (labeling)

Để có được một đặc tả tốt, có thể theo dõi mối liên quan giữa các yêu cầu, quá trình phát sinh ra chúng, v.v chúng ta cần có một quy định gán nhãn các yêu cầu một cách khoa học Có một số phương pháp thông dụng:

UR 3.2.1 (phương pháp này được sủdụng rộng rãi nhất)

texttual tags):Print.Copies.Confirm

Trang 10

2 Đánh dấu những điểm chưa rõ trong đặc tả

Đôi khi chúng ta thiếu một số các thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với NSD để biết chi tiết hơn, v.v Tất cả những chỗ như vây nên được đánh dấu bằng “To be determined’ - TBD Như vậy chúng ta đã phân định rõ những điểm thiếu (gaps) trong đặc tả để cần là sáng tỏ.

Tất cả các TBD này phải được giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm.

Trang 11

3 Mối liên quan giữa đặc tả và giao diện người

sử dụng

Sự kết hợp giữa thiết kế giao diện trong SRS có cả

ưu điểm và nhược điểm:

Nhược điểm:

• Các yêu cầu về giao diện thực chất chỉ là các giải pháp mà

không phải là các yêu cầu phần mềm

• Quá trình xây dựng các yêu cầu sẽ kéo dài

• NSD, khách hàng có thể tốn rất nhiều thời gian với giao diện

mà quên đi nhiệm vụ chính của họ là giúp chúng ta xây dựng các yêu cầu phần mềm

• Các giao diện xây dựng ở giai đoạn này chỉ mang tính chất

định hướng

Trang 12

3 Mối liên quan giữa đặc tả và giao diện người

sử dụng (tiếp)

Uu điểm:

• Có khả năng trau chuốt các yêu cầu phần mềm, xây dựng

các tương tác trở nên hữu hìh và dễ hiểu hơn cho cả khách hàng và cả các PTV

• Trợ giúp tốt hơn cho việc lập kế hoạch và đánh giá khối

lượng công việc.

Kết luận ở đay là nên sử dụng một số giao diện chuẩn hoặc các mô hình giao diệnở mức độ vừa phải để đưa vào đặc tả: mô hình chung của các giao diện nhập liệu, các giao diện - màn hình sử

lý, giao diện - màn hinh hiển thị, các hộp thoại, v.v.

Trang 13

1.4.3 Các mẫu đặc tả yêu cầu phần mềm (SRS template)

z Mỗi tổ chức, công ty phần mềm đều cần xây dựng

z Các SRS template là các tài liệu có cấu trúc tốt,

mềm dẻo, có khả năng tuỳ biến được theo yêu cầu của mỗi công ty phần mềm

Trang 14

IEEE 830-1998 Adapted and Extended Template:

2.5 Design and Implementation Constraints

2.6 Assumptions and Dependencies

Trang 15

IEEE 830-1998 Adapted and Extended Template

Trang 16

IEEE 830-1998 Adapted and Extended Template

Appendix B: Analysis Model

Appendix C: To - Be - Determined List

Trang 17

1.4.4 Quality Measures of the Modern SRS Package )

z A Good Table of Contents

z A Good Index

z A Revision History :

• The revision number or code for each change to the

published information

• The date of each revision to the published information

• A short summary of the revisions made to the published

information

• The name of the person responsible for the changes to

the published information

z A Glossary

Trang 18

1.4.5 Technical Methods for Specifying Requirements

z Technical methods for specifying requirements are

appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood

z Technical methods include pseudo-code, finite state

machines, decision trees, activity diagrams, relationship models, object-oriented analysis, and structured analysis

entity-z We can choose from a variety of technical specification

methods: Pseudo-code, Finite state machines, Decision trees, Activity diagrams (flowcharts), Entity relationship models, Object-oriented analysis, Structured analysis

Trang 19

1.4.5 Technical Methods for Specifying Requirements

z Technical methods for specifying requirements are

appropriate when the requirement description is too complex for natural language or if you cannot afford to have the specification misunderstood

z Technical methods include pseudo-code, finite state

machines, decision trees, activity diagrams, relationship models, object-oriented analysis, and structured analysis

entity-z We can choose from a variety of technical specification

methods: Pseudo-code, Finite state machines, Decision trees, Activity diagrams (flowcharts), Entity relationship models, Object-oriented analysis, Structured analysis

z More detail about methods: see chapter 28 of [1]

Trang 20

1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các

yêu cầu phần mềm

Các nguyên tác chỉ đạo khi viết đặc tả:

(1) Cố gắng viết các câu và đoạn văn ngắn gọn, không dài dòng(2) Sử dụng các thuật ngữ dễ hiểu, đã có trong glossary

(3) Viết các câu văn trong sáng, đúng ngữ pháp

(4) Tránh sử dụng những từ mang tính chất quảng cáo: giao diện

thân thiện, hệ thống hoạt động hiệu quả, v.v một cách chungchung mà cần chỉ rõ như thế nào là thân thiện, như thế nào

là hiệu quả

(5) Tránh sử dụng những tính từ so sánh: tốt hơn tốt nhất mà nên

chỉ ra rõ ràng các tiêu thức đánh giá trong đặc tả

Trang 21

Tracing Requirement:

z Theo dõi dấu vết của một yêu cầu phần mềm cho

phép chúng ta quản lý được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện, kiểm thử, bảo dưỡng và phát triển nó.

z Tồn tại 04 thao tác với quá trình theo dõi dấu vết của

một yêu cầu phần mềm

• Forward to Requirement

• Backward from Requirement

• Forward from Requirement

• Backward to Requirement

Trang 22

Forward

to Requirement

Backward

to Requirement

Forward from Requirement

Trang 23

SoftwareFunctionalRequirement

Trang 24

Tại sao cần Tracing Requirement:

z Tính chứng nhận (certification): xác thực tất cả cácchức

năng đã được thực hiện

z Khả năng phân tích phần mềm tốt hơn (change impact

analyis)

z Khả năng bảo dưỡng phần mềm tốt hơn (maintenance)

z Khả năng theo dõi quản lý, hiệu chỉnh dự án tốt hơn

(project tracking)

z Khả năng phát triển hệ thống: Reengineering

Trang 25

1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm

Tại sao cần Tracing Requirement (tiếp):

z Khả năng tái sử dụng (reuse)

z Khả năng giảm rủi ro (Risk Reduce)

z Khả năng kiểm thử (testing)

Trang 26

Ma trận theo dõi các yêu cầu phần mềm (Requirements Traceability Matrix)

z Phương pháp hay được sử dụng nhất để liên kết các

yêu cầu phần mềm và các thành phần khác của hệ thống là sử dung ma trận theo dõi các yêu cầu phần mềm.

z Các liên kết này thường được thể hiện giữa các thành

phần:

• Các trường hợp sử dụng (yêu cầu phần mềm)

• Các yêu cầu chức năng (functional requirement)

• Các thành phần thiết kế (design element)

• Mã chương trình (code)

• Trường hợp kiểm thử (test case)

Trang 27

Trang 28

Use case Functional

Requirement

Design element Code Test Case

UC -01 Input.Form FormNL formNL.input() Input.01

Trang 29

1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm

Functinal

FR-01 UC-01 FormNL formNL.input() Input.01

Trang 30

Quá trình lập ma trận:

(1) Xác định các mối liên kết và các khả năng lập ma trận

(2) Chọn dạng ma trận: tổng hợp hay chi tiết

(3) Chọn các chức năng/ các yêu cầu cần theo dõi

(3) Xác định phương pháp gán nhãn các yêu cầu

(4) Xác định nguồn các thông tin về các yêu cầu phục vụ

cho sự liênkết

(5) Thông báo cho những người tham gia về sự liên kết (6) Kiểm soát sự liên kết trong quá trình phá triển phần

mềm

Trang 31

1.6 Thẩm định xác minh các yêu cầu phần mềm

(Validating the Requirements)

z Mục đích của việc kiểm tra xác minh thẩm định

các yêu cầu phần mềm về tính đúng dắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm

z Các yêu cầu phần mềm chúng ta miêu tả trong

SRS phải đúng là những yêu cầu từ khách hàng, các yêu cầu giải quyết được những công việc của họ.

z Chúng ta có nhiệm vụ kiểm soát tính chính xác,

tính không trùng lặp của các yêu cầu phần mềm này.

Trang 32

z Các thao tác thẩm định xác minh có thể bao gồm:

• Viết các trường hợp kiểm thử cho các yêu cầu: sử dụng

mô hình hộp đen từ các trường hợp sử dụng để đánh giáhoạt dộng và hành vi của hệ thống Duyệt các hành vi vàtheo dõi các hoạt động để kiểm tra hệ thống đang đặc tả

có đáp ứng các yêu cầu của NSD hay không

• Xây dựng tài liệu hướng dẫn sử dụng (user manual): để

tiết kiệm thời gian chúng ta có thể dựng bản nháp của tàiliệu hướng dẫn sử dụng và sử dụng nó như là tài liệu đểkiểm tra lại các yêu cầu phần mềm.

Trang 33

z Acceptance Tests:

final validation process in order to gain assurance that "the product works the way the customer really needs it to."

specific number of "scenarios" that the user specifies and executes in the usage environment

Trang 34

z Các thao tác thầm định xác minh có thể bao gồm

(tiếp):

• Định nghĩa các tiêu chuẩn chấp nhận: Hỏi NSD xem các

tiêu thực ho đánh giá sản phầm phần mềm cần xây dựngtheo những tiêu thức như thế nào để chúng ta có thể đưanhững tiêu thức đó vào các trường hợp sử dụng của hệthống

Trang 35

z Testing Discrete Requirements:

z In the same way that we used traceability relationships to

relate use cases to test cases, we can use traceability to manage relationships between discrete, or itemized requirements and to then associate them with test cases

Trang 36

z Omitted Validation Relationships

• Having detected this "hole" in the relationships, you

should review the original set of product requirements and the related test cases If you find that a link was accidentally missed in establishing the traceability, simply add a new link and re-compute the trace matrix This type of omission frequently occurs in the early stages of establishing validation traceability

• Validation traceability helps ensure that no linkages have

been left out and that all product tests have been properly related to the higher-level product requirements Of course, it also helps if the product passes the tests

Trang 37

z Excess Validation Relationships

• That is, inspection of the columns of the trace matrix may

reveal a column that is not linked to any row elements

• Perhaps a link was accidentally missed in establishing the

traceability If so, simply add a new link and re-compute the trace matrix This type of omission frequently occurs in the early stages of establishing validation traceability

• Or, you might find that the development of the product

features simply failed to consider the needs of one of the required software tests This case may occur if, for example, certain nonfunctional requirements for the implementation in fact change the features of the product In this case, a projectreview may be necessary to consider the feasibility and need for the requirements As in verification, your team will need

to resolve whether the test is required at all and, if it is, what

Trang 38

z Testing Design Constraints

• You know how to collect and manage the tests for the use

cases and requirements The question then arises, "How do you test design constraints?

• Therefore, it is appropriate to include design constraints as

part of the validation effort When it comes to testing, you should test design constraints just as you would anything else Many design constraints will yield to a simple test by inspection For example, a design constraint that requires the software to be written in Visual Basic (VB) can be tested by simply looking at the source code

Tiêu đề	Tổng hợp và phân tích các yêu cầu phần mềm
Người hướng dẫn	PGS. Huỳnh Quyết Thắng
Trường học	Học viện Công nghệ Bưu chính Viễn thông - Posts and Telecommunications Institute of Technology
Chuyên ngành	Kỹ thuật phần mềm
Thể loại	Giáo trình
Năm xuất bản	2008-2009
Thành phố	Hà Nội

Định dạng
Số trang	46
Dung lượng	408,37 KB