thuật ngữ thường dùng
– cia: confidentiality, integrity and availability (Độ tin cậy, tính toàn vẹn, tính khả dụng ) – uml: unified modeling language (ngôn ngữ mô hình hóa) – sysml: systems modeling language (ngôn ngữ mô hình hóa hệ thống)
1.1. kiến thức cơ bản
tong quan
Định nghĩa
- Yêu cầu cho 1 phần mềm cụ thể là tổng hợp những yêu cầu từ nhiều người khác nhau về tổ chức, mức ộ chuyên môn và mức ộ Tham gia No.
- có thể kiểm chứng một cách riêng rẽ ở mức chức năng (yêu cầu chức năng) hoặc mức hệ thống (yêu cầu phi chức năng).
- cung cấp các chỉ số đánh giá độ ưu tiên về các mặt khi cân nhắc về nguồn tài nguyên.
- cung cấp các giá trị trạng thái để theo dõi tiến độ của dự án.
- yêu cầu tiến trình : là những ràng buộc liên quan ến việc phát triển phần mềm đó (quy trình, ối tác kiểm thửn, … phych, dửsử sử).
-
theo chức năng
- yêu cầu chức năng: đặc tả các chức năng mà phần mềm phải thực hiện.
- yêu cầu phi chức năng: là các ràng buộc về giải pháp và chất lượng (hiệu năng, việc bảo trì, độ an toàn, bảo mật,…).
- yêu cầu ặc tả các thuộc tính nổi bật: là ặc tả cho các thuộc tính phụ thuộc vào sự vận hành, ặc biệt là kiến thuống. các thuộc tính này không thể xác định được cho từng thành phần đơn lẻ.
-
theo tính kiểm định
- mơ hồ, không thể kiểm định
- rõ ràng, định lượng và có thể kiểm định được.
- Theo Phạm VI ặC Tả
- Yêu cầu hệ thống: ặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần mềm, with người, kỹ thuật,… của toàn bộ hệ /li>
- yêu cầu phần mềm: đặc tả các chức năng, giao diện,… của các cấu phần phần mềm.
- xuất phát từ giai đoạn khởi tạo dự án, cho tới khi hoàn thiện các tiến trình trong vòng đời phát triển của phần mềm. không chỉ là các hoạt động bề nổi nhìn thấy được.
- Được nhận biết như phần cấu hình của mọi việc, và được quản lí như việc quản lí các cấu hình; hoặc là sản phẩm của các qua trình trong vòng đời phát triển.
- Được thiết kế theo từng tổ chức và hoàn cảnh của từng dự án.
- người dùng: vận hành phần mềm.
- khách hàng: gồm những người được hưởng mục tiêu cuối cùng của phần mềm, những giá trị thương mại mà phần mếm đli>
- nhà phân tích thị trường: phân tích nhu cầu thị trường và tương tác với bên đại diện khách hàng.
- Đại diện pháp lý: kiểm soát việc tuân thủ quy định, quy ước chung, quy định pháp lý.
- kỹ sư phần mềm: jue lợi nhuận hợp pháp từ việc phát triển phần mềm.
- quản lí nguồn tài nguyên được sử dụng trong các tiến trình.
- cân đối nguồn nhân lực, tài chính, đào tạo và công cụ.
1.2. tiến trình yêu cầu phần mềm
vị trí trong mô hình tiến trình
các nhân tố tham gia
quản lý và hỗ trợ quy trình
chất lượng và cải tiến
- Định hướng tiến trình theo các chuẩn chất lượng và xây dựng mô hình cải tiến cho phần mềm và hệ thống.
- bao gồm:
- Độ bao phủ theo các mô hình và chuẩn cải tiến.
- việc đo đạc và đánh giá tiến trình.
- việc thực hiện và lên kế hoạch cải tiến.
- việc cài đặt và lên kế hoạch cho an ninh.
- tạo được niềm tin của khách hàng khi họ được tham gia vào giai đoạn thu thập yêu cầu.
- giảm việc phải làm lại trong qua trình phát triển
- quá trình phát triển sẽ nhanh hơn, giảm được những chi phí cho những yêu cầu không cần thiết.
- hạn chế phạm vi hệ thống bị phình rộng.
- mục tieu – goal. các mục tiêu về giá trị và giá thành thường mơ hồ, không rõ ràng. kĩ sư phần mềm cần chú ý để xác định rõ các mục tiêu đó. nghiên cứu tính khả thi là sẽ giúp giảm giá thành của qua trình phát triển. ví dụ kỹ sư phần mềm cần xác định chi phí xây dựng server với chi phí đi mua cái nào sẽ tối ưu hơn để lựa chọn.
- hiểu biết về các lĩnh vực. các kỹ sư phần mềm cần có kiến thức về các lĩnh vực như: mua sắm, ngân hàng, chăm sóc sức khỏe, … lĩnh vực mà phần mềm dƣm.
- các bên liên quan (stakeholders). nhiều phần mềm đã được chứng minh không đạt yêu cầu vì nó chỉ tập trung vào yêu cầu của một số bên mà bỏ qua các bên khác. do đó phần mềm đã giao rất khó để sử dụng hoặc phá vỡ văn hóa hoặc tổ chức chính trị của tổ chức khách hàng. các kỹ sư phần mềm cần phải xác định, miêu tả và quản lý các yêu cầu của các bên liên quan. Ví dụ phần mềm cho người không chuyên thì sửng chuột và các menu chọn, nhưng với người thành thạo thì cầnc cc Các Key Hot-Key ể ể rút ngắn thời gian tương tương tá
- nguyên tắc kinh doanh. là những điều kiện hoặc các ràng buộc được xác định để các doanh nghiệp hoạt động được. “Một Sinh Viên Không Thể đĂng ký vào các khóa học học kỳ tiếp Theo nếu vẫn còn một số môn chưa tonh ton học phí” sẽ là một ví dụ của nguyên tắc kinh đ đ đ đ đ đ đ đ đ đ đ đ đ đ đ đ đ đ học.
- môi trường vận hành. các yêu cầu sẽ được bắt nguồn từ môi trường mà trong đó phần mềm sẽ được thực thi. ví dụ như ràng buộc thời gian trong phần mềm thời gian thực hoặc ràng buộc hiệu năng trong môi trường kinh doanh.
- môi trường tổ chức. phần mềm thường có thể bị ràng buộc bởi cấu trúc, văn hóa và tổ chức chính trị. các kỹ sư phần mềm cần phải hiểu biết về chúng, phần mềm không nên ép buộc thay đổi ngoài ý muốn trong qua trình kinh doanh.
- phỏng vấn. phỏng vấn là cách truyền thống để thu thập yêu cầu.
- ưu điểm: thu thập ược ược những thông tin trực tiếp các thông tin có chất lượng cao, tính chân thực và ộn cậy có th჻m quể tronghiỻ.
- nhược điểm: Đòi hỏi người phỏng vấn phải có trình độ cao, am hiểu, có kỹ năng xử lý các tình huống. khó triển khai được trên quy mô rộng. tiếp cận khách hàng là việc tương đối khó vì cần hẹn trước.
- kịch bản. kỹ sư phần mềm cung cấp một hệ thống các câu hỏi bằng việc sử sụng các câu hỏi như “what if” và “how do you do this”. các loại kịch bản phổ biến được sử dụng là mô tả các trường hợp sử dụng. ví dụ: Điều gì sẽ xảy ra với phần mềm khi bị mất kết nối mạng,…
- các bản mẫu. kỹ thuật này sẽ làm rõ các yêu cầu không rõ ràng. có thể sử dụng mackup, prototypes (bản vẽ thô), wireframes (bản vẽ có working fluids rõ ràng) hoặc màn hình thiết kế hoặc các bản thử nghiệm ể xác minh nhẻ kác y. ví dụ: jue thập các yêu cầu về thiết kế hoặc chức năng của phần mềm.
- cuộc hội họp. một nhóm người sẽ mang lại nhiều cái nhìn sâu sắc hơn vào các yêu cầu phần mềm. mọi người sẽ cùng suy nghĩ, tinh chỉnh các yêu cầu. lợi thế của phương pháp này là các yêu cầu mâu thuẫn sẽ dễ dàng xử lý hơn.
- phát hiện và giải quyết xung đột giữa các yêu cầu
- tìm ra những giới hạn của phần mềm và cách phần mềm tương tác với tổ chức và môi trường hoạt động của nó.
- nghiên cứu các yêu cầu hệ thống để lấy được các yêu cầu phầu phần mềm.
- vấn đề tự nhiên. một số loại phần mềm đòi hỏi một số khía cạnh được phân tích đặc biệt nghiêm ngặt. ví dụ mô hình trạng thái và mô hình tham số của phần mềm thời gian thực quan trọng hơn so với hệ thống thông tin.
- sự thành thạo của kỹ sư phần mềm. kỹ sư phần mềm có kinh nghiệm sẽ lựa chọn các mô hình hay phương pháp để được kết quả tốt hơn.
- các yêu cầu về quy trình của khách hàng. khách hàng có thể áp đặt các ký hiệu ưa thích của họ hoặc phương pháp hoặc ngăn cản bất cứ cái gì mà họ thấy không quen thuộc. nhân tố này có thể xung đột với các nhân tố trước đó.
- thẩm định yêu cầu quan tâm đến việc chứng tở rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sᑻn. các yêu cầu phải được thẩm định để đảm bảo rằng người thực thi, người lập trình hiểu được yêu cầu.
- việc thẩm định phải đảm bảo dễ hiểu, nhất quán và hoàn thiện.
- thẩm định yêu cầu được quan tâm đến qua trình kiểm tra tài liệu yêu cầu có đảm bảo đầu ra là 1 phần mềm hoàn ch, ắ>
các kĩ thuật thẩm định yêu cầu
- xem lại yêu cầu
- sử dụng phiên bản mẫu, thử nghiệm
- thầm định mô hình
- kiểm thử chấp thuận
- khách hàng, người sử dụng thay đổi => thay đổi chức năng. ví dụ: khách hàng muốn tạo chức năng đặt lịch gửi mail. do đó phần mềm cần phải có chức năng email scheduler.
- xung đột giữa các yêu cầu mới nảy sinh, và giữa yêu cầu mới với yêu cầu cũ => quản lý thay đổi là trung tâm và đặc biệt quan trọng của quản lý các yêu cầu.
- yêu cầu bao gồm không chỉ đặc tả hệ thống mà còn những thông liên quan, giup dễ dàng quản lí và diễn giải yêu cầu
- Đinh danh yêu cầu cần được định nghĩa, ghi nhân và cập nhật như phần phần mềm trong qua trình phát triển và bảo trì.
- bao gồm:
- việc phân loại yêu cầu ví dụ: functional requirement and non-functional requirement
- phương pháp xác minh ví dụ: . xác minh bằng cách xem lại yêu cầu. xác minh bằng sử dụng phiên bản mẫu, thử nghiệm
- thầm định mô hình
- kiểm thử chấp thuận
- kế hoạch kiểm thử
- thuộc tính duy nhất để thuận tiện cho việc tham chiếu giữa các yêu cầu và lần vết. ví dụ: thông tin của yêu cầu duy nhất để tiện cho việc thêm và chỉnh sửa sau khi có sự thay đổi.
- lần vết yêu cầu có liên quan với việc khôi phục nguồn của yêu cầu và dự đoán những ảnh hưởng củu các yu.
- truy vết để thực hiện phân tích những ảnh hưởng khi yêu cầu thay đổi.
- một yêu cầu nên ược truy về những yêu cầu khác và các bên liên quan ể thúc ẩy nó (ví dụ: từ y y cầu phần mềm về thuố yêu cầ)
- Ngược lại. một yêu cầu nên được truy đến những yêu cầu khác nhằm thỏa mãn nó (ví dụ: từ yêu cầu hệ thống đến yêu cầu phần mềm)
- Đánh giá kích thước của sự thay đổi yêu cầu.
- ví dụ: đánh giá độ khó khăn của việc triển khai thay đổi yêu cầu, đánh giá xem nó ảnh hưởng tới những phân hệ nào trong hệ></
- Đánh giá chi phí cho việc phát triển hoặc duy trì một yêu cầu
- ví dụ: đánh giá nguồn lực, chi phí, man-day cho việc thay đổi yêu cầu.
- model công cụ cho việc vẽ (case tool, staruml)
- công cụ cho việc quản lí yêu cầu (spreadsheet, cơ sở dữ liệu,..)
1.8. công cụ sử dụng trong việc làm yêu cầu phần mềm
1.7.3. lần vết yêu cầu
1.7.4. Ðánh giá yêu cầu
1.6.1. xem lại yêu cầu
có lẽ phương tiện phổ biến nhất của việc thẩm định là sự kiểm tra hoặc xem lại các tài liệu yêu cầu. một nhóm người được giao nhiệm vụ tìm các lỗi, sai sót, thiếu sự rõ ràng, và độ lệch so với tiêu chuẩn. thành phần của nhóm này ặc biệt quan trọng (Ít nhất cần có ại diện khách hàng ể có ược ịnh hướng đúng ắn), và hểc dcọ có thừ. việc nhận xétc có thể ược thành lập sau khi hoàn thành các tài liệu ịnh nghĩa hệ thống, các tài liệu ặc tả hệ thống, ặc tả cơ bản cho 1 phi làm yêu cầu. ví dụ. Công ty ưa ra 1 tiêu chuẩn chung khi làm tài liệu, các kí hiệu, mô hình ối tượng, cần phải ược thống nhất, nhưng một nhân viên mới vào chộn n y Cay n ê n ê n ê n ê n ê n ê n ê n ê n ê n ê n neme phương pháp xem lại yêu cầu sẽ giúp tìm ra sai sót này giúp đồng nhất trong qua trình viết tài liệu.
1.6.2. sử dụng phiên bản mẫu, thử nghiệm
sử dụng phiên bản mẫu, thử nghiệm là dùng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu. Ưu điểm của phương pháp này nhằm giúp dễ dàng trong việc giải thích những yêu cầu của phần mềm, giúp khách hàng có những phản hồi kịp thời để làm rõ hệ thống đang sai ở đâu, cũng như phát hiện ra những yêu cầu mới. Ví dụ việc sửng mô hình giao diện người dùng (mackup, ..) giup nguời lập trình cũng như khách hàng dẽ hiểu ết kiệm honor việc miiêu tản thuầng dẽi ồu ồt ồt ồ sự biến ộng hay sự thay ổi yêu cầu sau khi dùng bản thử nghiệm là rất thấp bởi vì có sự thống nhất giữa người lận bậ và trìchá cánhà cánhà. bên cạnh những ưu điểm đó, phương pháp dùng phiên bản mẫu cũng có một số nhược điểm như sau. dùng phiên bản thử nghiệm làm phân tán sự tập trung của người dùng. ví dụ, phiên bản mẫu là phiên bản chưa hoàn thiện về mặt thẩm mĩ cũng như chức năng. Điều đó khiến người dùng nhầm tưởng rằng chất lượng sản phẩm có chất lượng không tốt. dùng phiên bản mẫu có thể tốn kém hơn cho việc phát triển. ví dụ, khách hàng qua tập trung vào chức năng của phiên bản mẫu sẽ dẫn đến lỗi phát sinh, người làm yêu cầu lại ại ải sải. do đó việc giải thích đây chỉ là bản mẫu, thử nghiệm là đặc biệt quan trọng. vì vậy sẽ tránh lãng phí nguồn nhân lực.
1.6.3. thẩm định mô hình
thẩm định model là thẩm định lại chất lượng các model information model, behavior model, structure model) đã được phát triển trong suốt quá trình phân tích. ví dụ trong mô hình ối tượng, chún ta phải kiểm tra xem liên kết giữa các ối tượng, giữa sự trao ổi dữ liệu giữa các ốôi tượng x chuẩgá. các model phải đủ các tiêu chí: hoàn thiện, nhất quán và chuẩn xác.
1.6.4. kiểm thử chấp thuận
một đặc điểm quan trọng của yêu cầu phần mềm là nó có thể kiểm định rằng sản phẩm cuối cùng phải thầa yu cên. viết các test case dành cho các yêu cầu để kiểm tra khả năng đáp ứng được các yêu cầu end user. sản phẩm cuối cùng phải thỏa mãn các test case.
1.7. khảo sat hiện trạng
thực trạng có rất nhiều thay ổi, do đó quản lí những thay ổi và duy trì những yêu cầu là chìa khóa quyết ịnh sự thành mền cềm củ. Ví dụ: Không phải tổ chức nào cũng có thói quen làm tài liệu cũng như quản lý yêu cầu ặc biệt với những công ty mới thành lập hoặc những công tyco cc nguồn nhân nhân nhân khi những công ty này mở rộng, số lượng khách hàng trở lên lớn hơn, sản phẩm của họ bắt đầu phát triển, thì lúc này việc tìm lại những yêu cầu và thúc đẩy thêm nhiều tính năng để đáp ứng nhu cầu thị trường và sự thay đổi của môi trường là rất cần thiết. do đó, tài liệu yêu cầu và quản lí những thay đổi là chìa khóa cho sự thành công của bất kì quá trình yêu cầu nào.
1.7.1. quản lý thay đổi
quản lý thay đổi là trung tâm của quản lý yêu cầu. yêu cầu phần mềm luôn luôn thay đổi: môi trường doanh nghiệp và kĩ thuật thay đổi. phần cứng mới => giao diện mới. ví dụ: màn hình thay đổi, sắc net hơn nên giao diện cũng phải chăm chút hơn. luật thay đổi, nhu cầu doanh nghiệp thay đổi => thay đổi chức năng. ví dụ: luật doanh nghiệp không cho tiết lộ thông tin người dùng. do đó hệ thống quản lí user cần phải bảo mật hơn
1.7.2. Định danh yêu cầu
1.4. phân tích yêu cầu
nhằm mục đích:
1.4.1. mô hình hóa khái niệm
xây dựng các mô hình trong một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm. mục đích của nó là để hiểu rõ về những vấn đề xảy ra cũng như miêu tả được giải pháp của vấn đề. do dó mô hình khái niệm báo gồm các mô hình của các thực thể từ miền vấn đề, cấu hình để phản ánh các mối quan hệ thệth giớng bu. Có rất nhiều loại mô hình có thể ược phát triển bao gồm biểu ồ use case, mô hình luồng dữ liệu, mô hình trạng thati, mô hình dựa trên mục tiêu, tương tág người dùng, môn dữ … các yếu tố ảnh hưởng đến sự lựa chọn mô hình bao gồm:
1.4.2. thiết kế kiến trúc và phân bổ yêu cầu
thiết kế kiến trúc là điểm mà tại đó qua trình yêu cầu trùng lặp với phần mềm hoặc các hệ thống thiết kế. Trong nhiều trường hợp, các hành vi kỹ sư pHần mềm như là kiến trúc sư pHần mềm bởi vì vì qua trình pHân tích và xây dựng các yêu nhiệm đáp ứng các yêu cầu được xác định. phân bổ là quan trọng để cho phép phân tích chi tiết các yêu cầu. do đó, ví dụ, khi một bộ các yêu cầu đã ược phân bổ cho một thành phần, các yêu cầu cá nhân có thể ược phân tích đáp ứng các yêu đicầo. trong các dự án lớn, phân bổ thúc đẩy một vòng mới của phân tích cho mỗi hệ thống. thiết kế kiến trúc được xác định chặt chẽ với các mô hình khái niệm.
1.4.3. Đàm phán, giải quyết các xung đột giữa các yêu cầu
điều này liên quan ến việc giải quyết vấn ề giữa hai yêu cầu của các bên lóên quan cùng các tính nĂng không tương thích, giữa các yêu Trong tất cả các trrường hợp kỹ sư pHần mềm không ược tự ưa ra các ịt ịnh mà cần thiết tham khảo từ các bên li li quan ểt ược một sự ồ ồng thuận thu ựp.
tuy nhiên, thường rất khó khăn để có được thông tin thực. ngoài ra, các yêu cầu thường phụ thuộc vào nhau, và có ưu tiên tương đối. trong thực tế, các kỹ sư phần mềm thực hiện các yêu cầu ưu tiên thường xuyên mà không biết về tất cả các yêu cầu. nó cũng bao gồm một phân tích từ các kỹ sư phần mềm ước tính chi phí thực hiện từng yêu cầu hoặc liên quan đến các yêu cầu khác.
1.4.4. phân tích hình thức – formal analysis
formal analysis đã có một tác động trên một số lĩnh vực ứng dụng, đặc biệt là các hệ thống toàn vẹn cao. các hình thức thể hiện của các yêu cầu đòi hỏi một ngôn ngữ với ngữ nghĩa định nghĩa chính thức (ví dụ: ngôn ngữ z). việc sử dụng một phân tích hình thức cho các yêu cầu biểu hiện có hai lợi ích. Đầu tiên, nó cho phép các yêu cầu thể hiện bằng ngôn ngữ được xác định một cách chính xác và rõ ràng, do vậy tránh đưểc khả n hi. thứ hai, yêu cầu có thể được lý giải trên, cho phép đặc tính mong muốn của phần mềm cụ thể để chứng minh. phân tích hình thức nhất là tập trung vào giai đoạn khá muộn của phân tích yêu cầu.
1.5. Đặc tả yêu cầu
ặc tả yêu cầu là một mô tả của hệ thống phần mềm ược phát triển, ưa ra các yêu cầu chức năng và phi chức năng, và tó thể bao gồm một tập hợp các cac cac cac cac cac cac cac cac ( maj) tả tương tác giữa người dùng với phần mềm. Ặc tả yêu cầu tạo cơ sở cho một thỏa Thuận giữa khác hàng và nhà cung cấp vềng gì gì pHần mềm đã làm ược tốt cũng nhưng gì chưa ược như mong i. nó cũng cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro và lịch trình. Ối với các hệ thống pHức tạp có 3 loại tài liệu ược tạo ra là: ịnh nghĩa hệ thống, yêu cầu hệ thống vỻu các yên ối với sản pHẩm pHần mềm
1.5.1. tài liệu đặc tả hệ thống.
còn được biết như là tài liệu yêu cầu người dùng hay là tài liệu vận hành ghi lại những yêu cầu hệ thống. nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ domain. Độc giả của tài liệu bao gồm hệ thống người dùng hoặc khác hàng. vì vậy nội dung của nó phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. tài liệu sẽ liệt kê các yêu cầu hệ thống c cuar với các thông tin cơ bản về ối tượng hệ thống, môi trường mục tiêu của nó, giả ịnh và cácec y cầu phi chi chi chi chi chi chi. Nó có thể bao gồm mô hình khái niệm ược thiết kế ể ể minh họa cho ngữ cảnh hệ thống, sửng kịch bản, và các miền thực thí chynh, cũng như Luồng công việc.
1.5.2. Đặc tả yêu cầu hệ thống
người phát triển những dự án phần mềm có những thành phần thuần túy là software và những phần non-software. ví dụ như máy bay hiện đại thường tách biệt yêu cầu hệ thống với yêu cầu phần mềm. Theo quan điểm này, yêu cầu hệ thống ược quy ịnh, các yêu cầu pHần mềmco nguồn gốc từ các yêu cầu hệ thống, và sau đó các yêu ối v vv vv vv vv vv vv vv vv vv vv vv vv
1.5.3. Đặc tả yêu cầu phần mềm
ặC tả yêu cầu pHần mềm tạo cơ sở chi việc thỏa Thuận giữa khách hàng và nhà thầu hoặc các nhà cung cấp vềng gì sản pHẩm pHần mềm có làm việc việc đc đ nó cho phép một đánh giá nghiêm ngặt các yêu cầu trước khi có thể bắt đầu vào việc thiết kế và làm giảm việc thiết kế lại. nó cung cần cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro, và lịch trình. các tổ chức cũng có thể sử dụng một tài đặc tả yêu cầu phần mềm làm cơ sở để phát triển kế hoạch kiểm tra và xác minh. Đặc tả yêu cầu phần mềm cung cấp một cơ sở thông báo cho chuyển một sản phẩm phần mềm cho người dùng mới hoặcặc các tnm. cuối cùng, nó có thể cung cấp một cơ sở để nâng cao phần mềm. Yêu cầu phần mềm thường ược viết bằng ngôn ngữ tự nhiên, nhưng ặc tả yêu cầu pHần mềmc có thể ược bổ sung bằng các mô tả chynh thức gần chính thức. lựa chọn các ký hiệu thích hợp và các khía cạnh của kiến trúc phần mềm cụ thể được mô tả chính xác hơn so với ngôn ngữ nhi t. các nguyên tắc chung là ký hiệu nên được sử dụng cho phép các yêu cầu để được mô tả là chính xác càng tốt. Điều này đặc biệt quan trọng đối với các phần mềm an toàn cao và một số loại phần mềm đáng tin cậy khác. tuy nhiên, sự lựa chọn của các kí hiệu thường được hạn chế bởi việc đào tạo, kỹ năng, và sở thích của các tác giả v. Một số chỉ tiêu chất lượng đã ược phat triển có thể ược sử dụng liên quan ến chất lượng của ặc tảu cầu pHần mềm như chi pHí, hài lòng, hi đ, tếng. chỉ tiêu chất lượng cho đặc tả yêu cầu của cá nhân bao gồm mệnh lệnh, chỉ thị, các pha yếu, tùy chọn, và sự duy trì. các chỉ số cho các tài liệu đặc tả yêu cầu phần mềm bao gồm kích thước, dễ đọc, đặc tả kỹ thuật, chiều sâu vĺp.
1.6. thẩm định yêu cầu
tất cả tài liệu yêu cầu cần được thông qua qua trình thẩm định và kiểm duyệt. vậy thẩm định yêu cầu là gì?
khái niệm
1.3. thập yêu cầu
là giai đoạn ầu tiên trong việc xây dựng sự hiểu biết về sản phẩm pHần mềm và các vấn ề ề cần thiết phải giải quyt quan (stakeholders) ượC xác ịnh. Thiết lập các mối quan hệ giữa các nhóm phat triển và khách hàng. liên tục qua toàn bộ vòng ời phát triển pHần mềm (sdlc), qua trình trao ổi với các bên Liên quan khác nhau tại mỗi các thời điểm khác nhau. tạo ra các kênh cho sự giao tiếp này. họ sẽ là trung gian giữa khách hàng và kỹ sư phần mềm. một số lợi ích của jue thập yêu cầu:
1.3.1. Nguồn yêu cầu – Requirements Sources
các yêu cầu có rất nhiều nguồn trong đặc thù phần mềm và điều quan trọng là tất cả các nguồn tiềm năng cần đáưánh gic xá. phần này nhằm nâng cao nhận thức của các nguồn khác nhau của yêu cầu phần mềm và những framework để quản lý chúng. những điểm chính của nguồn yêu cầu bao gồm:
1.3.2. kỹ thuật thu thập- provocation techniques
một khi các nguồn yêu cầu được xác định, các kỹ sư phần mềm có thể bắt đầu jue thập thông tin yêu cầu từ chúng. phần này tập trung vào các kỹ thuật để thu thập các thông tin cần thiết từ các bên liên quan.
Các kỹ sư phần mềm cần phải linh hoạt với các sự việc xảy ra ví dụ: người dùng gặp khó khăn trong việc mô tả yêu cầu của họ, có thể thông tin quan trọng không được nói ra hoặc có thể không muốn hoặc không thể hợp tác.
Thu thập không phải là hoạt động thụ động, ngay cả khi các bên liên quan sẵn sàng hợp tác các kỹ sư phần mềm phải cố gắng để thu thập thông tin chính xác nhất.Một số kỹ thuật thu thập yêu cầu như:
phân loại
ví dụ: project trong a:
yêu cầu sản phẩm là xây dựng trang web trường học điện tử với các tính năng như giáo viên quản lý câu hỏi, đề thi; học sinh tham gia làm bài; administrator duyệt câu hỏi của giáo viên trước khi đăng,…
yêu cầu tiến trình: phải thực hiện theo mô hình agile. sản phẩm cuối cùng bao gồm cả sản phẩm và backlog cho từng sprint.
