Chương 1 - Phân tích và quản lý, yêu cầu phần mềm

Trong chương này sẽ trình bày lý do, tại sao, và những nhận định ban đầu về phần mềm.

1. Thu thập (3 nguồn, 10 kỹ thuật)

1.1 3 Nguồn

• Từ khách hàng: phỏng vấn khách hàng

  • Phỏng vấn khách hàng: người trả tiền cho dự án, các stakeholder

  • Các vấn đề: Khách hàng không biết mình muốn gì, dễ thay đổi, không thể diễn đạt bằng các thuật ngữ kỹ thuật

  • Các kỹ thuật: mockup, prototype, hướng dẫn từng bước, so sánh với các hệ thống khác

• Phân tích thị trường: các sản phẩm cạnh tranh, khả năng của chúng ta, khảo sát thị trường.

  • Đánh giá sản phẩm cạnh tranh: đã có, chưa có, chú ý không vi phạm bản quyền

  • Đánh giá khả năng của chúng ta: tốt hơn đối thủ điểm nào? kiến thức, kỹ năng gì ?

  • Khảo sát thị trường: PV khách hàng, xem xét xu hướng, ...

  • Vấn đề: Người ta không biết mình muốn gì, thị trường thay đổi khá nhanh

• Các tiêu chuẩn: các tiêu chuẩn hệ thống, tiêu chuẩn chính thức, tiêu chuẩn công nghiệp.

  • Các tiêu chuẩn và hệ thống liên vận hành: Các tiêu chuẩn hệ thống, các tiêu chuẩn miền

  • Các tiêu chuẩn chính thức: ANSI, ISO, IEEE

  • Các tiêu chuẩn công nghiệp: Java, DotNet

1.2 10 Kỹ thuật thu thập yêu cầu

1. Brainstorming: để cho stackholder suy nghĩ tìm ra các ý tưởng sáng tạo và cách tiếp cận mới tới vấn đề.

2. Workshops: là tạo ra các cuộc họp với nhiều stackholder để phác thảo ra và mô hình các yêu cầu.

3. Interviewing: kỹ thuật phỏng vấn trưc tiếp nơi mà người phân tích nghiệp vụ hỏi trực tiếp thông tin từ các stackholders.

4. Surveys: tạo ra các cuộc khảo sát thu thập thông tin anonymously từ stackholders.

5. Documentation Review: đọc các hướng dẫn và review từ các phần mềm tương tự.

6. Prototyping: kỹ thuật này giúp người dùng hình dung được một phần nào đó về phần mềm

7. Focus Group: là phỏng vấn theo nhóm.

8. Observation: người phân tích yêu cầu đến tận nơi quan sát các hoạt động hằng ngày và đặt câu hỏi về daily task của stackholders.

9. Card sorting: là kỹ thuật sắp xếp các thẻ để hiểu được trải nghiệm, kiến thức người dùng.

10. Role Playing: thử nghiệm vai trò của users.

2. Phân tích (các thuộc tính chất lượng, goal, objective, scope, tính khả thi)

2.1 Các thuộc tính chất lượng

1. Availability (Tính sẵn có): sự sẵn sàng về thời gian và địa điểm để dùng hệ thống.

2. Efficiency (Hiệu quả): Hệ thống tiêu thụ bao nhiêu tài nguyên.

3. Flexibility (Linh Hoạt): Khả năng thêm một chức năng mới.

4. Installability (Cài đặt): hệ thống có dễ dàng được cài đặt chính xác.

5. Integrity (Toàn vẹn): Hệ thống bảo vệ lại sự xâm nhập không hợp pháp và mất dữ liệu.

6. Interoperability (Tích hợp): Hệ thống có dễ dàng kết nối bên ngoài với các hệ thống khác.

7. Maintainability (Bảo trì): Hệ thống dễ dàng sửa lỗi và thay đổi yêu cầu.

8. Portability (Linh Động): hệ thống có thể làm việc đa nền tảng.

9. Reliability (Độ tin cậy): hệ thống có thể chạy đủ lâu trước khi bị lỗi.

10. Reusability (Tái sử dụng): sử dụng các components của hệ thống cho other systems.

11. Robustness (Mạnh mẽ): khả năng xử lý khi gặp phải các điều kiện không lường trước.

12. Safety (An toàn): khả năng xử lý trước tình huống hệ thống bị hư hại và phá hỏng.

13. Testability (Khả năng kiểm thử): có thể kiểm tra hệ thống cài đặt chính xác hay không.

14. Usability (Khả năng sử dụng ):dễ dàng cho mọi người học và sử dụng

2.2 Goal, objective, scope

2.3 Tính khả thi

Điều kiện đánh giá tính khả thi:

• Technology

• Finance

• Time : sản phẩm có thể hoàn thiện sớm để có thể cạnh tranh trên thị trường.

• Resources : tổ chức có đủ các tài nguyên cần thiết hay không

3. Đặc tả (UC diagram, Business Process, xác định độ ưu tiên)

3.1 UC diagram

3.2 Business Process (BNPM, activity diagram)

3.3 Xác định độ ưu tiên

• Constraints: Requirements, limited Budgets, strict Schedules, these constraints.

• Prioritization Technique 1:

  • Must Have (Essential - High)

  • Should Have (Desirable - Medium)

  • Nice to Have (Optional - Low)

• Prioritization Technique 2:

  • Important and Urgency

​	Important	Not Important
Urgent	High Priority	Don't do these
Not Urgent	Medium Priority	Low Priority

• Prioritization Technique 3: ước tính dựa trên giá trị và chi phí của mỗi requirements. Công thức tính :p = (value)/((cost*cost weight )+(risk*risk weight)p=(value)/((cost∗costweight)+(risk∗riskweight)

4. Kiểm tra (Các kỹ thuật kiểm tra, đánh giá yêu cầu)

• Reviewing Requirements

  • Informal

  • Formal - Inspection

• Testing the Requirements

  • Test case

• Validation with stakeholders

• Prototyping

• Validation with Management

• Validation with Project Team

• 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

4.1 Prototype

4.2 Requirement change (4 yêu cầu thay đổi, 6 tác nhân)

4 yêu cầu thay đổi

• Mutable requirements (Yêu cầu có thể thay đổi): là những yêu cầu thay đổi khi môi trường cài đặt hệ thống thay đổi.

• Emergent requirements (Yêu cầu cấp bách): là các yêu cầu không thể hoàn thành do tính cấp bách của nó.

• Consequential requirements (Yêu cầu hệ quả): là các yêu cầu phụ thuộc vài sự tiêu thụ của hệ thống, khi đưa vào sử dụng có thể sai.

• Compatibility requirements (yêu cầu tương thích): là các yêu cầu phụ thuộc vào các thiết bị và quy trình.

6 Change Factors

1. Requirements errors, conflicts and inconsistencies

2. Evolving stakeholders knowledge of the system

3. Technical, schedule or cost problems

4. Changing customer priorities

5. Environmental changes

6. Organizational changes

4.3 Trace

5. Risk Indetification

8 rủi ro mà mọi dự án đều có thê có:

1. Time

2. Costs

3. Scope

4. Feasibility

5. Quality

6. Stakeholders expectations

7. Human Resources

8. Technical Accuracy