Phân tích: kĩ thuật yêu cầu RE

Phân tích: kĩ thuật yêu cầu RE

Kỹ thuật yêu cầu RE

„ Các kỹ thuật phát hiện yêu cầu

3.2.3 Đặc tả yêu cầu 3.2.4 Đánh giá yêu cầu

3.3 Quản lý yêu cầu

Mục tiêu

„ Kỹ thuật yêu cầu là một quá trình lặp bao gồm 3 loại hoạt động

„ Rút ra yêu cầu từ thực tế (Elicitation)

„ Đặc tả yêu cầu (Specification)

„ Xác thực (Validation)

„ Kết quả của quá trình là những đặc tả về hệ thống phần mềm

„ Ta dùng Requirements Engineering thay cho

Requirement Analysis vì nó có nghĩa rộng hơn

3.1.1 Yêu cầu là gì (Requirement - IEEE)?

„ a) A condition or capability (khả năng) needed by a user to

solve a problem or achieve (dành được, hoàn thành) an

objective (mục tiêu)

„ b) A Condition or capability that must be met or possessed (sở hữu) by a system or system component to satisfy a contract (hợp đồng), standard, specification or other formally (chính

thức) imposed (áp đặt) document

„ c) A documented representation of a condition or capability as

in definition (a) or (b)

Mức độ mô tả yêu cầu

„ Viết chủ yếu cho người dùng

„ Thường bằng ngôn ngữ tự nhiên cộng với các biểu đồ

„ Mô tả các dịch vụ và những ràng buộc hoạt động

Vd: xác định và đặc tả

Người đọc

Kỹ thuật yêu cầu (Requirements Engineering)?

„ “The hardest single part of the building a system is deciding what to build” [Bro87]

„ RE là bước chính yếu đầu tiên nhằm giải quyết vấn đề xử lý

dữ liệu Trong giai đoạn này:

„ Những yêu cầu của người dùng đối với hệ thống tương lai được xác định và được tư liệu (document) cẩn thận

„ Không cần xác định cách nào để giải quyết vấn đề

Requirements engineering

„ We use the term requirement engineering rather than the narrower notion (khái niệm) of requirements analysis to

emphasize (nhấn mạnh, làm nổi bật) that it is an iterative

and co-operative (cộng tác) process of analyzing a problem

„ Documenting the resulting observations (quan sát) and

„ Checking the accuracy (đúng đắn, chính xác) of the

understanding gained (thu được)

„ Requirements Engineering not only involves technical

concerns of how to prepare the requirements but also play a dominant role in social and cognitive (kinh nghiệm) aspects (khía cạnh)

Qui trình RE

the problem requirements elicitation

build a prototype

create analysis models

develop Specification Review

3.1.2 Phân loại yêu cầu

„ Có 3 loại yêu cầu:

„ Yêu cầu chức năng: chức năng dịch vụ hệ thống cung cấp

„ Yêu cầu phi chức năng: những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về

chất lượng.

„ Yêu cầu miền ứng dụng: phản ảnh những đặc trưng của miền ứng dụng

„ Có những yêu cầu ngầm định (implicit)

„ A requirement may be conscious (nhận biết) (known, spoken) / unconscious (forgotten, unspoken…)

Yêu cầu chức năng

„ Một số yêu cầu chức năng

„ Chức năng tính toán

„ Chức năng lưu trữ

„ Chức năng tìm kiếm

„ Chức năng kết xuất

„ Chức năng backup, restore

„ Chức năng đa người dùng

„ Chức năng đa phương tiện…

„ Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng thường quan hệ với những nguồn đặc trưng, thường là các use-case hay những qui tắc nghiệp vụ (business rule)

Ví dụ

„ Người dùng có thể tìm kiếm, download, in những bài báo

„ Người dùng được cấp một vùng lưu trữ riêng để có thể

copy để lưu trữ tài liệu lâu dài

Yêu cầu phi chức năng

„ Một số yêu cầu phi chức năng

„ Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ…

„ Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình…

„ Yêu cầu của người sử dụng: dễ sử dụng, thân thiện

„ Ràng buộc về ngân sách

„ Phù hợp với các chính sách của tổ chức sử dụng hệ thống

„ Yêu cầu tương thích giữa phần cứng và phần mềm

„ Các yêu cầu từ các tác nhân ngoài khác…

Phân loại yêu cầu phi chức năng

„ Các yêu cầu về sản phẩm: hiệu năng, độ tin cậy…

„ Các yêu cầu của tổ chức sử dụng hệ thống: thời gian bàn giao, yêu cầu phù hợp với hệ thống cũ…

„ Các yêu cầu ngoài: được xác định từ các tác nhân từ bên ngoài như các yêu cầu về luật pháp, yêu cầu tôn trọng

tính riêng tư…

Yêu cầu phi chức năng

Ví dụ

„ Yêu cầu sản phẩm: giao diện người dùng không chứa

frame và applet java

„ Yêu cầu tổ chức: qui trình phát triển hệ thống và tài liệu

phân phối phải phù hợp theo tiêu chuẩn “STAN-07”

„ Yêu cầu ngoài: hệ thống không được lộ thông tin của

khách hàng

Mục tiêu (Goal) và đo lường (measure)

„ Những yêu cầu phi chức năng khó phát biểu chính xác,

mơ hồ cần bổ sung bằng mục tiêu và một số đo lường

„ Ví dụ

„ Một mục tiêu của hệ thống

„ Hệ thống dễ sử dụng cho những người đã có kinh nghiệm và người dùng có thể tùy biến được giao diện làm việc

„ Một yêu cầu phi chức năng có thể kiểm tra

„ Người dùng có kinh nghiệm có thể sử dụng tất cả các chức năng sau 2 giờ huấn luyện Sau khi huấn luyện người dùng có kinh nghiệm sẽ không có lỗi trung bình quá 2 lỗi /ngày

Đo lường

Property Measure

Speed Processed transactions/second

User/Event r esponse time Screen refresh time

Robustness Time to restart after failure

Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements

Number of target systems

Tranh chấp giữa các yêu cầu phi chức năng

„ Để trọng lượng và lượng điện tiêu thụ thấp thì cần phải

dùng những chip có trọng lượng nhỏ và tiêu thụ năng

lượng thấp

„ Nhưng có thể phải sử dụng nhiều chip hơn

Yêu cầu miền ứng dụng

„ Yêu cầu miền ứng dụng được xác định từ lãnh vực ứng dụng của hệ thống, nó phản ánh các thuộc tính và ràng buộc của lãnh vực ứng dụng

„ Nó có thể là yêu cầu chức năng hoặc phi chức năng

VD:

„ Trong hệ thống Quản lý thư viện, do vấn đề bản quyền vài tài liệu phải được xóa ngay sau khi in

Các vấn đề về yêu cầu miền ứng dụng

„ Yêu cầu cần diễn đạt theo ngôn ngữ miền ứng dụng, khó

hiểu cho người phát triển

Thế nào là một yêu cầu tốt?

„ Correct - a quality that can only be ensured by the customer or user representative

„ Possible (feasible khả thi) - a quality that requires knowledge

of the environment on the part of the developer; available tools, techniques, people and budgets must be able to satisfy the final requirements;

„ Necessary

„ Prioritized

„ Very important – absolutely necessary (to be implemented

in the next release)

„ Important - but not necessary for the next release

„ Purely (chỉ là) optional - nice to have but implementation

will depend on resources and schedule

Thế nào là một yêu cầu tốt?

„ Unambiguous (rõ ràng)

„ Concise (ngắn gọn) - with only the information necessary to proceed too the next development step; associated history, costs, schedule and so on are housed elsewhere.

„ Verifiable (có thể thẩm tra) ( testable, measurable)

Cần chú ý tới những nhu cầu trong tương lai (future needs)

Một số ràng buộc Khi đưa ra các yêu cầu ta có thể dùng các ràng buộc

(constraint)

được môn kia

bán tiền mặt, nợ <1000$ thì được cho ghi nợ đến 1000$

dựa vào các luật

„ Thời gian xử lý: tiền mặt phải giao trước 16h30

„ Thời gian yêu cầu cho xử lý ngoài: báo cáo hàng tháng

phải gởi trước ngày 4 của tháng sau

„ Thời gian đáp ứng qua giao diện: khi người dùng nhấn

enter thì hệ thống phải hồi đáp trong vòng 2 giây

Example - Library Information System

Besides the requirements, which directly relate to the functions

of the software to be delivered, a number of other matters

should be addressed during the requirements engineering

phase :

„ On which machine will the system be implemented, and which

operating system will be used? Which type of DBMS is to be used? What type of terminal (thiết bị cuối) is to be used and

how many terminals will be supported (hỗ trợ)?

„ Which classes of users can be distinguished (phân biệt)? Will certain functions of the system be restricted certain classes of user? Normal library members will probably not be allowed to update the database or print the contents (nội dung) of the

database

Example - Library Information System

„ What is the size of the database and how is it expected to grow

in the course of time? These factors influence both storage

capacity needed and algorithms to be used.

„ What response time should the system offer? A search request for a certain book will have to be answered fairly quickly If the user has to wait too long for an answer, he will become

dissatisfied and search the shelves directly.

„ How much will a system of this kind cost? In our library

example, we should not only pay attention to the direct costs incurred by the software development effort The cost of data entry of the books etc is also important.

3.2 Qui trình RE

Qui trình RE

3.2.1 Phân tích khả thi

xác định có thể thực hiện trong những điều kiện về kỹ

thuật, tài nguyên, ngân sách… Một số vấn đề:

„ Hệ thống có đóng góp vào mục tiêu của tổ chức hay không

„ Hệ thống có thể được xây dựng bằng cách sử dụng công nghệ hiện tại và ngân sách cho phép.

„ Hệ thống có được tích hợp với các hệ thống khác đang sử dụng hay không.

Phân tích khả thi

„ Vấn đề xử lý hiện tại như thế nào?

„ Hệ thống đề nghị cung cấp những tiện ích gì?

„ Nếu hệ thống không được cài đặt thì sao?

„ Hệ thống đề xuất sẽ trợ giúp nghiệp vụ theo cách thức nào?

Technical Feasibility

„ Is the proposed technology or solution practical?

„ Do we currently possess the necessary technology?

„ Do we possess the necessary technical expertise

and is the schedule reasonable?

„ Economy Does the system offer adequate service level and

capacity to reduce the costs of the business or increase the profits

of the business?

„ Control Does the system offer adequate controls to protect against fraud and embezzlement and to guarantee the accuracy and

security of data and information?

„ Efficiency Does the system make maximum use of available

resources including people, time, flow of forms, minimum

processing delays, and the like?

„ Services: Does the system provide desirable and reliable service to those who need it? Is the system flexible and expandable?

Economic Feasibility

„ This evaluation looks at the financial aspects of the project It determines whether the investment needed

to implement the system will be recovered

„ In other words it concerns returns from investments

in a project.

„ Cost - Benefit Analysis calculates the Actual

Investments made in a Project and Actual Benefits

generated out of the Project

3.2.2 Phát hiện yêu cầu

định: các dịch vụ mà hệ thống cung cấp, các ràng buộc vận hành của hệ thống…

riêng của họ

thống

có thể xuất hiện những nhân tố mới, những thay đổi về môi trường nghiệp vụ

Stakeholder của hệ thống ATM

Qui trình phát hiện yêu cầu

„ Phát hiện yêu cầu: tiếp xúc với các stakeholder để phát hiện ra các yêu cầu của họ bao gồm các yêu cầu miền ứng dụng

„ Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có liên quan lẫn nhau và tổ chức chúng thành những nhóm gắn kết

„ Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu: định thứ tự

ưu tiên của các yêu cầu, phát hiện và giải quyết xung đột giữa các yêu cầu.

„ Tạo tài liệu yêu cầu (documentation)

Qui trình phát hiện yêu cầu

Những khó khăn khi phát hiện yêu cầu

giải quyết vấn đề

Các kỹ thuật thường dùng

„ Khung nhìn (Viewpoint)

„ Phỏng vấn (interview)

„ Kỹ thuật đặc tả ứng dụng thuận tiện FAST ( Facilitated Application Specification Techniques)

Deployment)

Khung nhìn (Viewpoint)

nó biểu diễn hệ thống dưới những góc nhìn khác nhau của các stakeholder

toàn diện hơn

Phân loại khung nhìn

„ Người và những hệ thống khác tương tác trực tiếp với hệ thống

„ Những người có thể không dùng hệ thống nhưng ảnh

hưởng tới hệ thống

„ Những đặc trưng và ràng buộc của miền mà ảnh hưởng tới yên cầu

VD: Hệ thống cấp bậc của khung nhìn

Phỏng vấn

trong những phần quan trọng nhất của quy trình xác định yêu cầu

„ Phỏng vấn có cấu trúc

„ Phỏng vấn không có cấu trúc

„ Phỏng vấn đóng: tập các câu hỏi đã được định trước và có nhiều đáp án để stakeholder lựa chọn trả lời.

„ Phỏng vấn mở: tất cả các câu hỏi không được định trước

và stakeholder phải tự giải thích và phát biểu theo quan

điểm của mình.

Phỏng vấn (tt)

„ Thu thập được tất cả các hiểu biết về công việc phải làm của stakeholder

„ Nắm rõ họ tương tác với hệ thống như thế nào.

các thuật ngữ của miền ứng dụng, việc diễn đạt.

„ Cởi mở, sẵn sàng lắng nghe stakeholder

„ Không có định kiến

„ Đưa ra những câu hỏi gợi mở, thân thiện.

Các bước phỏng vấn

„ Bước 1: Những câu hỏi căn bản, ngữ cảnh bất kỳ

„ Ai là người đưa ra những yêu cầu?

„ Ai là người sử dụng giải pháp?

„ Giải pháp thành công sẽ mang đến những lợi ích gì?

„ Có thể có cách khác để thực hiện giải pháp?

„ Bước 2: Nhằm hiểu sâu hơn vấn đề

„ Giải pháp tốt sẽ có output như thế nào?

„ Những vấn đề của giải pháp cần giải quyết?

„ Hãy cho biết môi trường của giải pháp?

„ Những vấn đề về thực thi và những ràng buộc ảnh hưởng?

„ Câu trả lời của bạn có chính thức không?

„ Câu hỏi của tôi có phù hợp với vấn đề mà bạn đang gặp ?

„ Tôi đã hỏi quá nhiều câu hỏi?

„ Những ai có thể cung cấp những thông tin thêm?

„ Tôi có nên hỏi bạn những điều gì khác?

Các bước phỏng vấn

„ Giới thiệu về bản thân

„ Sử dụng câu hỏi mở để bắt đầu

„ Luôn chú ý câu trả lời

„ Có kế hoạch cho nội dung chính

„ Kết hợp câu hỏi mở và đóng

„ Bám sát trình bày và phát triển chi tiết

Các bước phỏng vấn (tt)

„ Luôn cung cấp thông tin phản hồi

„ Hạn chế ghi chép

„ Có kế hoạch kết thúc

„ Tóm tắt nội dung, yêu cầu hiệu chỉnh

„ Cho biết ngày họ nhận báo cáo

„ Thống nhất ngày lấy lại bản hiệu chỉnh

„ Xác nhận lại lịch làm việc

Cách soạn câu hỏi

„ Nhiều hơn 2 câu hỏi về một vấn đề

„ Câu hỏi tối nghĩa

„ Câu hỏi không có câu trả lời

„ Câu hỏi tạo định hướng

„ Không xác định được hết các trường hợp trả lời

„ Gây nhầm lẫn về thứ tự câu trả lời

Soạn câu hỏi (tt)

„ Thử lại với nhóm nhỏ (5-10) Yêu cầu góp ý

„ Phân tích góp ý

„ Phân tích câu trả lời

„ Kết quả không như mong đợi, kiểm tra lại câu hỏi

Hướng dẫn phỏng vấn

„ Dùng ngôn ngữ ngắn gọn và rõ ràng

„ Không bao gồm ý kiến riêng của bạn trong câu hỏi

„ Tránh câu hỏi dài và phức tạp

„ Tránh những câu hỏi đe dọa

„ Don’t use “you” when you mean a group of people

Phỏng vấn: đánh giá

Advantages

1 Interviews give the analyst

an opportunity to motivate the

interviewee to respond freely

and openly to questions.

2 Allow the SA to probe for

more feedback from the

interviewee

3 Permits the SA to adapt or

reword questions for each

individual

Disadvantages

1 Interviewing is very time consuming, and therefore, costly, fact-finding approach

2 Success of interview is highly dependent on the systems analyst human relations skills

3 Interviewing may be impractical due to the location

of interviewee

„ Assuming an answer is finished or leading nowhere

„ Revealing your personal biases (thành kiến)

Định hướng cho phỏng vấn

Do

„ Be patient

„ Keep interviewee at ease

„ Maintain self control

Avoid

„ Talking instead of listening

„ Assuming anything about the topic and the

interviewee

„ Tape Recording - a sign of poor listening skills

Họp tham vấn (Brainstorming Sessions)

„ Brainstorming is a conference technique by which a group

attempts to find a solution of a specific problem by amassing (góp nhặt) all the ideas spontaneously (tự phát) by its

members

It is easier to tone down a wild idea than to think up a new one

[Alex Osborn]

Họp tham vấn

„ Theo tự điển “brainstorm” bao gồm: cảm hứng thình lình (sudden inspiration); a bright idea; a severe

outburst (bùng nổ) of excitement, often as a result of

a transitory (chớp nhoáng) disturbance (náo động) of cerebral (não) activity;

„ Họp tham vấn nhằm tránh những bất ngờ khó chịu sau đó trong dự án