Giải pháp thăm quan


HỖ TRỢ
Đăng ký
Đăng nhập
Bắt đầu dùng thử miễn phí

Mục lục

Một trong những phần quan trọng nhất của bất kỳ dự án phát triển phần mềm nào là tạo ra các yêu cầu chi tiết, chính xác. Nếu không hiểu rõ những gì cần phải xây dựng, thì không thể tạo ra một sản phẩm cuối cùng chất lượng cao. Thật không may, viết ra những yêu cầu tốt thường nói dễ hơn làm. Lý do chính mà mọi người viết yêu cầu kém là họ không được đào tạo hoặc không có kinh nghiệm để viết yêu cầu tốt. Nếu bạn hoặc nhân viên của bạn gặp vấn đề với việc viết các yêu cầu tốt, bạn có thể được hưởng lợi từ hướng dẫn về cách viết các yêu cầu tốt. Bằng cách dành thời gian để tìm hiểu cách viết các yêu cầu tốt hơn, bạn có thể cải thiện chất lượng tổng thể của các dự án phát triển phần mềm của mình - và giúp bản thân đỡ phải đau đầu.

Tại sao Dự án Kỹ thuật Hệ thống không thành công?

Tại sao các dự án trong các ngành được quản lý chặt chẽ lại thất bại? Nhiều nhà nghiên cứu đã tìm hiểu lý do tại sao các hệ thống và dự án phần mềm thất bại. Nhóm Standish đã tiến hành nghiên cứu vào năm 2009, trong đó nhấn mạnh rằng hầu hết các lý do khiến các dự án thất bại đều liên quan đến các yêu cầu.

Phân tích chất lượng dự án

Đó là một trong những lý do chính tại sao việc viết các yêu cầu tốt là rất quan trọng cho sự thành công của dự án. Ngoài ra, việc viết ra các yêu cầu tốt mang lại nhiều lợi ích khác cho các nhóm.

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

Đặc tả yêu cầu là một quá trình trong đó các yêu cầu được xác định, lập thành văn bản và phân tích. Đó là một phần quan trọng của phát triển phần mềm vì nó đảm bảo rằng tất cả các bên liên quan đồng ý về chức năng của phần mềm trước khi bắt đầu phát triển. Bằng cách làm này, giảm khả năng hiểu nhầm và phải làm lại sau này.

Đặ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 hoặc viết 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.

Yêu cầu kỹ thuật

Quy trình kỹ thuật yêu cầu

Kỹ thuật yêu cầu

Có một số hoạt động mà chúng tôi phải đối mặt khi làm việc với các yêu cầu. Trong chu trình Kỹ thuật Yêu cầu, có năm hoạt động chính, đó là,

  1. Yêu cầu khơi gợi - Đây là quá trình thu thập, xem xét và tìm hiểu nhu cầu và ràng buộc của các bên liên quan và người sử dụng đối với mùa vụ. Người dùng cần thông tin miền, thông tin hệ thống hiện có, quy định, tiêu chuẩn, v.v. Dựa trên thông tin này, chúng tôi đưa ra các yêu cầu. Sau đó, chúng tôi chuyển sang phân tích yêu cầu và thương lượng. 
  2. Phân tích yêu cầu và thương lượng - Phân tích là quá trình tinh chỉnh các nhu cầu và ràng buộc của người sử dụng trên cơ sở thông tin thu thập và gợi ra. Sau đó, chúng tôi chuyển sang hoạt động tài liệu. 
  3. Yêu cầu Tài liệu / Đặc điểm kỹ thuật - Sau khi có thông số kỹ thuật yêu cầu, chúng ta chuyển sang phần tài liệu. Chúng tôi ghi lại các nhu cầu và ràng buộc của người dùng một cách rõ ràng và chính xác. 
  4. Xác thực yêu cầu - Cuối cùng, trong hoạt động xác nhận, chúng tôi chèn rằng các yêu cầu của mùa phải đầy đủ, ngắn gọn và rõ ràng. 
  5. Quản lý yêu cầu - Quản lý yêu cầu là một cách thu thập, phân tích, tinh chỉnh và ưu tiên tất cả các sản phẩm hoặc yêu cầu trong giai đoạn phát triển. Trong giai đoạn này, khả năng xác định nguồn gốc vững chắc giữa các yêu cầu và nguồn thông tin cũng được thiết lập. 

Khi chúng tôi hoàn thành năm hoạt động này, chúng tôi lặp đi lặp lại chúng cho đến khi chúng tôi nhận được một bộ tài liệu yêu cầu đã đồng ý là các thông số kỹ thuật chính thức.

Tại sao việc viết các yêu cầu tốt lại quan trọng?

Có rất nhiều lợi ích của việc có các thông số kỹ thuật yêu cầu tốt. 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.

Chúng ta đạt được những gì bằng cách viết ra những yêu cầu tuyệt vời?

Có rất nhiều điều yêu cầu tuyệt vời giúp đạt được. Một số trong số họ được liệt kê dưới đây:

  • Các yêu cầu lớn giúp đảm bảo rằng hệ thống đang được phát triển đáp ứng nhu cầu của người dùng.
  • Chúng là cơ sở để kiểm tra hệ thống để đảm bảo rằng nó hoạt động như mong đợi.
  • Chúng giúp giảm chi phí và thời gian phát triển tổng thể bằng cách tránh làm lại do những thay đổi trong yêu cầu.
  • Các yêu cầu lớn giúp cho quá trình phát triển trở nên hiệu quả và hiệu quả hơn.

Những thách thức khi viết yêu cầu

Có những thách thức khác nhau mà mọi người phải đối mặt khi viết các yêu cầu.

Yêu cầu Viết

Thủ tục giấy tờ kém - Trong một số tổ chức, tài liệu về các quá trình không tồn tại hoặc không đạt tiêu chuẩn. Trong trường hợp này, việc thu thập các yêu cầu trở thành một quy trình gồm hai bước: đầu tiên thiết kế ngược lại quy trình hiện có, sau đó xác định các khu vực cần cải tiến và tối ưu hóa. Để xác nhận rằng các yêu cầu được bổ sung và chính xác, điều quan trọng là xác định các bên liên quan chính và các chuyên gia về chủ đề, tham gia trực tiếp với họ. Vẽ bản đồ quy trình kinh doanh và hình dung quy trình làm việc là hai cách tuyệt vời để làm điều đó. Điều này giúp loại bỏ các giả định không chính xác đồng thời cung cấp một bức tranh hoàn chỉnh. Vẽ bản đồ quy trình và hiển thị quy trình là hai cách tiếp cận hữu ích cho mục đích này.

Yêu cầu mâu thuẫn - Khi các bên liên quan có những ưu tiên khác nhau cho các mục tiêu kinh doanh của họ, điều này dẫn đến các yêu cầu mâu thuẫn với nhau. Trong những trường hợp như vậy, trách nhiệm của một nhà phân tích kinh doanh là ghi lại tất cả các yêu cầu một cách chi tiết, xác định những yêu cầu nào chống lại nhau và cho phép các bên liên quan có cơ hội quyết định điều gì cần ưu tiên.

Bạn không thể đưa ra quyết định mà không cần lắng nghe ý kiến ​​đóng góp của các bên liên quan và với tư cách là một nhà phân tích kinh doanh, bạn có thể có một số ý tưởng về những gì nên được ưu tiên. Điều quan trọng vẫn là lắng nghe quan điểm của các bên liên quan. Thiết lập một cuộc thăm dò có thể là một trong những phương pháp để có được sự rõ ràng về những gì quan trọng nhất đối với đa số các bên liên quan.

Không có sẵn thông tin đầu vào của người dùng - Một số lý do có thể góp phần làm cho người dùng cuối không có sẵn và mỗi lý do yêu cầu cách giải quyết riêng. Ví dụ: đôi khi người dùng cuối quá bận tâm với công việc hàng ngày của họ đến mức họ không muốn tham gia vào các hoạt động thu thập yêu cầu.

Trong những trường hợp như vậy, điều tốt nhất mà một nhà phân tích kinh doanh có thể làm là hạn chế số lượng và độ dài của các cam kết. Trước cuộc họp, nghiên cứu càng nhiều càng tốt sẽ giúp cuộc thảo luận có tổ chức và nhiều thông tin hơn. Nó gần giống như biến việc thu thập các yêu cầu thành các phiên xác thực yêu cầu. xác định nhóm trọng tâm và xác định người dùng cuối phù hợp nhất cho mỗi nhóm

Tập trung vào giao diện thay vì trải nghiệm - Nhiều bên liên quan và người dùng cuối có tầm nhìn rõ ràng về cách giải pháp mới sẽ xuất hiện, nhưng họ không biết nó sẽ đạt được những gì. Giao diện người dùng của bất kỳ hệ thống nào là rất quan trọng, nhưng nó không nên xác định hoặc can thiệp vào chức năng.

Các nhà phân tích kinh doanh nên luôn nhớ giữ riêng các yêu cầu về thiết kế và chức năng trong tài liệu của họ. Bằng cách sử dụng các công cụ tổng quát hơn như sơ đồ, câu chuyện người dùng hoặc các nguyên mẫu có độ phân giải thấp hơn là bản nháp thiết kế, họ có thể duy trì sự tập trung vào các khía cạnh chức năng của việc thu thập yêu cầu.

Đầu vào của các bên liên quan - Khi các bên liên quan hoặc người dùng cuối cố gắng nói cho các nhà thiết kế biết hệ thống nên hoạt động như thế nào thay vì hệ thống phải làm gì, điều đó có thể dẫn đến các thiết kế không tối ưu. Để bắt đầu điều này, hãy xác thực từng 'yêu cầu sai' bằng cách hỏi 'tại sao?' cho đến khi bạn đi đến vấn đề thực sự cần giải quyết.

Vấn đề truyền thông - Trong số các vấn đề có thể dẫn đến thông tin sai lệch giữa nhà phân tích kinh doanh và các bên khác là rào cản ngôn ngữ, giả định sai, từ vựng được giải thích không đầy đủ và sử dụng quá nhiều thuật ngữ kỹ thuật.

Cách tiếp cận lý tưởng để tránh vấn đề này là tương tác thường xuyên và phát triển các cuộc trò chuyện hai chiều. Ghi lại các nhu cầu mà bạn đã phát hiện ra và gửi chúng để xem xét và phê bình ngang hàng cho nhiều chuyên gia về chủ đề khác nhau, tạo bảng chú giải thuật ngữ và kiểm tra kỹ các tiền đề.

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 Easy Atiếp cận Rphương trình Syntax, của Alastair Marvin. 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ướ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 các câu ngắ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 thành phần thiết yếu của một tài liệu yêu cầu:

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 - Tất cả các hạn chế đặt ra đối với thiết kế hệ thống theo quan điểm của khách hàng được mô tả trong phần này. 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 điểm của Tài liệu Đặc tả Yêu cầu Phần mềm:

Phần mềm Yêu cầu kỹ thuật
  • Trong sáng - Yêu cầu viết phải rõ ràng, dễ đọc, dễ hiểu. Ghi rõ thông tin bằng cách sử dụng các câu khẳng định sẽ được trao đổi giữa các diễn viên. Mọi yêu cầu đều phải mô tả các tiêu chí thành công rõ ràng. Cố gắng sử dụng từ vựng đơn giản và tránh viết tắt. Ví dụ: “Người dùng sẽ có thể xem Báo cáo Nhật ký Đánh giá”.
  • Nguyên tử - Mỗi yêu cầu nên được coi như một trường hợp kiểm thử rời rạc. Không nên sử dụng các liên từ như và, hoặc, v.v. vì chúng có thể dẫn đến việc bỏ sót các yêu cầu. Điều này đặc biệt quan trọng vì các điều khoản như thế này có thể khiến các nhà phát triển phần mềm và người kiểm tra bỏ qua các yêu cầu. Chia các nhu cầu phức tạp thành các phần nhỏ hơn cho đến khi từng phần có thể được kiểm tra riêng biệt là một cách để ngăn điều này xảy ra.
  • Rõ ràng - Yêu cầu không rõ ràng, không đầy đủ hoặc mâu thuẫn có thể dẫn đến sai sót và phải làm lại. Để ngăn chặn điều này xảy ra, các yêu cầu phải được xem xét bởi mọi bên liên quan trước khi chúng được hoàn thiện. Điều này sẽ giúp xác định sớm bất kỳ khoảng trống nào mà sau đó có thể được giải quyết.
  • 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.
  • Cần thiết - Mỗi yêu cầu phải ghi lại một cái gì đó mà người dùng thực sự cần hoặc một cái gì đó được yêu cầu để đáp ứng một tiêu chuẩn hoặc nhu cầu tích hợp do sự tồn tại của một giao diện bên ngoài. Ngoài ra, điều quan trọng đối với mỗi yêu cầu là phải có một nguồn được ủy quyền.
  • Thiết kế độc lập - Mỗi yêu cầu phải xác định những gì là cần thiết, không phải nó sẽ được thực hiện như thế nào. Các yêu cầu phải xác định các đặc tính của hệ thống sẽ được quan sát bên ngoài, không phải các chi tiết bên trong.
  • Khả thi - Mỗi yêu cầu phải được thực thi về mặt kỹ thuật và cần được thực hiện có tính đến ngân sách, thời hạn và các hạn chế khác ảnh hưởng đến dự án. 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.
  • Hoàn thành - Tài liệu yêu cầu 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.
  • 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. Do đó, để viết đúng yêu cầu, chúng ta phải có được thông tin chính xác và ghi lại chính xác thông tin được thu thập.

Quy tắc cho một tập hợp các yêu cầu chính xác

Có một số quy tắc nhất định mà các yêu cầu phải tuân thủ để được gọi là "Đúng".

  • Hoàn thành - Tài liệu yêu cầu 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.
  • Tính nhất quán - Duy trì mức độ chi tiết nhất quán. Ví dụ: đối với các yêu cầu của người dùng, người dùng cuối phải là chủ thể của mọi câu. Tương tự, đối với các yêu cầu về hệ thống, hệ thống phải là chủ đề của mọi câu.
  • Khả năng sửa đổi - Các yêu cầu có thể thay đổi trong suốt vòng đời của dự án. Nhật ký yêu cầu phải được lưu trữ và có thể phân tích tác động của những thay đổi được thực hiện đối với các yêu cầu khác và các yếu tố của dự án.
  • Ưu tiên - Các yêu cầu phải được phân loại trên quan điểm tầm quan trọng. Không phải tất cả các đặc tính mong muốn cho một hệ thống đều quan trọng như nhau. Vì vậy, sẽ rất hữu ích nếu thiết lập một quy tắc để xác định các ưu tiên yêu cầu ở cấp độ tổ chức và điều chỉnh nó cho phù hợp với từng dự án. Và làm việc với người dùng để họ có thể ưu tiên các yêu cầu.

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 quản lý các 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ẽ.  

Các khóa học về công cụ của Visure

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

Để tạo ra một phần mềm tuyệt vời, điều quan trọng là phải có một bản đặc tả yêu cầu được viết tốt. Tài liệu này phác thảo các nhu cầu của khách hàng và hệ thống phải làm gì để đáp ứng kỳ vọng của họ. Tuy nhiên, viết các yêu cầu tốt có thể là một thách thức. Có nhiều tiêu chuẩn và hướng dẫn phải tuân theo, và có nhiều cách viết khác nhau tùy thuộc vào ngôn ngữ và công cụ bạn sử dụng. Yêu cầu thăm quan Nền tảng ALM cung cấp một khóa học dạy bạn cách viết thông số kỹ thuật yêu cầu hiệu quả bằng cách sử dụng các phương pháp hay nhất và tiêu chuẩn ngành. Khóa học bao gồm tất cả các thành phần thiết yếu của một tài liệu yêu cầu, từ cấu trúc đến định dạng, cũng như cách sử dụng các ngôn ngữ khác nhau cho các yêu cầu viết. Nó cũng nêu bật các đặc điểm của các yêu cầu lớn để bạn có thể tạo ra các tài liệu mà nhóm của bạn sẽ thích làm việc. Nếu bạn muốn tìm hiểu thêm về cách viết các yêu cầu hiệu quả, hãy thử Đặc điểm kỹ thuật yêu cầu khóa học theo Yêu cầu thăm quan Nền tảng ALM ngay hôm nay!

Đừng quên chia sẻ bài viết này!

Phần mềm IBM Rational Doors
Áo sơ mi