CHAPTER 6 REQUIREMENTS ENGINEERING (RE)

CHAPTER 6 REQUIREMENTS ENGINEERING (RE) 1

CHAPTER 6: REQUIREMENTS

ENGINEERING (RE)

⇒ Chủ động nắm bắt nhu cầu của khách hàng hơn là hỏi họ có yêu cầu gì cho phần

mềm

RE process

Feasibility studies (Case khả thi)

Chúng ta sẽ nghiên cứu và quyết định có nên đầu tư vào dự án này hay không

Phương pháp tuần tự

Phương pháp lặp lại tăng dần thường áp dụng cho các dự án Agile.

Một số cách nghiên cứu ngắn:

Hệ thống có đóng góp được gì cho mục tiêu ban đầu của tổ chức hay không

Hệ thống có nên được phát triển dựa trên các công nghệ hiện có được hay

không

Hệ thống có thể được tích hợp với các hệ thống khác được hay không

Hệ thống có thể được phát triển trong phạm vi ngân sách và đúng tiến độ

Hệ thống có cạnh tranh được với những hệ thống tương tự trên thị trường hay

không

Interviews in practice

Phỏng vấn những người dùng tiềm năng

Uses-case Diagrams

Chức năng: mô hình hóa

Uses-case

Uses case miêu tả một loạt các hành động được thực hiện bởi actor để tạo ra kết

quả trực quan cho các actor khác

Types of Use Case Relationships

Sự khác biệt giữa include và extend:

Khi làm 1 case thì phải làm thêm 1 case

khác, khi kết hợp vào case chính thì

mainflow của case include phải chung

main flow của case chính.

Khi làm 1 case thì có thể hoặc không phải làm thêm 1 case khác khi kết hợp vào case chính thì main flow của case extend

là alternative flow của case chính.

Thu 23/06/2022

Requirements validation

Validation make sure the requirements reflect what the customer wants

Những dự án mới khi cần đưa ra yêu cầu phần mềm thì chúng ta phải khảo sát, mò

mẫm như cầu của khách hàng chứ chúng ta thể nào phải ánh đúng yêu cầu của

người dùng

Người ta sẽ làm những chức năng đơn giản, nhưng nội dung nhỏ để thăm dò thị

trường

Đối với những dự án tin học lớn dành cho những cơ quan, trường học,… thì yêu

cầu phần mềm gần như đã rất rõ ràng

Requirements checking

Validity: Tính đúng đắn của phần mềm

Verifiability: Khả năng kiểm thử phần mềm

Consistency: Phần mềm phải đồng nhất, hệ thống phải tương thích với các nền

tảng hiện có

Completeness: Phần mềm có đáp ứng đủ yêu cầu hay chưa

Realism: Phần mềm phải thực tế vì đôi khi khách hàng yêu cầu những chức

năng rất cao siêu, công nghệ hiện tại chưa có đủ khả năng đáp ứng

Requirements reviews

Regular reviews cần được tổ chức trong khi xác định các yêu cầu

Hình thức review có thể formal hoặc informal

Các hình thức liên lạc hiệu quả có thể giúp cho việc giải quyết vấn đề có thể được

hoàn thành từ những giai đoạn đầu

Formal review process

Step:

1 Plan: What, Who, When, How, Why

2 Hold an overview meeting

3 Each member reads and finds errors in requirements

4 Hold a review meeting/record errors

5 Authors fix errors found

6 Follow-up until all errors are fixed

Informal review process

Gửi tài liệu cho các thành viên, ai phát hiện ra lỗi thì sửa

Review Record

No Title Description Severity (Độ nghiêm trọng)

Requirements Management

Một quá trình quản lý các thay đổi trong suốt quá trình làm đồ án

Requirements change

Thay đổi thay xu hướng mới

Thay đổi theo độ đáp ứng của công nghệ hiện tại

Thay đổi theo độ ưu tiên

Dựa trên các môi trường kỹ thuật của doanh nghiệp

Requirements engineering processes

Common activies:

Requirements elicitation (rút trích, thu thập)

Requirements analysis (phân tích từ các dữ liệu khác nhau)

Requirements validation

Requirements managements

Feasibility studies (Case khả thi)

Đầu tư

Dựa vào những yêu cầu gì, thu thập thông tin và viết các báo cáo

Ai sử dụng ứng dụng này ? Thị trường ra sao ?

Công nghệ nào ?

Kĩ năng cần thiết ?

Thời gian, kế hoạch

Ngân sách

Requirements elicitation and analysis

Tìm hiểu về các ứng dụng trong lĩnh vực

Các dịch vụ mà hệ thống đó có thể cung cấp

Những ràng buộc vận hành

Tham gia bởi rất nhiều bên khác nhau

Problems of requirements analysis

Các stakeholders không biết những thứ họ cần

Stakeholders đưa ra những yêu cầu của riêng họ

Những xung đột về yêu cầu của các stakeholders

Các tổ chức và yếu tố chính trị ảnh hưởng

Thay đổi yêu cầu phần mềm (thay đổi luật, chính sách,…)

Process activities

Tìm ra các yêu cầu

Ghi lại các yêu cầu

Requirements discovery

Thu thập dữ liệu

Các nguồn thông tin khác nhau

Types of viewpoint

Interator viewpoints: Góc nhìn của người dùng tương tác trực tiếp với hệ thống

Indirect viewpoints: Góc nhìn tương tác gián tiếp

Domain viewpoints: góc nhìn của những người liên quan đến nghiệp vụ

Viewpoint identification

Dịch vụ hệ thống

Tiêu chuẩn quy định

Interviewing

Phỏng vấn những người dùng tiềm năng

Khám phá ra yêu cầu của khách hàng bằng cách phỏng vấn, xác nhận với người

dùng

Lắng nghe khách hàng

Không áp những yêu cầu mình muốn

Use Case Diagrams

Mô hình hoá yêu cầu phần mềm

Đặc tả yêu cầu phần mềm

Use Cases

Viết ra những hành động của Actors và cho ra những kết quả quan sát được

Description of Use Cases

Một chuỗi các dòng chảy sự kiện

Một dòng chảy chính (Main flow/Basic flow) và nhiều dòng chảy phụ (Alternative

flows)

Scenarios

Một trong những dòng chảy khả thi, xảy ra thực tế

User story = Scenario

Types of Use Case Relationship

Association

Generalization

Include: Khi làm 1 case thì phải làm thêm 1 case khác, khi kết hợp vào case

chính thì main flow của case include phải chung main flow của case chính

Extend: Khi làm 1 case thì có thể hoặc không phải làm thêm 1 case khác, khi kết

hợp vào case chính thì main flow của case extend là alternative flow của case

chính

Example: Khi login thì làm một relationship với một use case riêng để tránh login

dependency vào các use case khác, gây nên khó hiểu, nên có một pre-condition

Requirements validation

Reflect what the customer wants

Error in requirements result problems in design, code and test.

Requirements error costs are high

Fixing errors caused by incorrect requirements after delivery is much higher than in early stages.

Requirements checking

Mò mẫm những requirements ban đầu → Làm những features cơ bản → Dò thị trường

Không phản ánh đúng thị trường, fail

Verifiability (Khả năng kiểm thử phần mềm)

Yêu cầu phải cụ thể

Consistency (Đồng nhất)

Các yêu cầu có conflict

Conpleteness (Độ hoàn thiện)

Tất cả các yêu cầu có hoàn thiện

Realism (Thực tế)

Cài đặt được, chạy được trên thực tế Rất khó vì nhiều yêu tố ảnh hưởng

Requirement validation techniques

Requirements reviews

Most common approach Manual analysis of the requirements Prototyping

Using an executable model Test-case generation

Check testability

Requirements reviews

Requirements are defined

Requirements analysts, designers, developers, testers

May be formal (Strict reviews) or informal (Many ways to reviews: send

documents, share docs to fix immediately, walkthrough the docs and feedback)

Resolve problems at an early stage

Formal review process

Được xác định bởi công ty

1 Plan: what, who (Moderator, Authors, Reviewers), when, how, why

2 Hold an overview meeting

3 Each member reads and finds errors in requirements

4 Hold a review meeting/record errors

5 Authors fix errors found

6 Follow-up until all errors are fixed

Review Record

Requirements management

Process of managing changing requirements during the project

Requirements change

New and changed business needs

Better understanding

Priority from different viewpoints changes

Business and technical environments change

Requirements change management

Change request

Change analysis and costing

Change implementation

Key points

Feasibility study, requirements elicitation and analysis, requirements specification

and requirements management