1.1 Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm
Trả lời
ü Gán nhãn các yêu cầu phần mềm
ü Đánh dấu những điểm chưa rõ ràng trong đặc tả
ü Mối liên quan giữa đặc tả và giao diện người sử dụng
ü Không phụ thuộc vào các yêu cầu được tìm được ra hay xây dựng như thế nào
ü 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.
ü Trong đặc tả phải nêu được đầy đủ các user requirement, sử dụng mẫu (template) của các trường hợp sử dụng của từng yêu cầu.
ü Thỏa mãn các tiêu thức đánh giá một đặc tả: tính nhất quán, tính thân thiện, tính dễ sử dụng.
1.2Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm
Trả lời:
Khái niệm:
Là hiểu biết hệ thống của khách hàng vào thời điểm thiết kế và phát triển phần mềm. Đó là hợp đồng đảm bảo về cả khách hàng và sự hiểu biết hệ thống,các nhu cầu khác trước khi ấn định thời điểm.
- 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.
- Các tiêu chí để đánh giá 1 đặc tả: tính nhất quán, tính thân thiện và tính dễ sử dụng.
- Trong đặc tả yêu cầu phần mềm phải nêu được cả yêu cầu thương mại, phạm vi ứng dụng, giới hạn của ứng dụng.
- Trong đặc tả phải nêu đầy đủ được các yêu cầu người sử dụng, 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 [n1]
Thành phần :
· Ghi lại các nguyên tắc công việc.
Khi người sử dụng miêu tả cho chúng ta một hoạt động nào đấy chỉ được thực hiện trong những điều kiện nhất định, do những tác nhân nhất định..tức là chúng ta đã có 1 nguyên tắc công việc.
· Đặc tả các yêu cầu phần mềm theo mẫu.
Là đặc tả chức năng hệ thống, sự thỏa thuận về chức năng, đặc tả hệ thống.(SRS)
üGán nhãn các yêu cầu phần mềm.
üĐánh dấu những điểm chưa rõ trong đặc tả.
üMối liên quan giữa đặc tả vào giao diện người sử dụng.
1.3Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU)
Trả lời:
Giao diện
-Chức năng
-Cơ sở dữ liệu
-Bảo mật
-Chất lượng
-Hạn chế.
IEEE:
· Giới thiệu
üMục đích tài liệu
üVăn bản quy ước.
üĐối tượng dự kiến và góp ý.
üPhạm vi sản phẩm.
üTài liệu tham khảo.
· Mô tả chung
üĐặc điểm sản phẩm
üChức năng sản phẩm
üĐặc điểm user
üMôi trường vận hành
üThiết kế và ràng buộc
üGiả định và phụ thuộc
· Yêu cầu về giao diện ngoài
üGiao diện người dùng
üGiao diện phần cứng
üGiao diện phần mềm
üGiao diện tương tác
· Tính năng hệ thống
üHệ thống tương lai
üMô tả và ưu tiên
üKích cầu/ thứ tự đáp ứng.
üYêu cầu chức năng
· Yêu cầu phi chức năng.
üYêu cầu trình diễn
üYêu cầu an toàn
üYêu cầu bảo mật
üYêu cầu chất lượng các thành phần phần mềm
üNguyên tắc công việc
üTài liệu người sử dụng
· Các yêu cầu khác
üThuật ngữ
üMô hình phân tích
üDanh sách định dạng
CMU:
1.4Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS.
Trả lời:
a. Trong cấu trúc Đặc tả yêu cầu phần mềm ( SRS ) :
- System Requirement ( yêu cầu hệ thống ) : Nêu lên cấu hình hiện tại của cơ sở hạ tẩng thông tin của hệ thống sẽ được phát triển phần mềm như : Cấu hình hạ tầng mạng, hệ thống máy tính, các thiết bị ngoại vi đang có, …. và ảnh hưởng của chúng lên phần mềm sẽ xây dựng. Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận.
- Software Requirement được hiểu là các yêu cầu về phần mềm bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác... do khách hàng đưa ra.
b. Trong tài liệu SRS System Requirement được đặt phía trước Software Requirement:
- System Requirement được đặc tả trong phần các yêu cầu chung nhất đối với hệ thống phần mềm sẽ phát triển.
- Software Requirement là phần chính của tài liệu SRS, bao gồm mô tả chi tiết yêu cầu đối với từng chức năng mà hệ thống cần phải đạt được , nó được đặc tả ở phần trung tâm của tài liệu SRS.
1.5Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm
Trả lời:
1. Giả ngôn ngữ
Giả ngôn ngữ là một sự kết hợp giữa ngôn ngữ tự nhiên với những cú pháp chặt chẽ, những cấu trúc điều khiển của một ngôn ngữ lập trình để diễn giải thuật toán hay chương trình theo một cách dễ hiểu nhất.
2. Máy trạng thái hữu hạn
Máy trạng thái hữu hạn (FSMS) rất phổ biến cho một số loại ứng dụng lập trình hệ thống, nhắn tin, chuyển đổi hệ thống, hệ điều hành và hệ thống điều khiển quá trình. FSMS là một cách để mô tả sự tương tác giữa người sử dụng nhân lực bên ngoài và hệ thống.
3. Cây quyết định
Thường được sử dụng trong việc xem xét yêu cầu dựa trên sự kết hợp của các thông tin đầu vào, những sự kết hợp khác nhau của các thông tin đầu vào sẽ dẫn đến các hành vi khác nhau hoặc các kết quả khác nhau của các kết quả đầu ra. Việc xây dựng cây quyết định thường gắn với những câu lệnh điều kiện “if – then” lồng nhau.
4. Biểu đồ hoạt động
Với việc sử dụng ngôn ngữ mô hình hóa UML, các đặc tả có thể được diễn giải thành các hình khối rất trực quan giúp cho người sử dụng có thể dễ dàng nắm bắt được nội dung của SRS.
5. Mô hình thực thể liên kết
ERD cung cấp 1 kiến trúc cấp cao của dữ liệu, nó sẽ được tiếp tục tăng cường với các chi tiết thích hợp về các thông tin cần thiết để mô tả.
6. Phân tích hướng đối tượng
Là một lối tư duy về vấn đề theo lối ánh xạ các thành phần trong bài toán vào cac đối tượng ngoài đời thực. Giúp người sử dụng dễ hiểu.
1.6Phân tích vai trò của từng thành phần trong cấu trúc tài liệu yêu cầu phần mềm
Trả lời:
Cấu trúc tài liệu yêu cầu phần mềm: 11 thành phần
- Introduction (Giới thiệu)
- Glossary (từ điển thuật ngữ)
- Use Cases (trường hợp sử dụng)
- Design Overview (thiết kế tổng quan)
- System Object Model (mô hình đối tượng hệ thống)
- Object Descriptions (mô tả đối tượng)
- Object Collaborations (đối tượng hợp tác)
- Data Design (thiết kế dữ liệu)
- Dynamic Model (mô hình động)
- Non-functional Requirements (yêu cầu phi chức năng)
- Supplementary Documentation (tài liệu bổ sung)
1. Introduction: cho ta biết
- Mục đích:
· Cung cấp một mô tả về các thiết kế của một hệ thống đầy đủ để cho phép phát triển phần mềm.
· Cung cấp thông tin cần thiết để cung cấp mô tả chi tiết cho các phần mềm và hệ thống được xây dựng
- Phạm vi: cho biết phạm vi của hệ thống
- Các từ viết tắt,các định nghĩa: giúp tài liệu trở nên ngắn gọn hơn, người đọc dễ đọc, dễ hiểu hơn.
- Sự tham khảo
- Tổng quan: giúp người đọc có cái nhìn tổng quan về hệ thống cần xây dựng
2. Glossary:cung cấp các thuật ngữ và định nghĩa để sử dụng nội bộ của tài liệu
3. Use Cases: xác định được những ai sẽ sử dụng hệ thống, tác nhân kích hoạt, đại diện và quản trị hệ thống
4. Design Overview: đưa ra một tổng quan về thiết kế, cho nó vào một ngữ cảnh với các hệ thống bên ngoài. Cho phép người đọc và người sử dụng tài liệu định hướng cho bản thân để thiết kế và nhìn thấy một bản tóm tắt trước khi tiếp tục thiết kế các chi tiết.
5. System Object Model : cho phép mô tả các hệ thống một cách tổng thể, cho thấy các nhóm khác nhau của các phần vào các hệ thống tương ứng
6. Object Descriptions: mô tả các đối tượng trong tài liệu
7. Object Collaborations: mô tả mối quan hệ các đối tượng
8. Data Design: Sơ đồ thực thể liên kết: cho biết các liên kết giữa các đối tượng (1-1, 1-nhiều, nhiều-nhiều)
9. Dynamic Model:
- Sơ đồ trình tự: cho thấy mức độ tổng quan về hình thức trình tự di chuyển từ dữ liệu và mẫu để có một tài liệu
- Sơ đồ chỉnh sửa tài liệu: cho thấy mức độ tổng quan về trìn tự di chuyển từ một tài liệu ban đầu chưa sửa đổi cho một tài liệu sửa đổi
10. Non-functional Requirements: cung cấp các yêu cầu thực hiện (các yêu cầu phi chức năng)
11. Supplementary Documentation: có thể là tài liệu tham khảm, có thể là công cụ được sử dụng để tạo biểu đồ
1.7Ý nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm
Trả lời:
ý nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm
Đặc tả hệ thống là đặc tả chức năng hệ thống: Định nghĩa các chức năng phần mềm mà người phát triển cần phải xây dựng để có thể đáp ứng được tất cả các nhiệm vụ đã miêu tả trong yêu cầu người sử dụng.
1.8Các kỹ thuật đăc tả các yêu cầu chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả chức năng và kiểm soát quan hệ giữa các yêu cầu chức năng
Trả lời
Các kĩ thuật đặc tả yêu cầu chức năng.
Các phương pháp kỹ thuật để xác định các yêu cầu phù hợp với mô tả yêu cầu là quá phức tạp đối với ngôn ngữ tự nhiên.
1 số phương pháp kĩ thuật bao gồm:kỹ thuật mã giả,máy trạng thái hữu hạn,cây quyết định,sơ đồ hoạt động, mô hình thực thể-quan hệ, phân tích hướng đối tượng, và phân tích cấu trúc.
Bạn có thể chọn từ nhiều phương pháp đặc tả kỹ thuật:
1.Mã giả
2.Máy trạng thái hữu hạn.
3.Cây quyết định
4.Biểu đồ hoạt động
5.Mô hình thực thể quan hệ
6.Phân tích hướng đối tượng
7.Phân tích cấu trúc(Biểu đồ luồng dữ liệu)
1.Mã giả
Mã giả là một "chuẩn" lập trình ngôn ngữ,kết hợp các phi chính thức của ngôn ngữ tự nhiên với cú pháp chặt chẽ, cấu trúc điều khiển của một ngôn ngữ lập trình. Mã giả bao gồm sự kết hợp của:
Câu bắt buộc với một động từ duy nhất và một đối tượng duy nhất.
Thường không quá 40-50, các "hành động theo định hướng" động từ mà từ đó các câu phải được xây dựng
Quyết định đại diện có cấu trúc IF-ELSE-ENDIF
Lặp đi lặp lại các hoạt động biểu diễn với DO-WHILE hay cấu trúc FOR-NEXT
Hình 28-1 cho thấy một ví dụ về một đặc tả mã giả của thuật toán để tính doanh thu.
2.Máy trạng thái hữu hạn.
Trong một số trường hợp, đó là thuận tiện để mô tả mối quan hệ rời rạc của 1 nhóm các hệ thống. Trong phản ứng với một đầu vào, chẳng hạn như nhập dữ liệu từ người sử dụng hoặc nhập vào từ một thiết bị bên ngoài, máy tính này thay đổi trạng thái của nó và sau đó tạo ra sản phẩm hoặc thực hiện một hành động.
Thiết kế phần cứng đã sử dụng máy trạng thái hữu hạn (FSMS) trong nhiều thập niên.
Hình 28-2 minh họa chuyển trạng thái cho các hộp đèn
FSMS đang rất phổ biến cho một số loại ứng dụng lập trình hệ thống, chẳng hạn như nhắn tin, chuyển đổi hệ thống, hệ điều hành, và hệ thống điều khiển quá trình.
3.Cây quyết định.
Nó phổ biến để xem một yêu cầu với một sự kết hợp của các yếu tố đầu vào, kết hợp khác nhau của các yếu tố đầu vào dẫn đến các hành vi khác nhau hoặc kết quả đầu ra.
Hình 28-3 cho thấy một cây quyết định sử dụng để mô tả các trình tự khẩn cấp HOLIS.
4.Biểu đồ hoạt động.
Các hoạt động sơ đồ UML, có lợi thế là hiểu biết hợp lý: Ngay cả người không có đào tạo liên quan đến máy tính đều có thể hiểu được.
5.Mô hình thực thể-quan hệ
Nếu các yêu cầu trong thiết lập liên quan đến một mô tả về cấu trúc và các mối quan hệ giữa các dữ liệu trong hệ thống, nó thường thể hiện bằng sơ đồ thực thể-quan hệ (ERD). Hình 28-5 cho thấy một ERD điển hình.
Các ERD không chính xác tập trung vào các hành vi bên ngoài của hệ thống mà cho phép chúng ta xác định những câu hỏi như "Có thể có nhiều hơn một địa chỉ thanh toán cho mỗi hoá đơn?" Trả lời: không có.
Mặc dù một ERD là một kỹ thuật mô hình hóa mạnh mẽ nhưng không phải là tất cả mọi người đều có thể hiểu được nó.
6.Mô hình hướng đối tượng.
Với sự phổ biến của OO và UML, các sơ đồ này được coi là nổi bật hơn cả trong số các kỹ thuật, trong các mô hình triển khai để thực hiện các chức năng của hệ thống.
Trong hình 28-6
7.Biểu đồ luồng dữ liệu
Ví dụ hình 28-7.
Biểu đồ luồng dữ liệu (DFD) các mô hình khá giống như mô hình ERD nhưng nó dễ hiểu hơn so với ERD.
1.9Các kỹ thuật đăc tả các yêu cầu phi chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả phi chức năng và kiểm soát quan hệ giữa các yêu cầu phi chức năng
Trả lời:
Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức năng. Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng. Có thể chia các yêu cầu phi chức năng thành hai loại:
üRàng buộc về hiệu năng: chẳng hạn "hệ thống cần phục vụ liên tục từ 5 giờ sáng đến 9 giờ tối.", "mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm".
üRàng buộc về quá trình phát triển hệ thống: thời gian, tài nguyên, chất lượng. Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).
Các kỹ thuật chính:
üLàm rõ yêu cầu (Eliciting requirements): giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.
üXem xét yêu cầu (Analyzing requirements): xác định xem các yêu cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó.
üLàm tài liệu yêu cầu (Recording requirements): các yêu cầu có thể được ghi lại theo nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các tình huống sử dụng(use case), câu chuyện sử dụng(user story), hoặc các đặc tả tiến trình.
Làm rõ yêu cầu khách hàng có thể sử dụng một số kỹ thuật sau như:
üCác cuộc phỏng vấn
üThành lập các nhóm trọng tâm (focus group) với các cuộc họp bàn về yêu cầu (requirements workshops)
üTạo ra các danh sách yêu cầu
üTạo nguyên mẫu(prototyping)
üTạo tình huống sử dụng
1.10 Nêu các phương pháp đánh giá chất lượng tài liệu đặc tả yêu cầu phần mềm
Trả lời:
Tài liệuyêucầu:
üChỉ mô tả về chức năng, ràng buộc
üKhông mô tả về phương pháp cài đặt
üPhải dễ thay đổi (có cấu trúc)
üKhó xác định được đầy đủ chính xác ngay
üPhải qua nhiều bước xét duyệt lại
Các nguyên tắc chỉ đạo khi viết tài liệu đặ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ậtngữ 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 chung
chung 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ả.
Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức
üTính rõ ràng, chính xác
ü Tính phù hợp
üTính đầy đủ hoàn thiện
1.11 Phân tích vai trò của từng tác nhân trong xem xét và thông qua (phê duyệt) tài liệu đặc tả yêu cầu phần mềm
Trả lời:
Các tác nhân tham gia vào quá trình xem xét và thông qua (phê duyệt) tài liệu yêu cầu đặc tả phần mềm:
- Các đại diện của người sử dụng (Product Champions): Thực hiện quá trình xác nhận các yêu cầu (Requirements Validation). Căn cứ vào tài liệu đặc tả và các yêu cầu thực tế của hệ thống, họ sẽ phải trả lời câu hỏi “Tôi có đang mô tả đúng phần mềm hay không?”. Các tiêu chí để xác nhận gồm có:
o Tính chính xác (Correct)
o Tính khả thi (feasible)
o Tính cần thiết (necessary)
o Độ ưu tiên (prioritized) của các yêu cầu.
- Các phân tích viên (Requirements Analysts): Thực hiện quá trình xác minh các yêu cầu (Requirements Verification). Căn cứ vào tài liệu đặc tả và các yêu cầu người dùng, họ sẽ phải trả lời cho câu hỏi “Tôi có đang xây dựng phần mềm đúng không?”. Các tiêu chí xác minh gồm:
o Tính ngắn gọn, súc tích (concise)
o Khả năng truy vết (traceable)
o Không dư thừa (non-redundant)
o Tổ chức tốt (organized)
o Đúng quy chuẩn (conformant to standards)
o Khả năng kiểm chứng (verifiable)
- Ngoài ra còn có các thành viên của công ty phần mềm tham gia vào qua trình thực hiện phát triển phần mềm: Lập trình viên, các nhà kiểm thử…
1.12 Các chức năng của EA hỗ trợ mô hình hóa các yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
Mô hình hóa use case
Mô hình hóa dữ liệu
Mô hình hóa nghiệp vụ
Requirements Modeling
Trong Enterprise Architect bạn có thể thu được hoặc thấy các yêu cầu một cách trực tiếp theo dạng mô hình, sử dụng thành phần Requirement cho phép từ bảng Requirements của Toolbox. Đây được coi là những yêu cầu bên ngoài. (Bảng Requirements đặt ở phía bên trái của giao diện EA trong Toolbox)
Sử dụng thành phần UML cho phép các yêu cầu được theo dõi đến các thành phần UML khác như là những yêu cầu khác, những use case, test case, và các thành phần phân tích hoặc thiết kế. Thành phần này có thể được sử dụng để mô hình hóa hoặc tài liệu hóa bất kì yêu cầu nào từ những yêu cầu dạng nghiệp vụ cho đến những yêu cầu về hiệu năng hoặc bảo mật. Những yêu cầu này có thể được thể hiện theo dạng sơ đồ với những quan hệ đi kèm( Hình 1). Những thông tin cốt lõi phía sau bất kì một yêu cầu nào cũng được định nghĩa trong phần properties (Hình 2) người dùng định nghĩa các “attributes” sử dụng Tagged Values và Profiles
Hình 1
Hình 2
Cách tạo External Requirement
· Chuột trái vào ‘Custom Button’ trong ‘UML Toolbox’ để mở bảng custom
· Click và kéo ‘Requirement’ từ bảng vào sơ đồ
· EA cho phép bạn xác định vài thuộc tính của yêu cầu
o Một trường ‘Short Description’ sẽ hiển thị trên sơ đồ
o Nhìn ‘External Requirement Attributes’ bên dưới để rõ hơn
· Click Ok để kết thúc
· Những thuộc tính này có thể sử chữa lại sau này bằng cách double-click vào requirement
· Một requirement mới được hiển thị trong ‘Project View’
Tên của requirement có thể đơn giản là dạng text hoặc được đánh số phía trước tên nhãn. EA hỗ trợ đánh số tự động các requirements (xem phần auto-naming elements bên dưới)
Các thuộc tính của External Requirement
Double-click vào các Requirement để gán các thuộc tính cho requirement. EA hỗ trợ các thuộc tính của Requirement như là status, difficulty, priority, and type. Ví dụ: xem hình 2 bên trên. Thay đổi chỉnh sửa dễ dàng à nhần OK để apply.
Những đặc trưng hữu ích cho External Requirement
Khi sử dụng external requirements, có một vài cách để thay đổi dữ liệu và cách nhìn các chi tiết.
Ví dụ:
· Tạo những thuộc tính user-definable sử dụng tagged values
· Viewing Requirement sử dụng Elements list view hoặc diagram view
· Thiết lập những mối quan hệ giữa các yêu cầu, như quan hệ với các thành phần UML khác như use case, class, test case v.v
· Những quan hệ dò vết giữa những yêu cầu và những thành phần khác.
· Tạo một cây yêu cầu kế thừa sử dụng thành phần child hoặc packages.
Thêm Additional Attributes của Requirements
Thông thường có một chuỗi các thuộc tính yêu cầu được xác định cho một dự án nào đó. Bạn có thể nhập vào một số bất kì những thuộc tính thêm vào này như độ tin cậy, giá thành, độ trễ phạt thông qua việc sử dụng ‘tagged values’.
Tagged values có thể định nghĩa trên một one-off cơ bản cho vài thành phần hoặc được định nghĩa trức khi thêm vào trong việc tạo ra một thành phần mới.
Tagged values data cho một thành phần được cho phép như là một cửa sổ riêng biệt, để truy xuất sử dụng Ctrl + Shift + 6 ( hoặc từ Main menu View| Tagged Values). Ví dụ xem hình 3
Hình 3
Predefining Tagged Values Types for Requirements
Những thành phần trong EA, bao gồm những thành phần yêu cầu, có thể có một tập các thuộc tính mở rộng đã được định nghĩa cho một dự án. Các thuộc tính thành phần này có thể được định nghĩa trước sử dụng một UML profile hoặc EA Template. Ví dụ xem hình 4 một thành phần sử dụng tập tagged values predefined cho những yêu cầu của một dự án.
Hình 4
Những thuộc tính mở rộng này có thể thấy được trực tiếp trên sơ đồ. Để thiết lập chế độ này right-click vào diagram và trong menu context lựa chọn Properties| Elements| Show Compartments| [v] Tags. Ví dụ xem hình 5
Hình 5
Element Numbering
EA hỗ trợ việc tạo một cây phân cấp những thành phần dưới dạn package. Việc đánh số kết hợp với cấu trúc phân cấp cho phép các thành phần bên trong một Package được đánh số theo dạng 1.1.1. Những đặc trưng này có thể được thiết lập trên bất kì package nào và áp dụng cho những thành phần chứa trong root of package (không áp dụng cho child package)
Ví dụ Element hierarchy với Element Numbering
Hình 6
Để cho phép lựa chọn này
· Select một package trong Project Browser
· Right-click và từ menu context select: Show Level Numbering
Hình 7
Từ Project View, các thành phần được đánh số có thể được sắp xếp lại đơn giản bằng cách kéo một child element vào một element khác. Những elements con sẽ được đánh số lại để phù hợp với elements cha.
Hình 8
Different Views of Requirements Using the Element List View
Thông thường nhưng yêu cầu được định nghĩa bởi người dùng không giống với sơ đò UML. EA hỗ trợ một text-based view của những yêu cầu, trong khi vẫn duy trì cấu trúc phân cấp trong Project View.
Vài đặc trưng là:
· The Project View. Cái này có thể gắn ở phía trái màn hình để hiển thị cây phân cấp.
· The Element List View. Sơ đồ này có thể thiết lập về chế độ text view
o Để thay đổi chế độ diagram view và Elements List View từ main menu, sleect View| Element List.
· The Notes and Tagged Value windows có thể thiết lập là default view
o Để xem the notes window select View| Notes
o Để xem the tagged values window select View| Tagged Values.
Dưới đây là ví dụ của text-based mode
Hình 9
Bên dưới là ví dụ text-based với Tagged Value window và the Notes window được mở:
Hình 10
Việc mô hình hóa này còn một số phần nhưng nó dính sang phần ‘Traceability’ và ‘Change Control’ thuộc những câu khác nên các bạn tham khảo để chém thêm nhé.
1.13 Các chức năng của EA hỗ trợ xây dựng đặc tả yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL
Trả lời:
ü Tạo ra các yêu cầu phần mềm bên ngoài (External Requirements)
+ Tạo trong biểu đồ ( Diagram )
· Mở Custom pages trong Enterprise Architect UML Toolbox. Chọn Requirements
· Cầm đối tượng Requirement, thả vào trong biểu đồ
· Nhập tên và các thông tin khác cho Requirement. Save lại
+ Tạo trong gói ( Package)
· Nháy phải vào gói, chọn Insert | New Element ( hoặc Ctrl + M )
· Trong hộp thoại New Element, chọn Requirement
· Nhập tên và các thông tin khác cho Requirement. Save lại.
ü Tạo ra các yêu cầu phần mềm bên trong một Element khác (Internal Requirements)
Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu.
Để thực hiện việc này, ta thực hiện như sau:
· Mở hộp thoại Properties của Element.
· Chọn Tab Require
· Nhập tên Requirement và các thuộc tính của nó.
· Bấm Save để lưu Requirement lại
· Nếu muốn, bấm New để tạo tiếp Internal Requirement khác cho Element, cũng hoặc thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa )
· Bấm OK để đóng hộp thoại
ü Chuyển yêu cầu bên trong ra ngoài
· Mở hộp thoại Properties của Element. Chọn Tab Require
· Chọn Requirement cần chuyển. Bấm Move External
· Trong hộp thoại mở ra, chọn package để lưu External Requirement
ü Quản lý các thuộc tính cơ bản của yêu cầu:
Các thuộc tính cơ bản của yêu cầu được quản lý trong EA:
· Tên
· Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra)
· Độ khó
· Độ ưu tiên
· Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …)
· Ghi chú
· Các thông tin khác
ü Ghi chú các thông tin bổ sung
· Sử dụng thuộc tính Note
· Sử dụng đối tượng chú thích Note
· Sử dụng Tagged Values (lựa chọn, mở cửa sổ Tagged Values, tạo ra các cặp Key – Value lưu trữ các thông tin bổ sung cho yêu cầu )
ü Xóa, sắp xếp các yêu cầu
Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh.
ü Tạo cấu trúc phân cấp cho yêu cầu
Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.
Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn.
ü Đánh số cho các Requirement:
Nháy phải vào package, chọn Show Level Numbering
ü Kết xuất thành văn bản
· Lựa chọn Requirement cần kết xuất
· Vào menu, chọn Project | Documentation
· Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…)
· Trong hộp thoại mở ra, nhập các thông số cần thiết. Chú ý chọn Use template là requirement template
[n1]Các yêu cầu đối với bản đặc tả
Bạn đang đọc truyện trên: Truyen2U.Pro