Đặc điểm kỹ thuật của một trang web là gì năm 2024

Đặc tả yêu cầu là một phần quan trọng của quy trình Kỹ thuật yêu cầu. Đây là giai đoạn thứ ba, sau khi Nắm bắt và Phân tích Yêu cầu. Mục đích là tạo một tài liệu, hoặc Đặc tả yêu cầu, với mức độ chi tiết tương ứng. Tài liệu này sẽ bao gồm tất cả các yêu cầu được áp dụng đối với việc thiết kế và xác minh sản phẩm. Nó cũng sẽ chứa các thông tin liên quan khác cần thiết cho việc thiết kế, xác minh và bảo trì sản phẩm.

Đặc điểm kỹ thuật yêu cầu là gì?

Đặc tả yêu cầu, còn được gọi là tài liệu, là một quá trình ghi lại tất cả các yêu cầu của hệ thống và người dùng dưới dạng một tài liệu. Các yêu cầu này phải rõ ràng, đầy đủ, toàn diện và nhất quán.

Trong hoạt động thu thập, chúng tôi thu thập tất cả các yêu cầu từ nhiều nguồn khác nhau. Trong quá trình phân tích và hoạt động đàm phán, chúng tôi phân tích và hiểu rõ những yêu cầu đó. Bây giờ, chúng ta phải chuẩn bị một tài liệu chính thức giải thích những yêu cầu đó. Đó là đặc điểm kỹ thuật yêu cầu. Nói một cách chính xác, đó là quá trình ghi lại tất cả các nhu cầu và ràng buộc của người dùng và hệ thống một cách rõ ràng và chính xác.

Yêu cầu hệ thống là gì?

Yêu cầu hệ thống có thể được gọi là phiên bản mở rộng của các yêu cầu người dùng. Yêu cầu hệ thống đóng vai trò là điểm bắt đầu cho bất kỳ thiết kế hệ thống mới nào. Các yêu cầu này là một mô tả chi tiết về các yêu cầu của người dùng mà hệ thống phải đáp ứng.

Yêu cầu người dùng là gì?

Yêu cầu của người dùng là sự kết hợp của các yêu cầu chức năng và phi chức năng. Các yêu cầu của người dùng này phải được thiết kế theo cách mà người dùng không có bất kỳ kiến ​​thức kỹ thuật nào có thể hiểu được chúng một cách dễ dàng. Do đó, chúng phải được viết bằng ngôn ngữ tự nhiên bằng các bảng, biểu mẫu và sơ đồ đơn giản. Ngoài ra, hãy đảm bảo rằng tài liệu không có chi tiết về thiết kế hệ thống, phần mềm hoặc ký hiệu chính thức.

Yêu cầu chức năng và phi chức năng là gì?

Các yêu cầu chức năng, như tên gọi, mô tả các chức năng của hệ thống được thiết kế. Nó là một mô tả về hệ thống sẽ như thế nào và nó sẽ hoạt động như thế nào để thỏa mãn nhu cầu của người dùng. Chúng cung cấp mô tả rõ ràng về cách hệ thống phải phản hồi với một lệnh cụ thể, các tính năng và những gì người dùng mong đợi.

Các yêu cầu phi chức năng giải thích các hạn chế và ràng buộc của hệ thống được thiết kế. Các yêu cầu này không có bất kỳ tác động nào đến chức năng của ứng dụng. Hơn nữa, có một thực tế phổ biến là phân loại phụ các yêu cầu phi chức năng thành các loại khác nhau như

• Giao diện người dùng
• Độ tin cậy
• Bảo mật
• HIỆU QUẢ
• bảo trì
• Tiêu chuẩn

Phân loại nhỏ các yêu cầu phi chức năng là một cách thực hiện tốt. Nó hữu ích khi tạo danh sách kiểm tra các yêu cầu cần được đáp ứng trong hệ thống được thiết kế.

Các yêu cầu phi chức năng cũng quan trọng như các yêu cầu chức năng. Nếu các yêu cầu chức năng chỉ rõ hệ thống phải làm gì, thì các yêu cầu phi chức năng mô tả cách hệ thống sẽ thực hiện. Ví dụ: ứng dụng mới sẽ cung cấp cho chúng tôi danh sách cuối cùng của tất cả người dùng được kết nối. Đó là một phần của yêu cầu chức năng. Nếu yêu cầu nói rằng hệ thống sẽ chỉ hoạt động trên hệ thống Windows và Linux, thì đó sẽ là một phần của các yêu cầu phi chức năng.

Sự khác biệt duy nhất giữa hai hệ thống là hệ thống không thể hoạt động nếu không đáp ứng tất cả các yêu cầu chức năng. Mặt khác, hệ thống sẽ cung cấp cho bạn kết quả mong muốn ngay cả khi nó không thỏa mãn các yêu cầu phi chức năng.

Lợi ích của việc có Đặc tả yêu cầu là gì?

Có rất nhiều lợi ích khi có một đặc tả yêu cầu. Một số trong số họ được liệt kê dưới đây:

• Giúp đảm bảo rằng tất cả các bên liên quan đều có hiểu biết chung về hệ thống sẽ được phát triển. Điều này tránh mọi hiểu lầm trong các giai đoạn phát triển sau này.
• Đóng vai trò là điểm tham khảo cho tất cả các bên liên quan trong quá trình phát triển.
• Giúp xác định bất kỳ khoảng trống nào trong các yêu cầu ở giai đoạn đầu.
• Giảm chi phí tổng thể và thời gian phát triển vì nó tránh phải làm lại do những thay đổi trong yêu cầu.

Tiêu chuẩn về yêu cầu viết?

EARS sẽ là một phương pháp luận hiệu quả ở đây. Nó là viết tắt của Cú pháp Tiếp cận Yêu cầu Dễ dàng. Trong phương pháp này, chúng tôi viết ngôn ngữ rõ ràng, ngắn gọn và dễ hiểu. Điều này cải thiện toàn bộ quy trình kỹ thuật yêu cầu và đơn giản hóa công việc bằng cách làm cho mọi thứ trở nên khá dễ hiểu.

Để đạt được điều này, đây là một số nguyên tắc cần phải ghi nhớ khi viết các yêu cầu. Chúng liên quan đến:

• Mỗi yêu cầu phải ở dạng một câu hoàn chỉnh. Không được sử dụng dấu đầu dòng, từ viết tắt, viết tắt hoặc từ thông dụng. Cố gắng tạo những câu ngắn gọn, trực tiếp và hoàn chỉnh.
• Đảm bảo rằng mỗi yêu cầu đều có chủ ngữ, vị ngữ và động từ thích hợp. Chủ đề sẽ là kiểu người dùng hoặc hệ thống mà chúng ta đang nói đến. Vị từ sẽ là các điều kiện hoặc hành động hoặc kết quả mong muốn mà chúng ta mong đợi. Chúng ta phải sử dụng các từ như 'shall', 'will', và 'must' để thể hiện một số loại cần thiết, và các từ như 'may' để thể hiện sự tùy chọn trong yêu cầu.
• Mỗi yêu cầu phải giải thích một cách hiệu quả kết quả cuối cùng mà chúng ta mong muốn từ hệ thống.
• Ngoài ra, yêu cầu phải mô tả chất lượng mà chúng tôi mong đợi từ hệ thống. Nó hữu ích khi chúng tôi đo lường kết quả cuối cùng và xem liệu yêu cầu có được thực hiện đúng hay không.

Các loại yêu cầu Thông số kỹ thuật:

Có rất nhiều loại thông số kỹ thuật yêu cầu. Chúng bao gồm Thông số kỹ thuật yêu cầu chức năng (FRS), Đặc điểm yêu cầu hiệu suất (PRS), Đặc điểm yêu cầu cấu hình (CRF), Đặc điểm yêu cầu kinh doanh (BRS), Đặc điểm yêu cầu độ tin cậy (RRF), Đặc điểm yêu cầu tương thích (CRF) và Đặc điểm yêu cầu phần mềm (SRS ).

Đặc điểm kỹ thuật yêu cầu chức năng: Đặc tả yêu cầu chức năng (FRS) là tài liệu ghi lại các chức năng mà hệ thống phải thực hiện. Nó bao gồm tất cả các chức năng, cơ sở, các biện pháp an ninh và các thông tin liên quan khác. Nói một cách đơn giản, FRS là một tài liệu chứa mọi thứ mà một hệ thống cụ thể phải làm.

Thông số kỹ thuật yêu cầu hiệu suất: Đặc tả yêu cầu hiệu suất (PRS) là một tài liệu ghi lại tất cả các khía cạnh liên quan đến hiệu suất của một hệ thống. Điều này bao gồm thời gian phản hồi, thông lượng dữ liệu, hiệu quả, khả năng mở rộng, v.v. Về cơ bản, bất kỳ thứ gì có thể được định lượng và cải thiện đều thuộc danh mục PRS.

Đặc điểm kỹ thuật yêu cầu cấu hình: Đặc tả yêu cầu cấu hình (CRS) là tài liệu ghi lại tất cả thông tin liên quan đến cấu hình của hệ thống. Điều này bao gồm các chi tiết như nền tảng được hỗ trợ, phần mềm / phần cứng phụ thuộc, yêu cầu hệ thống tối thiểu, v.v.

Đặc điểm kỹ thuật yêu cầu kinh doanh: Đặc tả yêu cầu nghiệp vụ (BRS) là một tài liệu ghi lại tất cả các khía cạnh liên quan đến nghiệp vụ của một hệ thống. Điều này bao gồm các tính năng như quản lý người dùng, bảo mật, toàn vẹn dữ liệu, v.v. Về cơ bản, bất kỳ thứ gì ảnh hưởng đến hoạt động kinh doanh của hệ thống đều thuộc danh mục BRS.

Thông số kỹ thuật yêu cầu về độ tin cậy: Đặc tả yêu cầu độ tin cậy (RRF) là tài liệu thu thập tất cả thông tin liên quan đến độ tin cậy của hệ thống. Điều này bao gồm các khía cạnh như thời gian hoạt động, thời gian khôi phục, tỷ lệ lỗi, v.v.

Thông số kỹ thuật yêu cầu tương thích: Đặc tả yêu cầu tương thích (CRF) là tài liệu thu thập tất cả thông tin liên quan đến khả năng tương thích của hệ thống. Điều này bao gồm các khía cạnh như nền tảng được hỗ trợ, phụ thuộc phần mềm / phần cứng, yêu cầu hệ thống tối thiểu, v.v.

Thông số kỹ thuật yêu cầu phần mềm: Đặc tả yêu cầu phần mềm (SRS) là một tài liệu ghi lại tất cả các khía cạnh liên quan đến phần mềm của một hệ thống. Điều này bao gồm các khía cạnh như chức năng, hiệu suất, khả năng mở rộng, v.v. Về cơ bản, bất kỳ thứ gì ảnh hưởng đến hoạt động phần mềm của hệ thống đều thuộc danh mục SRS.

Đặc điểm kỹ thuật yêu cầu phần mềm Vs Đặc điểm yêu cầu kinh doanh:

Đôi khi người ta trộn lẫn các khái niệm về phần mềm và các đặc tả yêu cầu nghiệp vụ. Trên thực tế, cả hai đều khá khác nhau.

Sự khác biệt chính giữa đặc tả yêu cầu phần mềm và đặc tả yêu cầu kinh doanh là cái trước nắm bắt tất cả thông tin liên quan đến phần mềm trong khi cái sau nắm bắt tất cả thông tin liên quan đến doanh nghiệp.

Đặc điểm kỹ thuật yêu cầu kinh doanh (BRS)Đặc điểm kỹ thuật yêu cầu phần mềm (SRS)Đây là một tài liệu chính thức mô tả các yêu cầu khác nhau do khách hàng / các bên liên quan cung cấp.Nó chỉ định các yêu cầu chức năng và phi chức năng có trong phần mềm. Nó bắt nguồn từ các yêu cầu và tương tác của khách hàng.Nó có nguồn gốc từ Đặc tả yêu cầu kinh doanh (BRS).Nó được tạo ra bởi một nhà phân tích kinh doanh.Nó được tạo ra bởi một nhà phân tích hệ thống hoặc một kiến ​​trúc sư hệ thống hoặc một nhà phân tích kinh doanh. Nó mô tả các thông số kỹ thuật chức năng của phần mềm ở mức rất cao.Nó mô tả cả các đặc tính kỹ thuật và chức năng của phần mềm cũng ở mức cao.Nó giải quyết các yêu cầu kinh doanh.Nó giải quyết các nguồn lực mà công ty cung cấp.Nó xác định nhu cầu của khách hàng. Tài liệu được sử dụng từ đầu đến cuối dự án.Nó mô tả cách thức hoạt động của doanh nghiệp khi sử dụng phần mềm hoặc ứng dụng.Bảng và trường hợp sử dụng không được bao gồm.Bảng và trường hợp sử dụng được bao gồm.

Đặc điểm của Tài liệu Đặc tả Yêu cầu Phần mềm:

• Chính xác - Mục tiêu của một tài liệu SRS là dễ hiểu. Không có gì nên không rõ ràng, vì vậy không có tranh chấp giữa các bên liên quan.
• Đo lường - Các yêu cầu trong tài liệu SRS của bạn phải có thể đo lường được, do đó thành phẩm có thể được xác nhận và chứng nhận so với các yêu cầu.
• Hoàn thành - Tài liệu SRS phải bao gồm đủ thông tin để nhóm phát triển và người kiểm tra của bạn hoàn thiện sản phẩm và đảm bảo rằng nó đáp ứng các yêu cầu của người dùng mà không có lỗi.
• Khả thi - Các yêu cầu phải phản ánh tình trạng thực tế của công việc, bao gồm chi phí, thời gian và công nghệ. Chúng không nên phụ thuộc vào những tiến bộ công nghệ trong tương lai.
• Linh hoạt - Vì hoàn cảnh có thể thay đổi tại nơi làm việc, tài liệu SRS của bạn phải đủ thích ứng để đáp ứng các thay đổi. Đừng bao gồm tài liệu thừa trong một số phần sẽ phải được cập nhật mỗi khi có sự thay đổi.
• Kiểm chứng - Mọi người trong nhóm phát triển nên có quyền truy cập vào tài liệu để họ có thể tham khảo nó thường xuyên khi được yêu cầu. Bởi vì các yêu cầu phải rõ ràng, các thành viên trong nhóm không muốn có thêm thông tin. Tất cả chúng phải có thể truy cập được trong tài liệu SRS.
• Phù hợp - Các yêu cầu phải tương thích. Không được mâu thuẫn giữa các phần của tài liệu yêu cầu của bạn. Tài liệu phải được cấu trúc nhất quán và thuật ngữ được sử dụng theo cùng một cách xuyên suốt.
• Không có ràng buộc triển khai - Nói chung, một tài liệu SRS phải đủ chi tiết để hoàn thành công việc nhưng không quá cụ thể đến mức nó ngừng phát triển. Rất nhiều sự phát triển dựa trên các dịch vụ của bên thứ ba mà các nhà phát triển không có quyền kiểm soát.
• Chính xác - Các yêu cầu quy định trong các tài liệu phải rất chính xác để tránh bất kỳ loại nhầm lẫn nào. Chúng không được có bất kỳ sơ hở, không rõ ràng, chủ quan, so sánh nhất hoặc so sánh.

Các thành phần cần thiết của SRS:

Các phần chính của đặc tả yêu cầu phần mềm là:

• Người điều hành kinh doanh - Các lý do tại sao khách hàng đang tìm cách xây dựng hệ thống được mô tả trong phần này. Phần này bao gồm thêm những vấn đề mà khách hàng đang gặp phải với hệ thống hiện tại và những cơ hội mà hệ thống mới sẽ mang lại.
• MÔ HÌNH KINH DOANH - Mô hình kinh doanh mà hệ thống được hỗ trợ sẽ được thảo luận trong phần này. Nó còn bao gồm nhiều chi tiết khác như bối cảnh tổ chức và kinh doanh, các chức năng kinh doanh chính và sơ đồ quy trình của hệ thống.
• Yêu cầu về chức năng và hệ thống - Phần này thường nêu chi tiết các yêu cầu được tổ chức theo cấu trúc phân cấp. Các yêu cầu chức năng ở cấp cao nhất và các yêu cầu hệ thống chi tiết được liệt kê dưới dạng các mục con.
• Các trường hợp sử dụng hệ thống - Phần này bao gồm sơ đồ trường hợp sử dụng Ngôn ngữ mô hình thống nhất (UML) giải thích tất cả các thực thể bên ngoài quan trọng sẽ tương tác với hệ thống và các trường hợp sử dụng khác nhau mà chúng sẽ phải thực hiện.
• Yêu cầu kỹ thuật - Phần này thảo luận về tất cả các yêu cầu phi chức năng tạo nên môi trường kỹ thuật và các giới hạn kỹ thuật mà phần mềm sẽ hoạt động.
• Chất lượng hệ thống - Trong phần này, nhiều phẩm chất của hệ thống được xác định như độ tin cậy, khả năng phục vụ, bảo mật, khả năng mở rộng, tính sẵn sàng và khả năng bảo trì.
• Hạn chế và giả định - Phần này mô tả tất cả các giới hạn được áp dụng đối với thiết kế hệ thống theo quan điểm của khách hàng. Các giả định khác nhau của nhóm kỹ sư về những gì sẽ xảy ra trong quá trình phát triển cũng được thảo luận ở đây.
• Tiêu chí chấp nhận - Chi tiết về tất cả các điều kiện phải đáp ứng trước khi hệ thống được bàn giao cho khách hàng cuối cùng sẽ được thảo luận trong phần này.

Cấu trúc của một SRS:

1. Giới thiệu -

Phần giới thiệu giải thích ý nghĩa SRS nói chung, phạm vi của nó đối với nhóm của bạn và cấu trúc của nó.

1.1. Mục đích

Ở đây, giải thích mục tiêu và cấu trúc của tài liệu phần mềm SRS: các loại yêu cầu sẽ được giải quyết, cũng như nhân sự sẽ sử dụng nó.

Giữ cho phần này ngắn gọn: 1-2 đoạn văn là đủ.

1.2. Đối tượng dự định

Bạn có thể đi sâu và giải thích cách các bên và nhóm liên quan sẽ làm việc với SRS, cũng như tham gia vào quá trình phát triển SRS. Họ thường là chủ sở hữu sản phẩm, nhà đầu tư, nhà phân tích kinh doanh, nhà phát triển, đôi khi là người kiểm tra và nhân viên vận hành. Toàn bộ cấu trúc được xác định bởi cách tiếp cận phát triển phần mềm của bạn và thiết lập tổ chức của nhóm.

1.3. Mục đích sử dụng

Mô tả các tình huống mà nhóm của bạn sẽ sử dụng SRS. Thông thường, nó được sử dụng trong các trường hợp sau:

• thiết kế và động não các tính năng mới
• lập kế hoạch thời gian dự án, nước rút, ước tính chi phí
• đánh giá rủi ro
• giám sát và đo lường thành công của nhóm
• các tình huống xung đột khi các bên liên quan có tầm nhìn khác nhau về một sản phẩm được thực hiện tốt.

KHAI THÁC. Phạm vi

Phần này bao gồm phạm vi của sản phẩm, vì vậy bạn sẽ cần phải trình bày tổng quan nhanh về hệ thống - mục đích chính, chức năng và vị trí của nó. Nó có thể so sánh với cách bạn giải thích một sản phẩm tại cuộc họp các bên liên quan ngoại trừ việc nó được phép nghiên cứu sâu hơn về các chi tiết kỹ thuật.

Phần này phải mô tả:

• Tất cả các loại người dùng dự kiến ​​sẽ tương tác với hệ thống
• Tất cả các phần thiết yếu của kiến ​​trúc

1.5 Định nghĩa và từ viết tắt

Các thành phần nêu trên tạo thành một định nghĩa. Các định nghĩa cung cấp thông tin về chức năng, công nghệ cơ bản, cá nhân mục tiêu, thực thể kinh doanh (người dùng, khách hàng, người trung gian) và các bên liên quan. Bạn có thể sử dụng một từ viết tắt để viết SRS của mình nhanh hơn nếu bạn chọn làm như vậy. Tài liệu sẽ có thể đọc được miễn là có bao gồm bảng định nghĩa.

Trong suốt tài liệu của bạn, nhóm thường xuyên sử dụng một số từ nhất định. Loại bỏ mọi hiểu lầm tiềm ẩn, cho phép các nhà phát triển mới tham gia và giải quyết các tình huống xung đột sẽ dễ dàng hơn nếu bạn hiểu rõ nghĩa của những từ này.

2. Mô tả chung

Trong phần thứ hai, bạn mô tả các tính năng chính của sản phẩm, người dùng mục tiêu và phạm vi hệ thống cho người đọc. Mô tả này chỉ tập trung vào các tính năng chính và kiến ​​trúc phần mềm mà không đi sâu vào chi tiết cụ thể về các tiện ích bổ sung và kết nối.

2.1 Nhu cầu của Người dùng

Phần này là một vấn đề lựa chọn, vì vậy một số tổ chức chọn không đưa nó vào tài liệu kỹ thuật SRS của họ. Chúng tôi tin rằng tốt hơn hết bạn nên liệt kê các vấn đề bạn muốn giải quyết với chức năng của mình ngay bây giờ. Nó sẽ hữu ích sau này trong khi các chức năng động não và giám sát. Bạn có thể quay lại phần này bất kỳ lúc nào trong quá trình phát triển sản phẩm và xem liệu nhóm trải nghiệm người dùng có đi lạc khỏi con đường đã định hay không.

Nhu cầu đề cập đến các vấn đề mà người dùng sẽ có thể giải quyết với hệ thống. Bạn có thể chia những nhu cầu này thành các danh mục phụ nếu bạn đối phó với đối tượng được phân khúc cao. Cố gắng không đi vào chi tiết về nhu cầu của từng người dùng. Bạn cần để lại một khoảng trống để giải thích, đề phòng trường hợp một vấn đề trở nên quan trọng hơn bạn nghĩ ban đầu.

2.2 Giả định và Phụ thuộc

Giả định là những giả định của nhóm về sản phẩm và khả năng của sản phẩm sẽ đúng trong 99% tình huống. Chẳng hạn, thật tự nhiên khi giả định rằng một nền tảng hỗ trợ người lái xe điều hướng vào ban đêm sẽ được sử dụng chủ yếu ở chế độ ban đêm.

Ý nghĩa của các giả định là gì? Chúng cho phép bạn tập trung vào các tính năng quan trọng nhất của ứng dụng trước tiên. Giả định này giúp hiểu rằng các nhà thiết kế phải phát triển một giao diện phù hợp với tầm nhìn trong bóng tối cho một trợ lý lái xe ban đêm. Một số người dùng chắc chắn có thể mở ứng dụng trong ngày, nhưng đó là một khoảng thời gian dài, vì vậy bạn không cần phải đưa các yếu tố liên quan vào nguyên mẫu ngay lập tức.

3. Các tính năng và yêu cầu của hệ thống

Phần này trình bày chi tiết các tính năng của sản phẩm và tiêu chí thực thi. Vì hai phần trước đề cập đến toàn bộ sản phẩm, bạn sẽ tìm thấy mô tả toàn diện hơn ở đây.

3.1 Yêu cầu chức năng

Các yêu cầu chức năng được nêu trong danh sách các chức năng sẽ được thực hiện trong một hệ thống. Các tiêu chí này liên quan đến "cái gì sẽ được tạo ra?" chứ không phải là "như thế nào" và "khi nào".

Các yêu cầu chức năng bắt đầu bằng cách mô tả chức năng được yêu cầu dựa trên mức độ cần thiết của nó đối với ứng dụng. Nếu bạn muốn làm việc trên nó trước tiên, bạn có thể bắt đầu với thiết kế, nhưng sau đó bạn nên bắt đầu phát triển. Các yêu cầu chức năng không đi sâu vào chi tiết về các ngăn xếp công nghệ vì chúng có thể thay đổi khi dự án tiến triển. Thay vì tập trung vào logic bên trong, các yêu cầu chức năng tập trung vào chức năng của người dùng cuối.

3.2 Yêu cầu về giao diện bên ngoài

Yêu cầu chức năng là một phần quan trọng của đặc tả yêu cầu hệ thống. Để bao gồm tất cả các tính năng cần thiết của hệ thống, bạn sẽ cần 4-5 trang thông tin. Một số nhóm chia nhỏ chúng theo chủ đề để làm cho tài liệu dễ đọc hơn.

Thông thường, các thành phần thiết kế SRS được coi là tách biệt với phần phụ trợ và logic nghiệp vụ. Điều này có ý nghĩa vì các nhà thiết kế thay vì các nhà phát triển xử lý phần lớn lĩnh vực này, mà còn bởi vì nó là nơi bắt đầu quá trình phát triển sản phẩm.

Tùy thuộc vào dự án, các yêu cầu về giao diện bên ngoài có thể bao gồm bốn loại:

• Giao diện người dùng
• Giao diện phần mềm
• Giao diện phần cứng
• Giao diện truyền thông

Các yêu cầu về giao diện bên ngoài mô tả các phần tử trang sẽ hiển thị cho khách hàng cuối. Chúng có thể bao gồm danh sách các trang, yếu tố thiết kế, chủ đề phong cách chính, thậm chí cả yếu tố nghệ thuật, v.v. nếu chúng cần thiết cho sản phẩm.

3.3 Yêu cầu hệ thống

Yêu cầu hệ thống của sản phẩm nêu rõ các điều kiện mà sản phẩm có thể được sử dụng. Chúng thường liên quan đến các thông số kỹ thuật và tính năng phần cứng. Yêu cầu phần cứng SRS thường được xác định theo phạm vi tối thiểu và tối đa, cũng như ngưỡng hiệu suất sản phẩm tối ưu.

Việc tạo ra các yêu cầu hệ thống trước khi bắt đầu tạo ra một sản phẩm có vẻ khó khăn, nhưng nó là điều cần thiết. Các nhà phát triển phải tuân thủ các yêu cầu phần cứng để họ không phải khởi động lại dự án sau này. Các ứng dụng dành cho thiết bị di động (có nhiều biến số cần xem xét) và các ứng dụng cần khả năng phản hồi cao (trò chơi, bất kỳ sản phẩm nào có VR / AR hoặc IoT) đặc biệt dễ bị tấn công.

3.4 Yêu cầu phi chức năng

Đối với nhiều tổ chức, phần này của SRS là phần khó nhất. Nếu các yêu cầu chức năng giải quyết câu hỏi tạo ra cái gì, thì các tiêu chuẩn phi chức năng xác định cách thức. Họ thiết lập các tiêu chí theo mức độ hiệu quả của hệ thống phải hoạt động. Tất cả các ngưỡng về hiệu suất, bảo mật và khả năng sử dụng đều được bao gồm trong lĩnh vực này.

Giá trị thực là điều khiến khó xác định các yêu cầu phi chức năng. Khó xác định các cụm từ như “đồng thời” hoặc “tính di động” vì chúng có thể có nhiều cách hiểu khác nhau cho tất cả các bên liên quan. Do đó, chúng tôi chủ trương cho điểm mỗi yêu cầu phi chức năng. Bạn có thể truy cập lại các yêu cầu dự án của mình bất kỳ lúc nào để xem liệu hệ thống hiện tại có đáp ứng các kỳ vọng ban đầu hay không.

Yêu cầu thăm quan Nền tảng ALM:

Visure là một trong những nền tảng quản lý vòng đời ứng dụng đáng tin cậy nhất chuyên về Quản lý yêu cầu cho các tổ chức thuộc mọi quy mô trên toàn cầu. Các đối tác chính của Visure bao gồm các công ty quan trọng về kinh doanh và quan trọng về an toàn. Công ty tích hợp thông qua toàn bộ quy trình Quản lý vòng đời ứng dụng bao gồm quản lý rủi ro, theo dõi vấn đề và lỗi, quản lý truy xuất nguồn gốc, quản lý thay đổi và nhiều lĩnh vực khác như phân tích chất lượng, lập phiên bản yêu cầu và báo cáo mạnh mẽ.

Nếu bạn đang tìm kiếm một công cụ quản lý yêu cầu sẽ giúp bạn với cả yêu cầu chức năng và phi chức năng, hãy xem Yêu cầu về lượt truy cập. Với nền tảng này, bạn có thể dễ dàng tạo, quản lý và theo dõi tất cả các yêu cầu của dự án ở một nơi.

Kết luận:

Đặc tả yêu cầu là một tài liệu phác thảo các nhu cầu cụ thể của một dự án hoặc hệ thống. Đặc tả yêu cầu rất quan trọng vì nó đóng vai trò là nền tảng cho tất cả các công việc sau này của dự án. Đặc tả yêu cầu phần mềm (SRS) khác với đặc tả yêu cầu kinh doanh (BRS), mặc dù chúng có liên quan với nhau. SRS tập trung vào những gì hệ thống phải làm, trong khi BRS tập trung vào lý do tại sao hệ thống cần thiết và nó sẽ được sử dụng như thế nào. Cấu trúc của tài liệu yêu cầu phần mềm có thể khác nhau, nhưng phải luôn bao gồm các phần về mục đích, phạm vi, chức năng, tính năng, ràng buộc, giả định và phụ thuộc. Yêu cầu thăm quan Nền tảng ALM giúp bạn tạo và quản lý SRS của mình một cách dễ dàng. Yêu cầu bản dùng thử miễn phí 30 ngày tại Nền tảng ALM Yêu cầu truy cập để xem cách công cụ của chúng tôi có thể giúp các dự án của bạn chạy trơn tru hơn.