Chapter 5 Đặc tả yêu cầu

Chapter 5Đăc ta yêu câu

Requirement specifications

Bai giang môn Thu nhân yêu câu - BM HTTT - HUI

1

Nôi dung


2

Requirement specifications (Đăc ta yêu câu) Đăc ta yêu câu phân mềm Tư điên dư liêu

Đăc ta yêu câu


3

Đăc ta yêu câu là người xây dựng hê thống phai tra lời các câu hỏi sau:

•Đâu ra của hê thống là gì

•Hê thống phai làm cái gì đê có kết qua mong muốn nghĩa là phai xử lý nhưng cái gì

•Nhưng tài nguyên mà hê thống yêu câu là gì

•Các hê thống phân mềm lớn luôn đòi hỏi cai tiến tư hiên trạng. Măc dù các khó khăn của hê thống hiên tại có thê xác định được nhưng các anh hưởng và hiêu ứng của hê thống mới khó dự đoán trước được.

•Hê thống lớn thường có nhiều công đồng sử dụng khác nhau. Họ có các yêu câu và ưu tiên khác nhau. Các yêu câu hê thống cuối cùng là gì

•Người tra tiền cho hê thống và người sử dụng khác nhau là ai?

Phân Loại Đăc ta yêu câu


4

Đăc ta yêu câu có thê chia thành 2 loại:•Đăc ta phi hình thức (ngôn ngư tự nhiên)•Đăc ta hình thức (dựa trên kiến trúc toán học)

Đăc ta Phi Hình Thức


5

Là đăc ta sử dụng ngôn ngư tự nhiên. Tuy không được chăt chẽ bằng đăc ta hình thức nhưng được nhiều người biết và có thê trao đổi với nhau đê làm chính xác hóa các điêm chưa rõ, chưa thống nhất giưa các bên phát triên hê thống.

Đăc ta Hình Thức


6

Là đăc ta mà ở đó các tư ngư, cú pháp, ngư nghĩa được định nghĩa hình thức dựa vào toán học.

Đăc ta hình thức có thê được coi là môt phân hoạt đông của đăc ta phân mềm.

Các đăc ta yêu câu được phân tích chi tiết. Các mô ta trưu tượng của các chức năng chương trình có thê được tạo đê làm rõ yêu câu



7

Có hai phương pháp đăc ta hình thức đê phát triên các hê thống tương đối phức tạp

Tiếp cận đại số, hê thống được mô ta dưới dạng các toán tử và các quan hê

Tiếp cận mô hình, mô hình hê thống được cấu trúc sử dụng các thực thê toán học như là tập hợp các thứ tự



8

Thuận lợi khi sử dụng đăc ta hình thức:•Cho phép chúng ta thấy và hiêu được ban chất bên trong của các yêu câu, đây là cách tốt nhất đê làm giam các lỗi, các thiếu sót có thê xay ra và giúp cho công viêc thiết kế được thuận lợi.•Do chúng ta sử dụng toán học cho viêc đăc ta nên có thê dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đây đủ của hê thống•Đăc ta hình thức ban thân nó cho chúng ta 1 cách thức cho viêc kiêm tra hê thống sau này



9

Hạn chế khi sử dụng đăc ta hình thức:•Quan lý phân mềm có tính bao thủ cố hưu của nó, không sẵn sàng chấp nhận các kỹ thuật mới•Chi phí thường cao hơn so với các đăc ta khác •Phân lớn nhưng người đăc ta không được đào tạo 1 cách chính qui về viêc sử dụng đăc ta hình ta hình thức cho viêc đăc ta hê thống mà dựa trên thói quen của họ•Nhiều thành phân của hê thống là khó cho viêc đăc ta bằng ngôn ngư hình thức. Thêm vào đó khách hàng không thê hiêu được nó.•Khách hàng không thích đăc ta toán học

Nguyên lý đăc ta


10

1. Phân tách chức năng với cài đăt: đăc ta là mô ta điều mong muốn chứ không phai cách thức thực hiên (cài đăt). Kết qua thu được theo dạng cái gì chứ không phai thế nào.

2. Cân tới ngôn ngư đăc ta hê thống hướng tiến trình: cân thiết đăc biêt trong trường hợp môi trường là đông và sự thay đổi của nó anh hưởng tới hành vi của thực thê nào đó tương tác với môi trường nào đó

3. Đăc ta phai bao gồm hê thống có phân mềm là môt thành phân: vì hê thống bao gồm các thành phân tương tác với nhau, chỉ bên trong hoàn canh của toàn bô hê thống và tương tác giưa các thành phân của nó thì hành vi của môt thành phân mới có thê xác định



11

4. Đăc ta phai bao gồm ca môi trường mà hê thống vận hành

5. Đăc ta hê thống phai là mô hình nhận thức: không phai là mô hình thiết kế hay cài đăt. Nó phai mô ta 1 hê thống như công đồng người sử dụng cam nhận thấy

6. Đăc ta phai vận hành: phai đây đủ và hình thức đê có thê được dùng trong viêc xác định liêu môt cài đăt được đề nghị có thỏa mãn đăc ta trong nhưng trường hợp kiêm thử tùy ý hay không



12

7. Đăc ta hê thống phai dung sai về tính không đây đủ và tính nâng cao. Đăc ta không thê hoàn toàn đây đủ do môi trường phức tạp

8. Đăc ta phai được cục bô hóa và được ghép lỏng lẻo: đăc ta làm cơ sở cho thiết kế và cài đăt, không phai tĩnh mà là sự vận đông, đang trai qua thay đổi đáng kê nên nôi dung và cấu trúc phai phù hợp. Sự thay đổi khi cân sửa đổi là tối thiêu, chỉ môt phân nhỏ các thành phân có thê thêm vào hay loại bớt môt cách dễ dàng

Tài liêu về yêu câu


13

Kết qua của quá trình phát triên yêu câu là bang thỏa thuận (agreement) giưa khách hàng và developer về san phâm cân xây dựng. Tài liêu về Vision and scope chứa các quy tắc

nghiêp vụ, và yêu câu người dùng thường dưới dạng các use cases.

Yêu câu chức năng và phi chức năng của san phâm sẽ nằm trong đăc ta yêu câu phân mềm (software requirements specification SRS)

Ba cách diễn ta yêu câu phân mềm


14

Văn ban: Tài liêu phai được viết 1 cách cân thận, có bố cục rõ ràng bằng ngôn ngư tự nhiên.

Mô hình: đê mô ta quy trình biến đổi, trạng thái hê thống và các thay đổi giưa chúng, các quan hê dư liêu, dòng logic, lớp và mối quan hê giưa các lớp.

Đăc ta hình thức: xác định các yêu câu bằng ngôn ngư logic toán học.

Cách nào thông dụng hơn???

Đăc ta yêu câu phân mềmSoftware requirements specification (SRS)


15

Đôi khi còn được gọi là functional specification, product specification, requirements document, system specification

Quy tắc nghiêp vụ và SRS


16

Đê tránh dư thưa, không nên lăp lại các quy tắc tư business rules catalog vào SRS mà nên chỉ ra nơi tham chiếu các qui tắc

Phòng tránh được viêc phai thay đổi cùng lúc ca qui tắc nghiêp vụ và yêu câu chức năng khi qui tắc thay đổi

Giư cho SRS luôn phan ánh các qui tắc vưa thay đổi vì nó tham chiếu đến ban sao chính của qui tắc

Thuận lợi trong viêc dùng lại cùng 1 qui tắc trong nhiều nơi khác nhau của SRS và cho nhiều dự án khác nhau mà vẫn giư được sự nhất quán.

Quy tắc nghiêp vụ và SRS


17

Lý do khác đê tách qui tắc nghiêp vụ và yêu câu chức năng: qui tắc thường được tách ra 1 cách riêng biêt, vì vậy có thê không nhạy bén khi xem thực tế có liên quan đến nhiều yêu câu khác.

Không có 1 giai pháp nào là perfect và simple đê cho môt qui tắc nghiêp vụ thực thi cùng nhau trong mọi hoàn canh

Các đối tượng sử dụng SRS


18

Customers, the marketing department, và sales staff cân biết họ được phân phối san phâm gì.

Project managers cân biết các ước tính về lịch biêu, tài nguyên, thời gian trong phân mô ta san phâm.

SRS cho đôi SW development biết cân xây dựng cái gì.

Nhóm kiêm thử dùng SRS đê phát triên kế hoạch test, các test cases và thủ tục kiêm thử

Giúp cho nhân viên maintenance &support biết mỗi phân của san phâm cân hỗ trợ gì.

Các đối tượng sử dụng SRS


19

Người viết tài liêu (Documentation writer) Người hướng dẫn sử dụng (Training

personnel) Quan chức luật pháp (Legal staff) dựa vào

SRS đê bao đam là các yêu câu phù hợp với luật và chính sách của chính quyền và tổ chức.

Đăc trưng của SRS


20

SRS chứa các chức năng và kha năng mà hê thống phân mềm phai cung cấp và các ràng buôc phai tuân theo.

SRS là cơ sở cho tất ca các giai đoạn planning, design, coding, testing và tạo tư liêu cho người dùng.

SRS cung mô ta các hành vi của hê thống dưới các điều kiên khác nhau nhưng không chứa design, construction, testing.

Đăc trưng của SRS


21

Không cân phai viết SRS cho ca san phâm trước khi bắt đâu, nhưng cân cung cấp yêu câu cho mỗi increment trước khi bắt đâu increment.

Phát triên theo hướng tăng tiến (incremental) là phù hợp khi stakeholders không thê xác định được tất ca yêu câu lúc đâu và cân nhận môt cách nhanh chóng 1 số chức năng tư người dùng

Cách bố trí SRS


22

Đăt nhãn cho mỗi phân môt cách thống nhất. Không nên gióng thăng lề phai. Sử dụng các phân cân nhấn mạnh môt cách hình

anh như in đậm, in nghiêng, các kiêu font khác nhau môt cách thống nhất và đúng mực.

Tạo bang mục lục và chỉ mục giúp người đọc tìm thông tin dễ dàng.

Đánh số và tạo tiêu đề tất ca hình anh và bang biêu

Cách bố trí SRS


23

Use your word processor's cross-reference facility rather than hard-coded page or section numbers to refer to other locations within a document.

Sử dụng hyperlink đê người đọc chuyên đến các phân có liên quan trong SRS hay trong các tài liêu khác.

Sử dụng template thích hợp đê sắp xếp lại tất ca các thông tin cân thiết.

SRS Template


24

Mỗi tổ chức SW nên thưa nhận cách viết SRS cho các dự án theo 1 hay 1 số mẫu tiêu chuân.

Xem phụ lục D

SRS Template


25

Hướng dẫn viết SRS – Phân Introdution


26

1.1. Purpose•Xác định san phâm cùng với số phiên ban sẽ phát hành1.2. Document Conventions•Mô ta qui ước tiêu chuân bao gồm định dạng văn ban, ký hiêu,…được dùng trong tài liêu•Indented Audience and Reading Suggestions1.3. Liêt kê các người đọc khác nhau. •Mô ta các phân trong SRS được sắp xếp như thế nào. Đề nghị đọc tài liêu sao là phù hợp nhất



27

1.4. Project Scope•Cung cấp mô ta vắn tắt về phân mềm với mục tiêu người dùng. Nếu đã có sẵn tài liêu vision and scope thì nên tham chiếu hơn là viết trùng lăp1.5. References•Liêt kê bất kỳ tài liêu và tài nguyên nào mà SRS tham chiếu đến. Cung cấp thông tin đủ đê người đọc có thê truy xuất đến các tham chiếu này, bao gồm tiêu đề, tác gia, số phiên ban, ngày, Url,…



28

2.1. Project perspective•Mô ta nguồn gốc hoăc hoàn canh xuất xứ san phâm: phiên ban kế tiếp, thay thế san phâm cu hay san phâm hoàn toàn mới•Nếu SRS này chỉ xác định 1 phân của ca hê thống lớn hơn, cân chỉ ra phân mềm này liên quan đến ca hê thống lớn như thế nào và xác định giao diên chính giưa hai phân mềm



29

2.2. Project Feature•Liêt kê các tính năng chính của san phâm. Hình anh của các nhóm yêu câu chính và mối liên hê giưa chúng chăng hạn lược đồ DFD, lược đồ Use case,…2.3. User Classes and characteristics•Xác định các lớp người dùng khác nhau và các tính năng phù hợp với mỗi lớp người dùng. Các lớp người dùng là 1 tập con của các stakeholder đã được mô ta trong tài liêu vision and scope.



30

2.4. Operating Environment •Mô ta môi trường mà phân mềm sẽ vận hành bao gồm phân cứng, hê điều hành, vị trí địa lý của người dùng, server và database. Tài liêu vision and scope có thê chứa 1 số thông tin ở mức cao



31

2.5. Design and Implementation Constraints•Mô ta các ràng buôc liên quan đến thiết kế và thực thi hê thống•Các ràng buôc như sau:

• Công nghê, tool, ngôn ngư lập trình, databases cân dùng hay phai tránh.

• Các hạn chế vì môi trường vận hành san phâm như loại và phiên ban version của Web browsers



32

Các ràng buôc như sau: Các qui ước và tiêu chuân phát triên SW Tích hợp ngược với các san phâm trước đó Các hạn chế dựa vào qui tắc nghiêp vụ Giới hạn về phân cứng như yêu câu thời gian,

bô nhớ, vi xử lý,… Các qui ước về giao diên người dùng hiên thời

cân được tuân theo khi mở rông san phâm mới.



33

2.6. User Documentation•Liêt kê các tài liêu sẽ phát hành kèm theo SW bao gồm user manuals, online help, tutorial.2.7. Assumptiom and Dependencies•Gia thiết (assumption) là các phát biêu được tin là đúng nhưng chưa được chứng minh. Gia thiết sai có thê gây ra các rủi ro cho dự án.



34

2.7. Assumptiom and Dependencies•Môt vài ví dụ về gia thiết

• Môt số người đọc SRS có thê gia thiết san phâm phù hợp với qui ước về giao diên người dùng, môt số khác giao diên phai khác.

• Nhà phát triên có thê gia thiết các chức năng này là phù hợp với ứng dụng nhưng nhà phân tích lại cho rằng họ sẽ dùng lại các chức năng tư dự án trước



35

2.7. Assumptiom and Dependencies•Xác định các phụ thuôc của dự án vào các yếu tố bên ngoài như ngày phát hành phiên ban kế tiếp hay các vấn đề liên quan đến tiêu chuân kỹ thuật.•Nếu hê thống cân tích hợp với 1 số thành phân của dự án khác đang phát triên thì hê thống sẽ phụ thuôc vào lịch trình của dự án đó. •Nếu các phụ thuôc này đã được ghi chép trong môt tài liêu khác như project plan thì phai chỉ ra viêc tham chiếu tài liêu đó



36

Trình bày lân lượt tưng tính năng của hê thống theo mẫu sau:

3.x System Feature X: Phát biêu ngắn gọn tên tính năng như “3.1 Spell Check” 3.x.1 Description and Priority: mô ta ngắn gọn về

tính năng và chỉ ra đô ưu tiên của tính năng (high, mediem hay low)

3.x.2 Stimulus/Response Sequences: liêt kê chuỗi các tác nhân đâu vào và đáp ứng của hê hê thống

3.x.3 Functional Requirements: Đánh số thứ tự các yêu câu chức năng chi tiết liên quan đến tính năng đang xét



37

4.1. User Interface•Mô ta các tính năng của mỗi giao diên người dùng. Các tiêu chuân GUI như:

• Fonts, icons, button lables, images, coloe schemes, field tabling sequences, commonly used controls,…

• Screen layout or resolution constraints• Standard buttons, functions, or navigation links

that will appear on every screen such as help button

So sánh SRS và vision document


38

Có 1 số phân trùng nhau giưa SRS và vision & scope document như project scope, product features, operating environment ….)

Vì có 1 số dự án nhỏ chỉ cân tạo 1 tài liêu về requirement là đủ. Do đó nếu muốn dùng ca 2 loại thì cân điều chỉnh đê loại trư phân trùng lăp giưa 2 tài liêu. Có thê sử dụng các section tương đương nhau

nhưng trong SRS thì mô ta chi tiết hơn các thông tin có tính sơ bô hay mức cao trong vision and scope document.

Cách viết requirement


39

Không có cách chính thống nào đê viết requirement môt cách tốt nhất; mà chủ yếu là tư kinh nghiêm (experience).

Nhưng vấn đề vấp phai trong quá khứ sẽ cho ta bài học đáng giá trong tương lai.

Môt vài gợi ý đê viết requirement


40

Viết câu đúng văn phạm, đúng chính ta. Câu văn và đoạn văn nên ngắn gọn và trực tiếp.

Sử dụng thê chủ đông (active voice) VD: "The system shall do something," không

dùng "Something shall happen.”

Assignment 21: Gợi ý viết requirement

Ví dụ 1 về yêu câu mẫu


41

"The Background Task Manager shall provide status messages at regular intervals not less than every 60 seconds."

Nhận xét gì về phát biêu trên Phân tích:

Status messages là gì? Chúng được cung cấp cho người dùng trong điều kiên gì và theo kiêu gì?

Nếu thông báo hiên thị, thì chúng xuất hiên trong bao lâu? Khoang thời gian “every 60 seconds” không rõ ràng.



42

Khoang thời gian giưa các status messages phai ít nhất là 60 seconds, vậy thì nếu cho 1 thông báo mới xuất hiên 1 lân/năm có được không? Hoăc nếu không được nhiều hơn 60 second giưa các thông báo, vậy thì khoang thời gian 1 millisecond có quá ngắn không?

Tuy các cách hiêu cực đoan này đều tương thích với yêu câu gốc nhưng rõ ràng nó không phai là cái mà người dùng muốn quan tâm tới. Yêu câu này không thê kiêm chứng được.



43

Sau khi thao luận với khách hàng thì yêu câu trên nên sửa lại như sau:

The Background Task Manager (BTM) shall display status messages in a designated area of the user interface. 1.1 The messages shall be updated every 60

plus or minus 10 seconds after background task processing begins.

1.2 The messages shall remain visible continuously.



44

1.3 Whenever communication with the background task process is possible, the BTM shall display the percent completed of the background task.

1.4 The BTM shall display a "Done" message when the background task is completed.

1.5 The BTM shall display a message if the background task has stalled.

Các ví dụ còn lại


45

Assignment 22: năm ví dụ về yêu câu không thê kiêm chứng và cách sửa lại đê có yêu câu rõ ràng ( sách SW requirement.chm)

Tư điên dư liêu(Data dictionary)


46

Data dictionary—a shared repository that defines the meaning, data type, length, format, necessary precision, and allowed range or list of values for all data elements or attributes used in the application.



47

Thông tin trong 1 tư điên dư liêu có thê được dùng cho nhiều đăc ta yêu câu khác nhau.

Các lỗi khi tích hợp thành phân sẽ giam nếu tất ca developers đều tuân theo các định nghĩa chung trong tư điên dư liêu.

Viêc tập hợp các định nghĩa dư liêu nên bắt đâu ngay trong lúc thu thập yêu câu.



48

Tư điên dư liêu có thê được đưa vào như 1 phụ lục của SRS hay tách ra thành 1 tài liêu riêng.

Lợi ích của tư điên dư liêu


49

Dễ tìm kiếm thông tin Tránh dư thưa và không đồng bô (thay vì đê các

định nghĩa dư liêu nằm rai rác trong phân yêu câu chức năng)

Tư yêu câu người dùng đến mô hình phân tích


50

Tư yêu câu của khách hàng, analyst có thê nhăt ra các tư khóa (keyword) và chuyên thành các phân tử của 1 mô hình nào đó.

Vai Trò của Tư Điên


51

Tư khóa và các thành phân mô hình phân tích


52

Chapter 5 Đặc tả yêu cầu

Documents

Transcript of Chapter 5 Đặc tả yêu cầu