ĐẶC TẢ CÁC YÊU CẦU PHI CHỨC NĂNG FUNCTIONAL 4.1 Các yêu cầu tương tác Accessibility This subsection specifies the following requirements associated with the degree to which the system
Trang 1TÊN CÔNG TY/ĐỢ VỊ/ TỔ CHỨC
[TÊN PHẦN MỀM/DỰ ÁN]
ĐẶC TẢ YÊU CẦU PHẦN MỀM [v1.0]
Người lập:
Ngày lập: ……/……./.………
Người xem xét:
Ngày lập: ……/……./.………
Người duyệt:
Ngày duyệt: ……/……./.………
ĐD khách hàng duyệt:
Ngày duyệt: ……/……./.………
Trang 2LỊCH SỬ THAY ĐỔI TÀI LIỆU
<dd/mm/yy> <Vx.y> <Mô tả chi tiết Mục, bảng, sơ đồ nào
thay đổi; nội dung thay đổi là gì>
<Họ tên người lập, nhóm lập>
Trang 3MỤC LỤC
2.5 Mô tả các xác thực chức năng (Functional validations) 7
Trang 44.7 Tính dễ chuyển mang (Portability) 11
5.2 Ràng buộc dữ liệu và nội dung (Data and Content Constraints) 13
5.5.3 Ràng buộc pháp lý và quy định (Legal and Regulatory Constraints) 14
Trang 51 GIỚI THIỆU CHUNG
1.1 Mục đích
<Trình bày vai trò, mục đích của tài liệu SRS: Tài liệu mô tả một cách đầy đủ, toàn diện các yêu cầu của phần mềm – đó là các yêu cầu chức năng, phi chức năng, các ràng buộc về mặt thiết kế >
<Ghi chú: tài liệu SRS mô tả các yêu cầu của phần mềm đối với toàn bộ hệ thống, hoặc đối với
từng hệ thống con Có nhiều kiểu cấu trúc cho tài liệu SRS Cấu trúc giới thiệu trong tài liệu này
là cấu trúc điển hình dùng cho các dự án áp dụng mô hình use-case (use-case modeling) Vì
vậy, tài liệu sẽ trình bày các use case, mô tả cho các use case và các đặc tả bổ sung, cũng như các thông tin hỗ trợ khác>
1.2 Phạm vi
<Mô tả ngắn gọn đặc điểm của phần mềm; lĩnh vực ứng dụng của phần mềm; phạm vi, đối tượng phục vụ của phần mềm; nhóm các hệ thống con, các mô hình Use-Case tương ứng > [Chỉ ra được tài liệu này dùng cho đối tượng nào?]
1.3 Các định nghĩa, thuật ngữ, từ viết tắt
<Mục này dành để giải thích cho các thuật ngữ và từ viết tắt dùng trong tài liệu, các định nghĩa
sử dụng trong tài liệu Có thể trình bày ngay trong mục này, cũng có thể tham chiếu tới một tài liệu riêng giải thích các thuật ngữ, từ viết tắt (gọi là Glossary) của dự án>
1.4 Tài liệu tham khảo
Trang 62 MÔ TẢ CHUNG HỆ THỐNG
2.1 Danh sách các tác nhân và mô tả vai trò
<Liệt kê các tác nhân của hệ thống> – tham khảo SRS_Gurubank
2.2 Danh sách các chức năng trong ứng dụng
<Liệt kê các use case theo mô hình use case Các use case tương ứng với các chức năng nào như đã mô tả trong tài liệu SRD Phải mapping use case và chức năng tương ứng mô tả ngắn gọn >
Mô tả các modun
UC_001 Tên use case Mô tả ngắn gọn Use case Ứng với chức năng nào như đã mô tả
trong SRD (mã số chức năng)
Ví dụ Balance Enquiry Manager
Customer
Customer: A customer can have
multiple bank accounts He can view balance of his accounts only
Manager: A manager can view balance
of all the customers who come under his supervision
…
Trong đó:
UC: Quy cách đánh số Use case
001, 002…: là số thứ tự của use case
2.3 Các mô tả giao diện
<Liệt kê các thông tin giao diện mô tả chức năng hệ thống-Tham khảo SRS_Guru 3.1>
- Chức năng: thuộc tính gọi tên trên giao diện chức năng
Trang 7Ví dụ:
Fund Transfer
● Payers account no
● Payees account no
● Amount
● Submit
● Reset
Change Password
● Old Password
● New Password
● Confirm Password
● Submit
● Reset
2.4 Các yêu cầu kỹ thuật (Technical Requirements)
<Liệt kê các yêu cầu dữ liệu cho các chức năng-Tham khảo SRS_Guru –mục 3.2 >
Ví dụ:
New Account
T1 Customer Id - Customer ID is required T2 Customer Id - Special character are not allowed T3 Customer Id - Characters are not allowed T3.1 Customer Id - First character cannot have space
2.5 Mô tả các xác thực chức năng (Functional validations)
<Mô tả các yêu cầu cần xác thực để thực hiện thông giao dịch, các điều kiện chuyển đổi giữa các modun, các chức năng ưu tiên tiên quyết cần thực hiện>
Ví dụ trong dự án guruBank tham khảo 3.3:
Balance Enquiry
Manager
F1 Manager can view balance of accounts associate with him
F2 Account number entered should exist in database
Customer
F3 Customer can view balance of only his accounts
F4 Account number entered should exist in database
Trang 83 ĐẶC TẢ CHỨC NĂNG (Functional specification)
<Phần này mô tả một cách chi tiết từng yêu cầu cụ thể, cho phép các thành viên tham gia dự
án căn cứ vào đó để xây dựng một phần mềm có chất lượng tốt nhất Với cách tiếp cận theo
mô hình UseCase (UC), các yêu cầu phần mềm được mô tả theo các UC và trong các đặc tả
bổ sung>
3.1 UC_001_Tên use case
Trong đó:
UC_001: là mã Use case
Tên use case: Tên Use case được mô tả ở mục 2.3
3.1.1 Mô tả use case UC_001
Use case: {Mã use case_Tên use case}
Mục đích: <Kết quả cần đạt được của Use case>
Mô tả: <Mô tả chi tiết use case, vai trò của Use case>
Tác nhân: <Các tác nhân tác động đến Use case>
Điều kiện trước: <Các điều kiện cần phải thực hiện trước khi thực hiện Use Case>
Luồng sự kiện chính
(Basic flows)
<Các luồng sự kiện chính, thành công của Use case theo trình tự thời gian>
Luồng sự kiện phụ
(Alternative Flows):
<Các luồng sự kiện ngoại lệ, không thành công của Use case theo trình tự thời gian>
Điều kiện sau: <Kết quả thu được sau khi thực hiện đúng & kết thúc UseCase>
3.1.2 Biểu đồ
<Biêu đồ (diagram) chi tiết> nếu có vẽ chi tiết
3.2 UC_002_Tên use case
Trong đó:
UC_002: là mã use case
Tên use case: Tên use case được mô tả ở mục 2.3
Trang 93.2.1 Mô tả use case UC_002
Use case: {Mã use case_Tên use case}
Mục đích: <Kết quả cần đạt được của Use case>
Mô tả: <Mô tả chi tiết use case, vai trò của Use case>
Tác nhân: <Các tác nhân tác động đến Use case>
Điều kiện trước: <Các điều kiện cần phải thực hiện trước khi thực hiện Use Case>
Luồng sự kiện chính
(Basic flows)
<Các luồng sự kiện chính, thành công của Use case theo trình tự thời gian>
Luồng sự kiện phụ
(Alternative Flows):
<Các luồng sự kiện ngoại lệ, không thành công của Use case theo trình tự thời gian>
Điều kiện sau: <Kết quả thu được sau khi thực hiện đúng & kết thúc UseCase>
3.2.2 Biểu đồ
<Biêu đồ (diagram) chi tiết> nếu có vẽ chi tiết
4 ĐẶC TẢ CÁC YÊU CẦU PHI CHỨC NĂNG (FUNCTIONAL)
4.1 Các yêu cầu tương tác (Accessibility)
This subsection specifies the following requirements associated with the degree to which the system must be accessible to people with disabilities:
mục này chỉ định các yêu cầu sau liên quan đến thiết kế hệ thống phải có thể truy cập được đối với người khuyết tật
ví dụ:
• ACC-1) Any graphical user interfaces of the app shall be usable by persons with color blindness
• ACC-2) Any graphical user interfaces of the app shall use an adequate font size to be usable
by persons with limited visual acuity
4.2 Các yêu cầu kiểm tra độc lập (Audit-ability)
< This subsection specifies the following requirements associated with the degree to which the system must support independent auditing of its events CRUD at database
mục này chỉ định các yêu cầu sau liên quan đến mức độ mà hệ thống phải hỗ trợ kiểm tra độc lập các sự kiện CRUD của nó tại cơ sở dữ liệu:>
VÍ DỤ:
• AUD-1) The app shall maintain a record for each insert/update/delete action:
− Authenticated user
Trang 10− IP address of client
4.3 Các yêu cầu về tính chính xác (Correctness)
< This subsection specifies the following requirements concerning the degree of correctness of the system’s outputs:
mục này chỉ định các yêu cầu sau liên quan đến mức độ chính xác của đầu ra của hệ thống>
Ví dụ: • COR-1) Values of money shall be correct to the nearest “dong” - Giá trị của tiền phải chính xác đến “đồng” gần nhất
• COR-2) Values of time shall be correct to the nearest second - Giá trị thời gian phải chính xác đến giây gần nhất
4.4 Các yêu cầu tương thích
< This subsection specifies the following requirements associated with the ease with which the system can be integrated with other system (e.g., browsers, legacy applications, and required databases)
Mô tả tính tương tích với các hệ thống khác (trình duyệt, ứng dụng cũ, csdl bắt buộc)
Ví dụ:
The app shall interoperate with the following browsers:
• IOP-1) Internet Explorer 11
• IOP-2) Google Chrome 34
• IOP-2) Mozilla Firefox 12
< mục này chỉ định các yêu cầu sau liên quan đến môi trường mà hệ thống có thể được tích hợp (ví dụ: trình duyệt, ứng dụng cũ và cơ sở dữ liệu bắt buộc>
4.5 Các yêu cầu bảo trì hệ thống (Maintainability)
Nếu ko có yc ghi none
This subsection specifies the following requirements associated with the ease with which the system can be maintained:
mục này chỉ định các yêu cầu sau liên quan đến sự dễ dàng mà hệ thống có thể được bảo trì
ví dụ:
M-1) The app shall permit the swapping and upgrade of hardware without down time
M-2) The app shall permit the upgrade of software without down time
M-3) The Mean Time To Fix (MTTF) shall not exceed one person day
4.6 Các yêu cầu về hiệu năng (Performance)
This subsection specifies the following requirements associated with the speed with which the system shall function
Trang 11Nếu ko có yc ghi none
4.6.1 Hiệu suất (Capacity)
This subsection specifies the following requirements concerning the minimum number of objects that the system can support:
mục này chỉ định các yêu cầu sau liên quan đến số lượng đối tượng tối thiểu mà hệ thống có thể hỗ trợ
PER-1) The system shall support a minimum of 100 employees
PER-2) The system shall support a minimum of 10,000 users
PER-3) The system shall support a minimum of 10,000 simultaneous interactions
Nếu ko có yc ghi none
4.6.2 Thời gian đáp ứng (Response Time)
This subsection specifies the following requirements concerning the maximum time that is permitted for the system to respond to requests:
mục này chỉ định các yêu cầu sau liên quan đến thời gian tối đa được phép để hệ thống phản hồi các yêu cầu:
PER-4) All system responses shall occur within 10 seconds
Nếu ko có yc ghi none
4.6.3 Thông lượng (Throughput)
This subsection specifies the following requirements concerning how many executions of a given system operation or use case path must the system be able execute in a unit of time:
mục này chỉ định các yêu cầu sau liên quan đến số lượng thực thi của một hoạt động hệ thống hoặc đường dẫn nhất định hệ thống phải thực thi trong một đơn vị thời gian:
Nếu ko có yc ghi none
4.7 Tính dễ chuyển mang (Portability)
This subsection specifies the following requirements associated with the ease with which the system can be moved from one environment (e.g., hardware, operating system) to another
mục này chỉ định các yêu cầu sau liên quan đến việc hệ thống có thể được di chuyển dễ dàng
từ môi trường này (ví dụ: phần cứng, hệ điều hành) sang môi trường khác
The app shall enable users to use the following environments (e.g., platform and operating system) to interact with The system
Ví dụ: User Personal Computer:
- POR-1) PC with minimum of Celeron chip, 2 GBs of RAM, and a 256 kbps ADSL modem
- Operating Systems:
+ POR-2) Windows 7
Trang 12+ POR-3) Fedora Linux 16
+ POR-4) Ubuntu 14
Nếu ko có yc ghi none
4.8 Độ tin cậy (Reliability)
This subsection specifies the following requirements associated with the reliability (e.g., mean time between failures, number of failures per unit time) of the system
mục này chỉ định các yêu cầu sau liên quan đến độ tin cậy (ví dụ: thời gian trung bình giữa các lần hỏng hóc, số lần hỏng hóc trên một đơn vị thời gian) của hệ thống
REL-1) The mean time between failures (MTBF) shall exceed 3 months
4.9 Khả năng sử dụng lại (Reusability)
This subsection specifies the following requirements associated with the degree to which the system can be used for purposes other than originally intended (e.g., as part of other applications)
mức độ mà hệ thống có thể được sử dụng cho các mục đích khác với mục đích ban đầu
REU-1) The app shall incorporate a database continuous availability layer
REU-2) The app shall reuse common classes such as name, address, telephone number, and currency
REU-3) The app shall reuse software for sending emails
Nếu ko có yc ghi none
4.10 Độ bền (Robustness)
This subsection specifies the following requirements associated with the degree to which the system continues to properly function under abnormal circumstances
mục này chỉ định các yêu cầu sau liên quan đến mức độ mà hệ thống tiếp tục hoạt động bình thường trong các trường hợp bất thường (khả năng hòi phục hệ thống)
ROB-1) The app should gracefully handle invalid input (i.e., detect invalid input, request valid input, and not crash) from all externals:
The human actors
The Authorization Processor Gateway
ROB-2) The app should gracefully handle hardware failures (i.e provide hot failover, notify the system operator, and not crash)
Nếu ko có yc ghi none
4.11 Tính an toàn (Safety)
This subsection specifies the following requirements associated with the degree to which the system does not directly or indirectly (e.g., via inactivity) cause accidental harm to life or
Trang 13mục này chỉ định các yêu cầu sau liên quan đến mức độ an toàn trực tiếp hoặc gián tieps liên quan: các tình huống bất thường như mất điện, thiệt hại do tai nạn trên môi trường mạng hoặc các tài sản như tiền hoặc dữ liệu
SAF-1) The system shall not accidentally lose user account information
Nếu ko có yc ghi none
The section documents the major architecture, design, and implementation constraints on the system
Phần này ghi lại các ràng buộc về kiến trúc, thiết kế và triển khai chính trên hệ thống
Liệt kê các yêu cầu về thiết kế CHUNG giao diện: tỷ lệ của sổ (3x4, 4x6, ), font, color, shape, message, display; language, dictation, vvv
Nếu ko có yc ghi none
5.1 Quy tắc kinh doanh (Business Rules)
The subsection documents all required data design constraints
mục ghi lại tất cả các ràng buộc thiết kế dữ liệu cần thiết
Nếu ko có yc ghi none
5.2 Ràng buộc dữ liệu và nội dung (Data and Content Constraints)
mục ghi lại tất cả các ràng buộc dữ liệu cần thiết
Nếu ko có yc ghi none
5.3 Cơ sở dữ liệu (Databases)
The subsection documents all required design constraints regarding the use of databases
mục ghi lại tất cả các ràng buộc thiết kế cần thiết liên quan đến việc sử dụng cơ sở dữ liệu
Nếu ko có yc ghi none
5.4 CÁC YÊU CẦU VỀ PHẦN CỨNG (HARDWARE CONTRAINS)
< The subsection documents all required constraints associated with minimum or actual hardware
- mục ghi lại tất cả các ràng buộc bắt buộc liên quan đến phần cứng tối thiểu hoặc phần cứng thực tế >
Nếu ko có yc ghi none
5.5 CÁC YÊU VỀ PHẦN MỀM (Software Constraints)
The subsection documents all required software constraints
Trang 145.5.1 Ngôn ngữ bậc cao (High-Level Languages)
The subsection documents all required design constraints associated with the use of high-level programming languages
• SYSDC-HLL-1) Application server software shall be written in Java
• SYSDC-HLL-2) Employee client software shall be written in Java
• SYSDC-HLL-3) User client software shall be written in DHTML, CSS, and JavaScript webpages
• SYSDC-HLL-4) Where practical, data shall be defined and documented using XML
Nếu ko có yc ghi none
5.5.2 Chuẩn công nghiệp (Industry Standards)
The subsection documents all required design constraints associated with industry standards DC-STD-1) The system shall conform to ISO 10646 (Unicode UTF-8) and ISO 10646-1 (Unicode UTF-16) standards for character set encoding
• www.unicode.org
• ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/ISO-10646-UTF-8.html
• ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/ISO-10646-UTF-16.html
DC-STD-2) The system shall conform to ISO 4217, codes for the representation of currencies
• www.xe.net/gen/iso4217.htm
DC-STD-3) The system shall conform to ISO 31, codes for units of measure
• www.unece.org/trade/rec/rec20en.htm
DC-STD-4) The system shall conform to ISO639-1 Languages, codes for the representation of languages
• http://sunsite.berkeley.edu/amher/iso_639.html
DC-STD-5) The system shall conform to ISO 3166-1, codes for the representation of names of countries
• www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/index.html
DC-STD-6) The system shall conform to ISO 8601, representation of dates and times
• www.state.ak.us/local/akpages/ADMIN/info/iso8601.htm
Nếu ko có yc ghi none
5.5.3 Ràng buộc pháp lý và quy định (Legal and Regulatory Constraints)
The subsection documents all required design constraints associated with legal and regulatory constraints
Nếu ko có yc ghi none