Phân tích yêu cầu phần mềm

ĐĂC TẢ CHỨC NĂNG ? Đặc tả chức năng : mô tả những gì chương trình sẽ làm hoàn toàn từ quan điểm của người sử dụng.. TÁC GIẢ Quản lý dự án cần phải có một số kỹ năng và có khả năng giao

CHƯƠNG 4

YÊU CẦU -

REQUIREMENTS

 Trước khi viết code, bạn cần phải biết bạn sẽ xây dựng cái gì.

 Nếu bạn muốn trở thành 1 nhà phát triển sản phẩm, mắc ít lỗi và cho ra 1 sản phẩm tốt, thiết kế rõ ràng, bạn cần

những yêu cầu- càng chi tiết càng tốt

 1 bộ yêu cầu tốt sẽ nói với bạn những gì chương trình đươc lâp trình để thưc hiên

 Giúp ban tâp trung vào viêc suy nghĩ về chi tiết chương

trình, và nó cũng khiến ban lắng nghe người dùng, để hiểu

rõ và đúng hơn về những gì họ muốn

 Khách hàng là thượng đế - End User - Userablity

ĐĂC TẢ CHỨC NĂNG ?

 Đặc tả chức năng : mô tả những gì chương trình sẽ làm hoàn toàn từ quan điểm của người sử dụng Nó nói về các tính năng của chương trình và quy định cụ thể: màn hình, menu, hộp thoại, và những điều tương tư

 Đặc tả kỹ thuật : mô tả việc thực hiện nội dung thông tin chi tiết của chương trình Đó là cấu trúc dữ liệu, thuật toán được sử dụng, mô hình cơ sở dữ liệu, ngôn ngữ lập trình

 Ngôn ngữ tự nhiên nhiều biểu cảm và đa dạng

hơn so với ngôn ngữ lập trình =>Hãy thiết kế

bằng ngôn ngữ tự nhiên và dịch sang các ngôn

ngữ lập trình để thực hiện sau đó.

PHÁC THẢO ĐĂC TẢ CHỨC NĂNG

 Mỗi đặc tả chức năng đều khác nhau, và mỗi dư

án phát triển phần mềm là khác nhau Vậy hãy

viết ra phác thảo với sự nửa tin nửa ngờ và chỉ

sử dung phần ứng dụng vào phần mềm của bạn

Rất nhiều ý tưởng xuất phát từ đây

 Phi chức năng : không kiểm soát ánh sáng

 Khóa an toàn, ngăn chặn sóng vi ba ngay khi cửa được mở ra

TỪ CHỐI TRÁCH NHIÊM

 Bạn nên luôn luôn đặt một tuyên bố ngay từ đầu

rằng "đặc điểm kỹ thuật này chưa thực hiện được Nếu bạn nghĩ rằng một cái gì đó bị thiếu hoặc sai, hãy thảo luận lại"

 Thay vì từ chối thẳng, có thể : "đặc điểm kỹ thuật này là hoàn chỉnh cho phiên bản này Nếu bạn nghĩ rằng một cái gì đó là thiếu hoặc sai, hãy phản hồi và chúng tôi sẽ xem xét nó cho các phát hành tiếp theo

"

TÁC GIẢ

 Quản lý dự án cần phải có một số kỹ năng và có khả năng giao tiếp tốt với tất cả các bên liên quan để đạt được sự đồng thuận về nội dung của các đặc tả chức năng

 Người quản lý dự án thường phụ trách đặc tả chức năng và tất cả các vấn đề thiết kế chương trình

CHI TIẾT BẰNG HÌNH ẢNH NHỮNG THÔNG SỐ

KỸ THUÂT

 Một khi bạn đã viết một vài kịch bản, bạn sẽ có một ý tưởng tốt hơn về cách thức chương trình của bạn, những màn hình, hộp thoại, menu Điều này cho phép bạn đi qua từng màn hình và xắc ra các chi tiết về cách thức chúng đặt ra, các nút bấm, hộp văn bản, biểu tượng, đồ họa, chúng sẽ có, và những gì các màn hình khác đươc kết nối

 Hãy Sử dụng hình ảnh! Một hình ảnh của một màn hình hoặc một hộp thoại giá trị hơn một ngàn chữ Nó cung cấp cho người đọc một cái gì đó để phản ứng lại và họ suy nghĩ về dòng chảy chương trình và các vấn đề giao diện người dùng

CÁC VẤN ĐỀ MỞ

 Khi lần đầu tiên viết các đặc tả chức năng, ban sẽ có một hoặc hai (ngàn) những điều bạn không biết Điều đó ổn Chỉ cần đặt chúng trong phần "Những vấn đề mở" Sau đó, mỗi khi bạn gặp

gỡ với khách hàng, hãy điểm đến phần này và cố gắng để có được câu trả lời Một số trong những câu hỏi này sẽ chuyển đến phần các yêu cầu và một số sẽ kết thúc trong phần "Không yêu cầu", sau khi bạn nhận được những câu trả lời

 Đến cuối của dự án, các vấn đề này phải được giải quyết hết, không còn tồn tại Nếu không, vấn đề đó sẽ ám ảnh bạn.

BACKLOG (TỒN ĐỌNG)

 Hầu hết các thông số kỹ thuật chức năng không có một phần "tồn đọng", nhưng nếu muốn đăc tả chức năng của bạn là một tài liệu sống, bạn cần một chỗ để đặt tất cả các công việc bạn sẽ làm gì sau đó Điều này là một

điều tốt cho bạn Nó nói với khách hàng bạn đã không quên các tính năng này, và rằng bằng cách tích hơp

chúng vào các phiên bản tiếp theo, bạn đang cam kết cung cấp các phiên bản theo lịch trình được công bố Và

nó cho các nhà phát triển biết rằng bạn vẫn kiểm soát dự

án, dư án vẫn đang được thực hiện với chất lượng cao

và đúng thời hạn

CÁC LOẠI YÊU CẦU

 Trong một đặc tả chức năng thường có bốn loại khác nhau của các yêu cầu: yêu cầu người sử dụng, yêu cầu miền, các yêu cầu phi chức năng,

và không yêu cầu

YÊU CẦU NGƯỜI SỬ DỤNG

 Yêu c u ng ầ ườ ử ụ i s d ng g n ầ như luôn th hi n trong ể ệ ngôn ng t nhiên ữ ự

 Chúng cũng bao g m mô t v b trí màn hình, h p ồ ả ề ố ộ tho i và menu ạ

 B t kỳ y u t t ấ ế ố ươ ng tác trong các ch ươ ng trình c n ầ

đ ượ c mô t trong các yêu c u c a ng ả ầ ủ ườ i dùng

 Có th th hi n các yêu c u ng ể ể ệ ầ ườ i dùng nh k ch b n, ư ị ả

và mô t chi ti t t ng màn hình ả ế ừ

 S d ng hình nh nhi u nh khi b n đang làm yêu c u ử ụ ả ề ư ạ ầ

s d ng ử ụ

YÊU CẦU MIỀN

 Đây là những yêu cầu được áp đặt cho bạn bởi các miền ứng dụng của chương trình

 Một tập hợp các yêu cầu miền chi tiết cung cấp cho các nhà phát triển thông tin mà họ cần trong quá trình thiết kế chương trình.

 Yêu cầu miền thường được coi là "lớp giữa" phần mềm bởi vì chúng là trung tâm của các ứng dụng, bên dưới giao diện người dùng và trên các hệ điều hành, mạng, hoặc các phần mềm cơ sở dữ liệu Rất nhiều yêu cầu miền sẽ được thực hiện như các lớp riêng biệt và thư viện với các API riêng.

YÊU CẦU PHI CHỨC NĂNG

 Yêu cầu phi chức năng là những hạn chế về các

dịch vụ và chức năng của chương trình và cũng kỳ vọng về hiệu suất Chúng có thể bao gồm các thông

số kỹ thuật nền tảng mục tiêu, hạn chế thời gian, yêu cầu thực hiện, yêu cầu sử dụng bộ nhớ, các đặc quyền truy cập tập tin, yêu cầu bảo mật, thời gian đáp ứng, số lượng tối thiểu của các giao dịch mỗi giây, v.v Đây thường là những yêu cầu mà có thể không được hiển thị cho người sử dụng, nhưng mà làm ảnh hưởng đến trải nghiệm người dùng.

KHÔNG YÊU CẦU

 Đây là những điều bạn sẽ không phải làm

ĐÀO XÂU

 Hầu hết các văn bản kỹ thuật phần mềm sử dụng cụm từ

"yêu cầu gợi mở" để nói về quá trình nhận yêu cầu

hàng

 Việc này không đơn giản : liên hệ BTL !!!

VẤN ĐỀ PHẠM VI

Các ranh giới thực tế về những gì chương trình làm được là không rõ ràng Điều này có thể là do một số điều.

 Chương trình có thể là một phần của một hệ thống lớn hơn

và sự tích hợp của các bộ phận không được tốt.

 Khách hàng có thể không có suy nghĩ quá chính xác những

gì họ muốn các chương trình làm, vì vậy họ bắt đầu ném ra tất cả các loại ý tưởng

 Khách hàng có thể đã cung cấp mức đô chi tiết không cần thiết.

 Phạm vi có liên quan trực tiếp đến yêu cầu chui

VẤN ĐỀ VỀ SỰ HIỂU BIẾT LẪN NHAU

Nhà phát triển có chuyên môn, nhưng không biết nghiệp

vụ, và ngược lại với khách hàng => không hiểu nhau là chuyện bình thường.Có hai cách để khắc phục vấn đề :

 Phải có một ai đó ở giữa, người đã sống ở cả hai thế

giới và những người có thể hiểu và dịch vấn đề giữa hai người

 Khách hàng là một thành viên của nhóm phát triển :

Agile,XP : Khi khách hàng là một phần của đội ngũ

phát triển, bạn có thể nói chuyện với họ mỗi ngày

 Một cách khác để quản lý sự thay đổi là quyết định đẩy vào sử dụng; cung cấp cho người dùng một sự lựa chọn

VẤN ĐỀ PHI KĨ THUÂT

 Trong thực tế, đây là những vấn đề nhà phát

triển không bao giờ nhìn thấy; các nhà quản lý của họ phải bảo vệ họ khỏi những vấn đề phi kỹ thuật Các vấn đề cơ bản của yêu cầu phi kỹ

thuât là chính trị

PHÂN TÍCH CÁC YÊU CẦU

Phân tích có ba phần cơ bản:

 Phân loại các yêu cầu và sắp xếp chúng vào các khu vực liên quan

 Thứ tự ưu tiên dựa trên đầu vào của khách hàng

 Kiểm tra từng yêu cầu liên quan đến tất cả những người khác để đảm bảo chúng phù hợp Hãy tự hỏi một loạt các câu hỏi:

1 Có phải mỗi yêu cầu phù hợp với mục tiêu tổng thể của dự án?

2 Yêu cầu này thực sự cần thiết?

3 Yêu cầu này có thể kiểm chứng?

4 Có thể thực hiện được yêu cầu này trong môi trường kỹ thuật bạn đã có?

5 Yêu cầu này rõ ràng?