Software Requirements - SWR302

Hoạt động tổ chức và chia sẻ ghi chú thuộc về việc chuẩn bị cho việc thu thập thông tin. Khi bạn chuẩn bị cho việc thu thập thông tin, bạn cần phải tổ chức và sắp xếp các ghi chú của mình để dễ dàng truy cập và sử dụng. Điều này giúp bạn có thể thu thập thông tin một cách hiệu quả và chính xác hơn. Việc tổ chức và chia sẻ ghi chú cũng giúp bạn có thể dễ dàng chia sẻ thông tin với các thành viên khác trong nhóm, từ đó giúp việc thu thập thông tin trở nên nhanh chóng và hiệu quả hơn.

Elicitation trong kỹ thuật yêu cầu (requirements engineering) là quá trình thu thập thông tin về yêu cầu của người dùng hoặc các bên liên quan (stakeholders). Quá trình này nhằm mục đích xác định rõ những gì người dùng mong muốn và cần có trong hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như phỏng vấn, quan sát, phân tích dữ liệu và các phương pháp khác để thu thập thông tin về yêu cầu của người dùng. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng hệ thống hoặc sản phẩm đáp ứng được nhu cầu và mong muốn của người dùng.

Tạo một ma trận theo dõi trong một dự án giúp đảm bảo rằng tất cả các yêu cầu được liên kết với các giai đoạn thiết kế, thử nghiệm và triển khai. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách có hệ thống và toàn diện. Ma trận theo dõi giúp xác định rõ ràng các yêu cầu nào đã được thực hiện, và các yêu cầu nào vẫn còn cần được xử lý. Điều này giúp giảm thiểu khả năng xảy ra lỗi và đảm bảo rằng dự án được hoàn thành đúng hạn. Ngoài ra, ma trận theo dõi còn giúp cải thiện sự hiểu biết và giao tiếp giữa các thành viên trong dự án, giúp đảm bảo rằng tất cả mọi người đều có cùng một bức tranh về dự án.

Tên các trường hợp sử dụng nên được viết theo cách mô tả. Ví dụ, nếu trường hợp sử dụng liên quan đến việc đăng ký tài khoản, tên trường hợp sử dụng có thể là 'Đăng ký tài khoản mới'. Điều này giúp cho các nhà phát triển và người dùng dễ dàng hiểu được mục đích và chức năng của trường hợp sử dụng. Tên trường hợp sử dụng nên được viết một cách rõ ràng, ngắn gọn và dễ hiểu, giúp cho việc giao tiếp và hợp tác giữa các thành viên trong nhóm được hiệu quả hơn.

Các Use Case mô tả các tương tác giữa hệ thống và các thực thể bên ngoài. Điều này có nghĩa là chúng mô tả các hành vi của người dùng và các yêu cầu của họ đối với hệ thống. Mục đích chính của Use Case là xác định các yêu cầu chức năng của hệ thống và mô tả các tương tác giữa người dùng và hệ thống. Các Use Case thường được sử dụng để xác định các yêu cầu của hệ thống và để tạo ra các yêu cầu chức năng của hệ thống. Chúng cũng có thể được sử dụng để xác định các yêu cầu của người dùng và để tạo ra các yêu cầu chức năng của hệ thống.

Trong quản lý yêu cầu Agile, các câu chuyện người dùng (user stories) đóng vai trò quan trọng. Chúng cung cấp mô tả ngắn gọn, dễ hiểu và có thể thực hiện được về các tính năng từ góc độ của người dùng. Điều này giúp các nhà phát triển hiểu rõ hơn về nhu cầu và mong muốn của người dùng, từ đó tạo ra sản phẩm đáp ứng được nhu cầu của họ. Các câu chuyện người dùng thường được viết dưới dạng câu hỏi như 'Làm thế nào để tôi có thể thực hiện được điều này?' hoặc 'Tôi muốn gì?' Điều này giúp các nhà phát triển tập trung vào việc tạo ra sản phẩm đáp ứng được nhu cầu của người dùng, thay vì tập trung vào các tính năng cụ thể.

Trong quá trình thu thập yêu cầu (requirements elicitation), prototyping đóng vai trò quan trọng. Prototyping là quá trình tạo ra mô hình hoặc bản demo của sản phẩm để thu thập phản hồi từ các bên liên quan. Điều này giúp làm rõ các yêu cầu không rõ ràng và thu thập phản hồi từ các bên liên quan. Quá trình này giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu và kỳ vọng của khách hàng. Ngoài ra, prototyping còn giúp tiết kiệm thời gian và nguồn lực trong quá trình phát triển sản phẩm.

Prototyping trong kỹ thuật yêu cầu giúp giảm thiểu rủi ro trong quá trình thiết kế yêu cầu bằng cách cung cấp cho các bên liên quan một hình ảnh trực quan để xác minh các yêu cầu không rõ ràng. Quá trình này cho phép các bên liên quan xem xét và phản hồi về các yêu cầu trước khi triển khai hệ thống. Điều này giúp đảm bảo rằng các yêu cầu được hiểu đúng và giảm thiểu rủi ro phát sinh từ các yêu cầu không rõ ràng. Ngoài ra, prototyping cũng giúp xác định và giải quyết các vấn đề sớm, từ đó tiết kiệm thời gian và nguồn lực cho dự án.

Một quy tắc kinh doanh là một tuyên bố xác định hoặc hạn chế một khía cạnh nào đó của kinh doanh để kiểm soát hoặc ảnh hưởng đến hành vi của nó. Điều này có nghĩa là quy tắc kinh doanh xác định các điều kiện hoặc hạn chế nào cần được tuân thủ để đảm bảo hoạt động kinh doanh được thực hiện một cách hiệu quả và chính xác. Ví dụ, một quy tắc kinh doanh có thể xác định rằng một khách hàng phải là người lớn mới có thể thực hiện một giao dịch mua hàng trực tuyến. Việc xác định và áp dụng các quy tắc kinh doanh giúp đảm bảo rằng hoạt động kinh doanh được thực hiện một cách nhất quán và chính xác. Ngoài ra, việc phân loại các quy tắc kinh doanh giúp hiểu rõ cách chúng có thể được áp dụng trong một ứng dụng phần mềm, chẳng hạn như sử dụng hạn chế để thực hiện các điều kiện nhất định.

Chủ đề chính của việc ghi chép yêu cầu cho các hệ thống phức tạp là đảm bảo rõ ràng, nhất quán và tránh nhầm lẫn. Khi một hệ thống phức tạp được thiết kế, việc ghi chép yêu cầu trở nên khó khăn hơn do sự phức tạp của các yêu cầu và mối quan hệ giữa chúng. Để giải quyết vấn đề này, các kỹ sư phần mềm cần phải đảm bảo rằng các yêu cầu được ghi chép một cách rõ ràng, nhất quán và không có sự nhầm lẫn. Điều này có thể đạt được bằng cách sử dụng các phương pháp và công cụ hỗ trợ như mô hình hóa yêu cầu, phân tích yêu cầu và kiểm tra yêu cầu.

Một bộ yêu cầu cần phải đáp ứng các đặc điểm sau. Trước hết, chúng cần phải đảm bảo tính toàn diện (Completeness), nghĩa là mặc dù có thể thiếu một số thông tin quan trọng nhưng vẫn phải ghi nhận được các yêu cầu cơ bản. Điều này cho phép các nhà phát triển hiểu được những gì cần phải được thực hiện. Tiếp theo, tính linh hoạt (Modifiability) là rất quan trọng, giúp cho việc thay đổi yêu cầu trở nên dễ dàng mà không cần phải theo dõi lịch sử thay đổi hoặc xem xét các mối quan hệ phụ thuộc giữa các yêu cầu. Tuy nhiên, tính nhất quán (Consistency) là đặc điểm quan trọng nhất, đảm bảo rằng các yêu cầu không xung đột với các yêu cầu khác hoặc các yêu cầu cấp cao hơn liên quan đến kinh doanh, người dùng hoặc hệ thống. Cuối cùng, tính theo dõi (Traceability) giúp cho việc liên kết các yêu cầu với nguồn gốc của chúng và các yếu tố được tạo ra từ chúng trở nên dễ dàng hơn.

Khi chọn kỹ thuật biểu diễn phù hợp cho mô hình phân tích, nên tuân theo các hướng dẫn sau. Mỗi quy trình kinh doanh có thể được biểu diễn bằng các sơ đồ lưu lượng dữ liệu ở mức cao hoặc các sơ đồ Swimlane thể hiện vai trò và trách nhiệm trong quy trình. Ngoài ra, logic phức tạp có thể được biểu diễn hiệu quả bằng các cây quyết định hoặc bảng quyết định, thể hiện các kết quả có thể xảy ra hoặc các yêu cầu chức năng độc đáo. Điều này giúp đảm bảo sự rõ ràng và tránh nhầm lẫn trong quá trình phát triển.

Một nhà phân tích kinh doanh có thể chuyển đổi tiếng nói của khách hàng thành các thành phần mô hình cụ thể bằng cách xác định các từ khóa như danh từ, động từ và các tuyên bố điều kiện có thể ánh xạ đến các thành phần mô hình phân tích tương ứng. Điều này giúp họ hiểu rõ hơn về nhu cầu và mong muốn của khách hàng, từ đó tạo ra các mô hình phân tích chính xác và hiệu quả. Ngoài ra, việc xác định các từ khóa cũng giúp nhà phân tích kinh doanh tránh được sự nhầm lẫn và đảm bảo rằng các mô hình phân tích được xây dựng dựa trên thông tin chính xác và đáng tin cậy.

Một Entity Relationship Diagram (ERD) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Nó mô tả mối quan hệ giữa các thực thể (entity) trong một hệ thống dữ liệu. Các thành phần chính của một ERD bao gồm: thực thể (entity), mối quan hệ (relationship), quan hệ giữa thực thể (association), thuộc tính (attribute). Trong các lựa chọn trên, chỉ có một thành phần không phải là một phần của ERD. Đó là 'Cardinality'. Cardinality chỉ là một khái niệm trong ERD, nó mô tả số lượng thực thể tham gia vào một mối quan hệ. Nó không phải là một thành phần độc lập của ERD.

ERD (Entity-Relationship Diagram) là một công cụ quan trọng trong thiết kế cơ sở dữ liệu. Để xác định câu trả lời sai, chúng ta cần hiểu rõ về các thành phần của ERD. Câu trả lời sai là 'Individual instances of an entity will have the same attribute values'. Điều này không đúng vì các bản sao riêng lẻ của một thực thể sẽ có các giá trị thuộc tính khác nhau. Ví dụ, trong một bảng khách hàng, mỗi khách hàng sẽ có một địa chỉ riêng biệt. Câu trả lời đúng về ERD bao gồm: 'The cardinality, or multiplicity, of each relationship is shown with a number or letter on the lines that connect entities and relationships', 'Each entity is described by one or more attributes' và 'The diamonds in the ERD represent relationships, which identify the logical linkages between pairs of entities'.

Khi đánh giá các thuộc tính chất lượng phần mềm, thuộc tính nội bộ (internal quality attribute) là những thuộc tính liên quan trực tiếp đến thiết kế và cấu trúc của phần mềm. Trong các lựa chọn trên, hiệu suất (Efficiency) là một thuộc tính nội bộ vì nó liên quan đến khả năng sử dụng tài nguyên của phần mềm, chẳng hạn như thời gian chạy, dung lượng bộ nhớ và tốc độ xử lý. Ví dụ, một phần mềm có thể được thiết kế để chạy nhanh chóng và hiệu quả, nhưng điều đó không nhất thiết phải đảm bảo rằng nó cũng dễ sử dụng (usability) hoặc an toàn (security). Tương tự, khả năng sẵn có (availability) cũng không phải là thuộc tính nội bộ vì nó liên quan đến khả năng truy cập và sử dụng phần mềm, chứ không phải là cấu trúc hoặc thiết kế của nó.

Khi tạo mô hình giả (mock-up), mục đích chính là để cải thiện thiết kế giao diện người dùng. Điều này bao gồm việc xác định các yếu tố như bố cục, màu sắc, hình ảnh và các yếu tố khác ảnh hưởng đến trải nghiệm người dùng. Ngoài ra, mô hình giả còn giúp kiểm tra tính khả thi của kiến trúc và cho phép người dùng đánh giá toàn bộ quy trình và yêu cầu. Tuy nhiên, mục đích không phải là tạo ra một giao diện người dùng giả mạo mà không có chức năng thực sự. Điều này có nghĩa là mô hình giả phải có một số chức năng cơ bản để cho phép người dùng tương tác và đánh giá.

Câu hỏi này yêu cầu bạn chọn phương pháp không liên quan đến kỹ thuật ưu tiên. Trong đó, 'In or out' không phải là một kỹ thuật ưu tiên. Kỹ thuật này thường được sử dụng để quyết định liệu một yêu cầu hoặc một dự án có được thực hiện hay không. Trong khi đó, các phương pháp khác như 'So sánh đôi và xếp hạng', 'Bảng thang ba mức', 'MoSCoW', 'Dựa trên rủi ro' đều liên quan đến việc ưu tiên các yêu cầu hoặc dự án.

Phương pháp đánh giá yêu cầu liên quan đến việc tác giả mô tả một sản phẩm và thu thập ý kiến về nó được gọi là phương pháp Peer deskcheck. Trong phương pháp này, tác giả sẽ mô tả chi tiết về sản phẩm và gửi cho các thành viên khác trong nhóm để họ có thể đưa ra ý kiến và góp ý. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu và nhu cầu của khách hàng. Phương pháp này thường được sử dụng khi nhóm cần phải có sự tham gia và ý kiến của nhiều người để có thể tạo ra một sản phẩm tốt nhất.

Khi xác minh yêu cầu, chúng ta có thể ngăn chặn một số vấn đề tiềm ẩn. Đầu tiên, xác minh yêu cầu giúp ngăn chặn hiện tượng 'Scope creep', khi yêu cầu thay đổi không ngừng và vượt quá phạm vi ban đầu. Điều này có thể dẫn đến lãng phí thời gian và tài nguyên. Thứ hai, xác minh yêu cầu giúp ngăn chặn 'Misaligned Expectations', khi người dùng và nhà phát triển không có cùng hiểu biết về yêu cầu. Điều này có thể dẫn đến sự thất vọng và lãng phí thời gian. Cuối cùng, xác minh yêu cầu giúp ngăn chặn 'Cost Overruns and Delays', khi dự án bị chậm tiến độ và vượt quá ngân sách. Điều này có thể dẫn đến thiệt hại tài chính và ảnh hưởng đến uy tín của công ty.