Giải pháp thăm quan


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

Triển khai AI, Công nghệ & Phương pháp hay nhất để viết các yêu cầu về an toàn cho các ngành công nghiệp quan trọng của Jordan Kyriakidis

Podcast 11 Tháng một, 2023 10 giờ sáng giờ chuẩn Thái Bình Dương

Mục lục

Giới thiệu

Các yêu cầu viết đã đặt ra một thách thức đáng kể trong nhiều thập kỷ nay, và một trong những lý do chính cho điều này là ngôn ngữ được sử dụng để thể hiện chúng. Điều cần thiết là viết các yêu cầu theo cách vừa toàn diện vừa dễ hiểu, đặc biệt khi người đọc là chủ doanh nghiệp, người dùng cuối hoặc các bên liên quan. Điều này có nghĩa là sử dụng ngôn ngữ “tự nhiên” không có biệt ngữ kỹ thuật và thuật ngữ phức tạp. Tuy nhiên, ngôn ngữ tự nhiên vốn không chính xác và có thể dễ dàng bị hiểu sai hoặc hiểu sai, dẫn đến những phức tạp hơn nữa.

Thật không may, nhiều nhà phân tích chống lại bất kỳ loại cấu trúc nào trong việc viết yêu cầu của họ, thay vào đó họ thích dựa vào các đoạn văn mô tả và các câu có thể ngụ ý các yêu cầu bổ sung. Mặc dù cách tiếp cận này có thể hấp dẫn hơn đối với người đọc, nhưng nó thường dẫn đến sự nhầm lẫn và hiểu lầm khi các yêu cầu được chuyển giao cho nhà phát triển hoặc nhà phân tích hệ thống. Ngược lại, điều này có thể dẫn đến các cuộc thảo luận kéo dài và sự chậm trễ trong khi cố gắng làm rõ ý nghĩa thực sự của các yêu cầu.

Trong cuộc phỏng vấn với Visure Solutions, Jordan Kyriakidis, Người đồng sáng lập và Giám đốc điều hành đáng kính của QRA Corp, đã chia sẻ những hiểu biết của mình về các khía cạnh khác nhau của kỹ thuật yêu cầu. Trong cuộc phỏng vấn này, chúng tôi đã thảo luận về một số chủ đề khá thú vị bao gồm

  • Các yếu tố thiết yếu của yêu cầu lớn
  • Easy Aphương pháp cho Rphương trình SCách tiếp cận cú pháp
  • AI đạt được lực kéo trong số hóa kỹ thuật yêu cầu
  • Mẹo và thủ thuật để viết yêu cầu tuyệt vời
  • Và nhiều hơn nữa!

Jordan Kyriakidis là ai?

Jordan Kyriakidis là nhà lãnh đạo nổi tiếng trong lĩnh vực thiết kế và xác minh các hệ thống quan trọng về an toàn. Ông là Đồng sáng lập và Giám đốc điều hành của QRA Corp, một công ty cung cấp các giải pháp tiên tiến cho các công ty và chính phủ để xác định và giảm thiểu rủi ro trong các dự án phức tạp liên quan đến công nghệ mới trong các ngành được quản lý. Với gần hai thập kỷ kinh nghiệm lãnh đạo các nhóm hiệu suất cao, Jordan là một nhà khoa học tài ba với nhiều ấn phẩm quốc tế được ghi nhận.

Jordan có bằng tiến sĩ. về Lý thuyết lượng tử từ Đại học Basel, Thụy Sĩ, đồng thời đã sống và làm việc ở nhiều quốc gia khác nhau trên toàn cầu, bao gồm Châu Âu, Hoa Kỳ và Canada. Chuyên môn của anh ấy về kỹ thuật yêu cầu, cùng với niềm đam mê thúc đẩy lĩnh vực này, đã khiến anh ấy trở thành một diễn giả được săn đón và là nhà lãnh đạo tư tưởng trong ngành. Jordan được biết đến với cách tiếp cận có tầm nhìn xa trong việc tận dụng AI và các phương pháp hay nhất để viết yêu cầu trong các ngành quan trọng, đồng thời, ông đã có công trong việc số hóa kỹ thuật yêu cầu.

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

Đặc tả yêu cầu là quá trình xác định rõ ràng và ghi lại các yêu cầu chức năng và phi chức năng của một hệ thống, ứng dụng phần mềm hoặc sản phẩm. Mục đích của đặc tả yêu cầu là nắm bắt nhu cầu và mong đợi của các bên liên quan, bao gồm khách hàng, người dùng cuối và các bên quan tâm khác, một cách rõ ràng và ngắn gọn. Tài liệu này được sử dụng làm kế hoạch chi tiết cho việc thiết kế, phát triển, thử nghiệm và triển khai hệ thống hoặc sản phẩm. 

Đặc tả yêu cầu thường bao gồm mô tả về chức năng, hiệu suất, khả năng sử dụng, độ tin cậy, bảo mật và các đặc điểm quan trọng khác của hệ thống hoặc sản phẩm. Nó cũng có thể bao gồm bất kỳ ràng buộc, giả định hoặc phụ thuộc nào có thể ảnh hưởng đến thiết kế hoặc triển khai hệ thống hoặc sản phẩm. Đặc tả yêu cầu là một thành phần thiết yếu của vòng đời phát triển phần mềm và đóng vai trò là nền tảng để giao tiếp và cộng tác hiệu quả giữa các bên liên quan của dự án.

Tầm quan trọng của việc viết các yêu cầu lớn

Viết các yêu cầu tuyệt vời là rất quan trọng cho sự thành công của bất kỳ dự án phát triển phần mềm nào. Dưới đây là một số lý do tại sao:

  1. Giao tiếp rõ ràng: Các yêu cầu được viết tốt giúp đảm bảo rằng tất cả các bên liên quan của dự án đều có sự hiểu biết rõ ràng và chia sẻ về những gì được mong đợi từ hệ thống hoặc sản phẩm đang được phát triển. Sự rõ ràng này đảm bảo rằng mọi người đều thống nhất với nhau, giảm nguy cơ hiểu lầm và thông tin sai lệch có thể dẫn đến sai sót, làm lại và trì hoãn dự án.
  2. Tập trung vào nhu cầu của người dùng: Yêu cầu tuyệt vời tập trung vào nhu cầu của người dùng cuối và khách hàng, đảm bảo rằng hệ thống hoặc sản phẩm đang được phát triển đáp ứng mong đợi và yêu cầu của họ. Cách tiếp cận này làm tăng sự hài lòng của khách hàng và giảm rủi ro thất bại của dự án do sự không phù hợp giữa sản phẩm và nhu cầu của người dùng.
  3. Quản lý rủi ro: Các yêu cầu có thể sớm xác định các rủi ro và vấn đề tiềm ẩn trong quá trình phát triển, cho phép đưa ra các chiến lược giảm thiểu chủ động. Bằng cách xác định sớm các vấn đề tiềm ẩn, các nhóm có thể tránh được việc làm lại tốn kém, chậm trễ và hỏng hóc sau này.
  4. Hiệu suất: Các yêu cầu tuyệt vời giúp hợp lý hóa quy trình phát triển bằng cách cung cấp một lộ trình rõ ràng để các nhà phát triển tuân theo. Lộ trình này đảm bảo rằng các nhà phát triển đang làm việc trên các tính năng và yêu cầu quan trọng nhất, tránh lãng phí công sức cho các nhiệm vụ ít quan trọng hơn.
  5. Đảm bảo chất lượng: Bằng cách xác định rõ các yêu cầu, việc đảm bảo rằng hệ thống hoặc sản phẩm đang được phát triển đáp ứng các tiêu chuẩn chất lượng được yêu cầu sẽ dễ dàng hơn. Các yêu cầu lớn giúp việc kiểm tra, xác thực và xác minh hệ thống hoặc sản phẩm đang được phát triển trở nên dễ dàng hơn, đảm bảo rằng nó được phân phối đúng thời hạn, đúng ngân sách và ở mức chất lượng mong đợi.

Đặc điểm của yêu cầu lớn

Các yêu cầu lớn là điều cần thiết để cung cấp các dự án phát triển phần mềm thành công đáp ứng mong đợi của khách hàng, được giao đúng hạn và nằm trong ngân sách. Dưới đây là một số đặc điểm của yêu cầu lớn:

  1. Rõ ràng và ngắn gọn: Yêu cầu tuyệt vời là dễ hiểu, với ngôn ngữ rõ ràng và ngắn gọn, tránh mơ hồ hoặc nhầm lẫn.
  2. Hoàn thành: Các yêu cầu lớn phải nắm bắt được tất cả các khía cạnh chức năng và phi chức năng cần thiết của hệ thống hoặc sản phẩm đang được phát triển, không có chỗ cho sự diễn giải hoặc hiểu lầm.
  3. Chính xác: Các yêu cầu tuyệt vời phải chính xác và có thể kiểm chứng, không có sự khác biệt giữa những gì được viết và những gì hệ thống hoặc sản phẩm dự kiến ​​sẽ thực hiện.
  4. Có thể kiểm tra: Các yêu cầu lớn phải có thể kiểm tra được, nghĩa là có thể tạo các thử nghiệm có thể xác minh rằng hệ thống hoặc sản phẩm đáp ứng các yêu cầu.
  5. ưu tiên: Các yêu cầu lớn nên được ưu tiên để đảm bảo rằng các tính năng và chức năng quan trọng nhất được phát triển trước tiên.
  6. Khả thi: Các yêu cầu lớn phải khả thi, nghĩa là chúng có thể đạt được về mặt kỹ thuật và thực tế trong thời gian và ngân sách hạn chế nhất định.
  7. Có thể theo dõi: Các yêu cầu lớn phải được theo dõi, nghĩa là có một liên kết rõ ràng giữa từng yêu cầu và nguồn của nó, bao gồm cả bên liên quan đã yêu cầu nó.
  8. Thích hợp: Các yêu cầu tuyệt vời phải nhất quán với các tài liệu dự án khác, bao gồm kế hoạch dự án, tuyên bố phạm vi và các tài liệu liên quan khác.
  9. rõ ràng: Các yêu cầu lớn không được mơ hồ hoặc nhầm lẫn, đảm bảo rằng có sự hiểu biết rõ ràng về những gì được mong đợi từ hệ thống hoặc sản phẩm đang được phát triể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.

Thủ tục giấy tờ kém – Trong một số tổ chức, tài liệu về các quy 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 là thiết kế ngược quy trình hiện có và sau đó xác định các khu vực cần cải thiệ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ủ đề, tương tác trực tiếp với họ. Vẽ bản đồ quy trình kinh doanh và trực quan hóa quy trình công việc là hai cách tuyệt vời để làm điều đó. Điều này hỗ trợ trong việc 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ó các ư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 xung đột với nhau. Trong những trường hợp như vậy, trách nhiệm của nhà phân tích nghiệp vụ là ghi lại chi tiết tất cả các yêu cầu, xác định những yêu cầu nào trái ngược nhau và cho phép các bên liên quan có cơ hội quyết định điều gì được ư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ó đầu vào của người dùng – Một số lý do có thể góp phần vào việc không có sẵn người dùng cuối và mỗi lý do đều yêu cầu giải pháp riêng. Chẳng hạn, đôi khi người dùng cuối quá bận rộn với công việc hàng ngày của họ đến nỗi 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 giải pháp đó sẽ đạt được những gì. Giao diện người dùng của bất kỳ hệ thống nào cũng 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 nên làm gì, điều đó có thể dẫn đến các thiết kế dưới mức tối ưu. Để giải quyết vấn đề này, hãy xác thực từng 'yêu cầu sai' tiềm ẩn 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 đề giao tiếp – Trong số các vấn đề có thể dẫn đến hiểu lầm giữa nhà phân tích nghiệp vụ 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 và gửi chúng để được đồng nghiệp đánh giá và phê bình 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ơ sở.

Những Sai Lầm Thường Gặp Khi Viết Yêu Cầu

Viết yêu cầu có thể là một nhiệm vụ đầy thách thức và có những lỗi phổ biến có thể mắc phải có thể ảnh hưởng đến sự thành công của dự án phát triển phần mềm. Dưới đây là một số lỗi phổ biến khi viết yêu cầu:

  1. Sự mơ hồ: Một trong những lỗi phổ biến nhất khi viết yêu cầu là sử dụng ngôn ngữ mơ hồ, có thể dẫn đến hiểu lầm và sai sót. Điều này có thể tránh được bằng cách sử dụng ngôn ngữ rõ ràng, ngắn gọn và rõ ràng.
  2. Yêu cầu không đầy đủ hoặc không nhất quán: Các yêu cầu không đầy đủ hoặc không nhất quán có thể dẫn đến nhầm lẫn và sai sót trong quá trình phát triển phần mềm. Điều này có thể tránh được bằng cách xem xét và xác nhận các yêu cầu để đảm bảo chúng đầy đủ và nhất quán với các tài liệu khác của dự án.
  3. Thiếu ưu tiên: Nếu không có sự ưu tiên thích hợp, các yêu cầu có thể được phát triển một cách ngẫu nhiên, dẫn đến sự chậm trễ và sản phẩm không đáp ứng mong đợi của khách hàng. Các yêu cầu ưu tiên có thể đảm bảo rằng các tính năng và chức năng quan trọng nhất được phát triển trước tiên.
  4. Yêu cầu không rõ ràng hoặc không thể kiểm chứng: Các yêu cầu không rõ ràng hoặc không thể kiểm chứng có thể dẫn đến hiểu lầm và khó xác thực rằng hệ thống hoặc sản phẩm đáp ứng các yêu cầu. Điều này có thể tránh được bằng cách đảm bảo rằng các yêu cầu rõ ràng và có thể kiểm chứng được.
  5. Mạ vàng: Mạ vàng xảy ra khi các tính năng hoặc chức năng bổ sung được thêm vào hệ thống hoặc sản phẩm không được chỉ định trong các yêu cầu. Điều này có thể dẫn đến sự chậm trễ, chi phí gia tăng và sản phẩm không đáp ứng được nhu cầu của khách hàng.
  6. Thiếu sự tham gia của các bên liên quan: Thiếu sự tham gia của các bên liên quan có thể dẫn đến các yêu cầu không đáp ứng nhu cầu của khách hàng và các bên liên quan khác. Thu hút các bên liên quan trong suốt quá trình phát triển phần mềm có thể đảm bảo rằng các yêu cầu phù hợp với nhu cầu và mong đợi của họ.
  7. Quá phụ thuộc vào công nghệ: Quá phụ thuộc vào công nghệ có thể dẫn đến các yêu cầu không phù hợp với khả năng của hệ thống hoặc sản phẩm đang được phát triển. Điều này có thể tránh được bằng cách đảm bảo rằng các yêu cầu là khả thi và phù hợp với công nghệ đang được sử dụng.
  8. Thiếu cân nhắc kiểm tra: Kiểm thử là một khía cạnh quan trọng của phát triển phần mềm và việc thiếu xem xét kiểm thử trong các yêu cầu có thể dẫn đến một sản phẩm khó kiểm thử hoặc không đáp ứng các tiêu chuẩn chất lượng.

Viết yêu cầu sử dụng phương pháp ngôn ngữ tự nhiên

Viết các yêu cầu bằng phương pháp ngôn ngữ tự nhiên liên quan đến việc sử dụng ngôn ngữ hàng ngày để truyền đạt các yêu cầu theo cách rõ ràng, ngắn gọn và dễ hiểu. Cách tiếp cận này thường được sử dụng trong phát triển phần mềm và các ngành công nghiệp khác, nơi có nhu cầu nắm bắt và ghi lại các yêu cầu mà tất cả các bên liên quan đều có thể hiểu được dễ dàng, bất kể chuyên môn kỹ thuật của họ.

Ngôn ngữ tự nhiên là ngôn ngữ mà chúng ta sử dụng trong giao tiếp hàng ngày, chẳng hạn như tiếng Anh, tiếng Pháp, tiếng Tây Ban Nha, v.v. Yêu cầu viết sử dụng ngôn ngữ tự nhiên liên quan đến việc sử dụng cùng một ngôn ngữ mà các bên liên quan sử dụng trong giao tiếp hàng ngày của họ, thay vì sử dụng thuật ngữ kỹ thuật hoặc ngôn ngữ chuyên ngành có thể không quen thuộc với các bên liên quan phi kỹ thuật.

Khi so sánh với các ngôn ngữ khác về yêu cầu viết, ngôn ngữ tự nhiên có lợi thế là dễ hiểu hơn đối với các bên liên quan phi kỹ thuật. Sử dụng ngôn ngữ tự nhiên có thể giúp đảm bảo rằng các yêu cầu được truyền đạt hiệu quả tới tất cả các bên liên quan, dẫn đến kết quả dự án thành công hơn. Ngược lại, các ngôn ngữ viết yêu cầu khác, chẳng hạn như ngôn ngữ đặc tả chính thức, có thể chính xác và rõ ràng hơn, nhưng chúng có thể khó hiểu hơn đối với các bên liên quan phi kỹ thuật.

Để viết yêu cầu bằng phương pháp ngôn ngữ tự nhiên, điều quan trọng là sử dụng ngôn ngữ đơn giản, hàng ngày, dễ hiểu. Các yêu cầu phải cụ thể, có thể đo lường và kiểm chứng được, đồng thời nên tránh sử dụng các thuật ngữ mơ hồ hoặc biệt ngữ kỹ thuật. Việc sử dụng các mẫu, ví dụ và hình ảnh cũng có thể giúp làm cho các yêu cầu trở nên rõ ràng và ngắn gọn hơn.

Mẫu TAI

Mẫu EARS (Cú pháp tiếp cận dễ dàng với yêu cầu) là mẫu tài liệu và thu thập yêu cầu cung cấp cách thức có cấu trúc để nắm bắt và lập tài liệu cho các yêu cầu. Nó thường được sử dụng trong các ngành như hàng không vũ trụ, quốc phòng và phát triển phần mềm, nơi có nhu cầu nắm bắt và ghi lại các yêu cầu phức tạp và thường là kỹ thuật. Mẫu EARS có thể được sử dụng cho cả yêu cầu chức năng và phi chức năng.

Mẫu EARS bao gồm bốn phần chính:

  1. môi trường: Phần này mô tả bối cảnh mà hệ thống sẽ hoạt động, bao gồm bất kỳ ràng buộc hoặc phụ thuộc nào phải được xem xét.
  2. Diễn viên: Phần này mô tả các loại người dùng hoặc hệ thống khác nhau sẽ tương tác với hệ thống, bao gồm vai trò và trách nhiệm của họ.
  3. Yêu cầu: Phần này mô tả các yêu cầu cụ thể đối với hệ thống, bao gồm cả yêu cầu chức năng và phi chức năng. Mỗi yêu cầu được xác định một cách rõ ràng và ngắn gọn bằng cách sử dụng cú pháp chuẩn hóa.
  4. Kích thích kinh tế: Phần này mô tả các đầu vào sẽ kích hoạt hệ thống thực hiện các hành động hoặc phản hồi nhất định và các đầu ra hoặc phản hồi dự kiến.

Để sử dụng mẫu EARS, trước tiên, nhà phân tích yêu cầu hoặc nhóm phải xác định môi trường mà hệ thống sẽ vận hành, bao gồm mọi ràng buộc hoặc phụ thuộc. Tiếp theo, họ nên xác định các tác nhân hoặc người dùng khác nhau sẽ tương tác với hệ thống cũng như vai trò và trách nhiệm của họ. Sau đó, họ nên xác định các yêu cầu cụ thể đối với hệ thống, sử dụng cú pháp tiêu chuẩn hóa được xác định trong mẫu. Cuối cùng, họ nên xác định các tác nhân kích thích sẽ kích hoạt hệ thống thực hiện các hành động hoặc phản hồi nhất định và các kết quả hoặc phản hồi mong đợi.

Mẫu EARS được thiết kế để cung cấp một cách rõ ràng và súc tích để ghi lại các yêu cầu, giúp việc hiểu và xác minh các yêu cầu trở nên dễ dàng hơn. Nó thường được sử dụng trong các ngành công nghiệp đòi hỏi yêu cầu tỉ mỉ và chính xác, chẳng hạn như hàng không vũ trụ, quốc phòng và phát triển phần mềm. Bằng cách sử dụng mẫu EARS, các nhà phân tích yêu cầu có thể đảm bảo rằng tất cả các yêu cầu liên quan đều được nắm bắt và ghi lại một cách nhất quán và có cấu trúc.

Nguyên tắc INCOSE – Mẫu

INCOSE, hay Hội đồng Quốc tế về Kỹ thuật Hệ thống, là một tổ chức thành viên phi lợi nhuận quốc tế cung cấp các tiêu chuẩn và hướng dẫn để giúp các tổ chức tạo ra các quy trình kỹ thuật hệ thống tốt hơn. Tiêu chuẩn yêu cầu hệ thống INCOSE (SRS) chứa một bộ quy tắc và tiêu chuẩn được thiết kế để giúp các tổ chức đánh giá các tuyên bố yêu cầu trước khi chúng được triển khai. SRS đã được một số tập đoàn lớn cũng như các cơ quan chính phủ trên khắp thế giới áp dụng và có thể được sử dụng trong nhiều ngành công nghiệp khác nhau cho các ứng dụng khác nhau. Điều quan trọng đối với các bên liên quan như nhà phát triển phần mềm, nhà phân tích kinh doanh, người quản lý dự án, người kiểm tra, nhân viên bộ phận CNTT và các thành viên khác trong nhóm là phải hiểu rõ về các yêu cầu này trước khi bắt đầu làm việc với bất kỳ tuyên bố hoặc dự án yêu cầu hệ thống nào.

Cuối cùng, viết các yêu cầu tốt liên quan đến sự cân bằng cẩn thận giữa chi tiết và ngắn gọn, cũng như đảm bảo rằng yêu cầu có thể kiểm tra và khả thi. INCOSE SRS đưa ra các nguyên tắc và hướng dẫn để các nhóm có thể viết các yêu cầu chất lượng tốt và giúp đảm bảo rằng các dự án của họ thành công. Điều này sẽ giúp tránh các lỗi tốn kém trong quá trình phát triển hoặc sau khi triển khai, từ đó giúp các tổ chức tạo ra các hệ thống tốt hơn trong một khoảng thời gian ngắn hơn.

Quy tắc INCOSE là gì?

Báo cáo yêu cầu được đánh giá thông qua các quy tắc của INCOSE. Các tiêu chuẩn này giúp tổ chức đánh giá tính khả thi và chất lượng của các yêu cầu trước khi chúng được thực hiện. Quá trình đánh giá bao gồm XNUMX tiêu chí chính:

  • Sạch - Yêu cầu văn bản phải rõ ràng, dễ đọc, dễ hiểu. Chỉ định rõ ràng 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 tác nhân. Mọi yêu cầ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ý kiểm tra”.
  • nguyên tử – Mỗi yêu cầu nên được coi là một trường hợp thử nghiệm riêng biệt. Các liên từ như and, or, v.v. không nên được sử dụng vì chúng có thể dẫn đến bỏ sót yêu cầu. Điều này đặc biệt quan trọng vì các thuật ngữ 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 mỗi phần có thể được kiểm tra riêng biệt là một cách để ngăn chặn điều này xảy ra.
  • rõ ràng – Các 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 điều này xảy ra, các yêu cầu phải được mọi bên liên quan xem xét 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ỳ lỗ hổng nào mà sau đó có thể được giải quyết.
  • có thể 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ần thiết. 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 đều 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 thứ gì đó mà người dùng thực sự cần hoặc thứ gì đó được yêu cầu để đáp ứng nhu cầu tiêu chuẩn hoặc tích hợp do sự tồn tại của giao diện bên ngoài. Ngoài ra, điều quan trọng là mỗi yêu cầu 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 chứ không phải cách nó sẽ được thực hiện. Các yêu cầu phải xác định các đặc điểm 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ể thực hiện được về mặt kỹ thuật và phải đượ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ệ. Họ 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 thử nghiệm của bạn hoàn thành 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 được chỉ định trong các tài liệu phải rất chính xác để tránh bất kỳ sự nhầm lẫn nào. Không được có sơ hở, mơ hồ, chủ quan, so sánh, 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.

Xu hướng tương lai: Viết yêu cầu với AI

Công nghệ Trí tuệ nhân tạo (AI) có khả năng cách mạng hóa cách viết và quản lý các yêu cầu trong quá trình phát triển sản phẩm. Trong những năm gần đây, đã có những tiến bộ đáng kể trong xử lý ngôn ngữ tự nhiên (NLP) và học máy (ML) giúp tự động hóa một số khía cạnh của kỹ thuật yêu cầu.

Một xu hướng tiềm năng trong tương lai là sử dụng các chatbot do AI cung cấp, chẳng hạn như ChatGPT và Jasper, để hỗ trợ viết các yêu cầu. Các chatbot này sử dụng thuật toán NLP để phân tích đầu vào từ các bên liên quan và tạo ra các yêu cầu chất lượng cao dựa trên đầu vào đó. Bằng cách tận dụng các công cụ này, các tổ chức có thể hợp lý hóa quy trình kỹ thuật yêu cầu, giảm thời gian và nỗ lực cần thiết để phát triển các yêu cầu, dẫn đến chu kỳ phát triển sản phẩm nhanh hơn và sử dụng tài nguyên hiệu quả hơn.

Một xu hướng tiềm năng khác là sử dụng AI để tự động xác định và trích xuất các yêu cầu từ nhiều nguồn dữ liệu phi cấu trúc khác nhau, chẳng hạn như phản hồi của khách hàng, bài đăng trên mạng xã hội và đánh giá sản phẩm. Bằng cách sử dụng các thuật toán NLP để tự động xác định và trích xuất các yêu cầu liên quan từ các nguồn này, các tổ chức có thể hiểu sâu hơn về nhu cầu và sở thích của khách hàng, dẫn đến kết quả phát triển sản phẩm thành công hơn.

Công nghệ AI cũng có thể giúp cải thiện chất lượng và tính nhất quán của các yêu cầu bằng cách xác định các xung đột tiềm ẩn, sự mơ hồ hoặc dư thừa trong các yêu cầu. Điều này có thể giúp giảm rủi ro sai sót và hiểu lầm, dẫn đến chất lượng sản phẩm tốt hơn và chu kỳ làm lại ít tốn kém hơn.

Mẹo cần thiết để viết yêu cầu

  1. Viết theo lớp – Viết các yêu cầu theo lớp có nghĩa là chia nhỏ các yêu cầu phức tạp thành các phần nhỏ hơn, dễ quản lý hơn. Điều này giúp làm cho các yêu cầu dễ hiểu hơn, toàn diện hơn và dễ thực hiện hơn.
  2. Cùng một lúc - Mỗi yêu cầu nên được coi là một trường hợp thử nghiệm riêng biệt. Các liên từ như and, or, v.v. không nên được sử dụng vì chúng có thể dẫn đến bỏ sót yêu cầu. Điều này đặc biệt quan trọng vì các thuật ngữ 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 mỗi phần có thể được kiểm tra riêng biệt là một cách để ngăn chặn điều này xảy ra.
  3. Nói “Cái gì” Không phải “Làm thế nào” – Nên tập trung vào những gì hệ thống sẽ làm chứ không phải cách nó thực hiện. Ngoài ra, tránh đi sâu vào các chủ đề thiết kế như tên trường, đối tượng ngôn ngữ lập trình và đối tượng phần mềm. Nếu bạn thấy mình đang thảo luận về các chủ đề này trong Tài liệu Đặc tả Yêu cầu, hãy lùi lại một bước – điều này có thể có nghĩa là bạn đang quá cụ thể.
  4. có thể kiểm chứng – Một điều khác cần lưu ý khi tổ chức các yêu cầu là chúng phải luôn có thể kiểm tra được. Điều này có nghĩa là cần phải có khả năng xác minh hệ thống đáp ứng yêu cầu được đề cập. Điều này cũng liên kết đến điểm tiếp theo của chúng tôi – truy xuất nguồn gốc. Nếu một yêu cầu chứa đầy các thuật ngữ mơ hồ, thì việc phân tích và xác minh xem hệ thống có thực sự đáp ứng các tiêu chuẩn này hay không sẽ trở nên khó khăn hơn. Do đó, càng nhiều càng tốt, hãy hướng tới sự rõ ràng và chính xác trong ngôn ngữ của bạn để việc thu thập Yêu cầu không phải là một quy trình mơ hồ.
  5. truy xuất nguồn gốc – Truy xuất nguồn gốc trong quản lý dự án đề cập đến việc đảm bảo rằng các yêu cầu được liên kết với các thành phần khác trong dự án. Điều này cho phép người quản lý dự án, nhà phát triển và các bên liên quan theo dõi toàn bộ vòng đời của yêu cầu từ đầu đến cuối theo mọi hướng cũng như với các phần khác của hệ thống. Nếu bạn quản lý truy xuất nguồn gốc đúng cách, bạn có thể tránh mã không tương ứng với bất kỳ yêu cầu nào (mã 'đi lạc') và đảm bảo rằng mọi trường hợp thử nghiệm đều đáp ứng ít nhất một yêu cầu. Bạn có thể làm cho các yêu cầu có thể theo dõi được bằng cách gắn nhãn cho chúng bằng mã định danh duy nhất và cung cấp thông tin về nguồn của chúng trong kho lưu trữ trung tâm mà tất cả các thành viên trong nhóm đều có thể truy cập được.
  6. 3 W – Các yêu cầu nên tập trung vào việc đáp ứng nhu cầu của người dùng chứ không phải giải pháp. Do đó, điều cần thiết là phải hiểu các yêu cầu và điểm yếu của người dùng trước khi phát triển các yêu cầu.
    1. Cái gì? – Chúng ta đang làm gì vậy?
    2. Ai? – Ai sẽ được lợi?
    3. Tại sao? – Tại sao chúng ta làm điều đó?
  7. 1 Yêu cầu cho 1 Nhiệm vụ – Mỗi yêu cầu nên nêu một hành động và mục tiêu duy nhất. Cẩn thận với việc sử dụng quá nhiều từ “and” và “or”. Ví dụ: “Nếu thứ Sáu cuối cùng của tháng và khoản thanh toán đến hạn vào ngày 31 và nếu ngày 31 là thứ Sáu cuối cùng của tháng, thì việc gửi khoản thanh toán vào ngày đó sau 6 giờ chiều theo giờ miền Đông sẽ dẫn đến việc thanh toán trễ ”. Tôi thách bạn hiểu điều đó!
  8. Ưu tiên các yêu cầu – Ưu tiên các yêu cầu dựa trên tầm quan trọng và tác động của chúng đối với sự thành công của dự án. Điều này giúp đảm bảo rằng các yêu cầu quan trọng nhất được thực hiện trước và nhu cầu của các bên liên quan được đáp ứng.
  9. Điều khoản không lối thoát – Ví dụ: “Hệ thống sẽ xác định số lần thử đăng nhập, trừ trường hợp người dùng rõ ràng đã nhập tên người dùng không chính xác”.

Theo Jordan, Điều gì phân biệt các dự án thành công với những dự án không thành công?

Theo Jordan Kyriakidis, điều làm nên sự khác biệt của các dự án thành công với những dự án không thành công là khả năng quản lý các yêu cầu một cách hiệu quả. Các dự án thành công có sự hiểu biết rõ ràng về các yêu cầu và có thể quản lý chúng trong toàn bộ quá trình phát triển, từ lập kế hoạch ban đầu đến phân phối cuối cùng. Mặt khác, các dự án không thành công thường gặp phải tình trạng quản lý yêu cầu kém, điều này có thể dẫn đến thông tin sai lệch, chậm trễ và cuối cùng là không đáp ứng được các mục tiêu của dự án. Do đó, điều quan trọng đối với các công ty là đầu tư vào các công cụ và thực hành kỹ thuật yêu cầu mạnh mẽ để đảm bảo thành công cho các dự án của họ.

Tìm hiểu thêm về Jordan Kyriakidis ở đâu?

Để tìm hiểu thêm về Jordan Kyriakidis và QRA Corp, bạn hãy xem trang LinkedIn của họ tại https://www.linkedin.com/company/qra-corp/. Ngoài ra, bạn có thể tìm thấy Jordan Kyriakidis trên LinkedIn tại https://www.linkedin.com/in/jordankyriakidis/. QRA Corp cũng có sẵn một số sách trắng và nghiên cứu điển hình trên trang web của họ để cung cấp thông tin chi tiết về công nghệ và ứng dụng của nó trong các ngành khác nhau.

Kết luận:

Tóm lại, Jordan Kyriakidis và Visure Solutions đã chia sẻ một cuộc trò chuyện sâu sắc về Yêu cầu viết. Chúng tôi đã khám phá tầm quan trọng của việc viết các yêu cầu tuyệt vời và đề cập đến những thách thức khi viết các yêu cầu cùng với các lỗi phổ biến. Chúng tôi đã xem xét các phương pháp khác nhau, chẳng hạn như phương pháp ngôn ngữ tự nhiên, mẫu EARS và hướng dẫn INCOSE. Công nghệ AI cũng đã mở ra nhiều khả năng viết yêu cầu, giúp những người mới bắt đầu học cách viết chúng dễ dàng hơn. Cuối cùng, chúng tôi cũng bao gồm các mẹo chính để giúp bạn trong suốt hành trình khi bạn bắt đầu cuộc hành trình này. Từ việc tìm hiểu về Quy tắc INCOSE đến Xu hướng Tương lai trong Yêu cầu Viết - có điều gì đó ở đây dành cho tất cả mọi người! Lấy đi những mẹo cần thiết này và áp dụng chúng vào thực tế ngay bây giờ! Kiểm tra các cuộc phỏng vấn đầy đủ ngay bây giờ!

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

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

Triển khai các phương pháp hay nhất về AI để tối ưu hóa các yêu cầu về hệ thống điện tử hàng không

Tháng Chín 12th, 2024

11 giờ sáng giờ EST | 5 giờ chiều CEST | 8 giờ sáng theo giờ Thái Bình Dương

Fernando Valera

Fernando Valera

CTO, Giải pháp Visure

Reza Madjidi

Reza Madjidi

Giám đốc điều hành ConsuNova Inc.

Phương pháp tiếp cận tích hợp với Visure Solutions và ConsuNova Inc.

Tìm hiểu cách AI giúp tối ưu hóa các yêu cầu về hệ thống điện tử hàng không để cất cánh và hạ cánh an toàn