TAILIEUCHUNG - Writing Better Requirement 2002 phần 9

Ví dụ: ". xem đám mây bão của radar ." Xác định các tiêu chí kiểm chứng Mỗi yêu cầu phải được kiểm chứng. Thường thì bạn có thể chỉ ra một bài kiểm tra có thể bằng cách thêm một cụm từ đơn giản để hội đủ điều kiện một nhu cầu cơ bản. | Writing Better Requirement 69 Example .view storm clouds by radar . Define verifiable criteria Every requirement must be verifiable. Often you can indicate a possible test by adding a simple phrase to qualify a basic need. Later you will connect a specific acceptance criterion with the requirement text. Example . at least WO kilometers ahead Acceptance criterion Aircraft flying at 800 km hour at 10 000 meters towards a known storm cloud indicated by meteorology satellite report storm cloud is detected at a range of at least 100 km. You do not necessarily have to write acceptance test criteria while you are preparing user requirements but you should be sure that practical tests or other ways of verifying your requirements can be devised readily. If it isn t verifiable it isn t a requirement. Suzanne Robertson talks in slightly different language about fit criteria - how well a solution fits the requirement system designers can use the criteria to satisfy themselves that they have found a solution acceptable to users Robertson 1999 . In Robertson s method every requirement contains not only a textual description of the user s intention but also a fit criterion. This strict approach means more effort while writing but promises fewer problems later in the project. User requirements may be clear but hard to verify. For example The crew find the sailboat fun to sail could in principle be tested in a series of trials using representative volunteers of different ages and levels of experience. The acceptance criterion might be that the average enjoyment score is over 50 . This is a feasible approach and though it might be costly in practice testing is usually cheaper than making a product that does not attract users. Don t write like this There are many ways of losing control of a project through bad requirements. Here are some things to avoid. None of the rules are absolute - you can probably make up examples where each of the danger signs is reasonable in a .

• Kỹ thuật lập trình
• lập trình C
• lập trình windows
• lập trình ứng dụng
• lập trình máy tính
• lập trình Java
• lập trình dot Net
• lập trình C#
• ứng dụng máy tính
• mẹo vặt cho windows 7
• thủ thuật máy tính
• Bài giảng Ngôn ngữ lập trình C
• Bài giảng Ngôn ngữ lập trình C++
• Ngôn ngữ lập trình C
• Ngôn ngữ lập trình C++
• Lập trình C++
• Bài tập lập trình
• Ôn tập lập trình C++
• Ôn thi lập trình C++
• Cách học lập trình C++
• Tài liệu lập trình C++
• Đề thi lập trình C++
• Các lớp nhập trong C++
• Các lớp xuất trong C++
• STL lập trình khái lược trong C++
• hướng dẫn lập trình C
• kỹ thuật lập trình C
• phương pháp lập trình C
• kinh nghiệm lập trình C
• cẩm nang lập trình C
• Lớp và đối tượng
• kinh nghiệm lập trình
• giáo trình Ngôn ngữ lập trình C#
• bài giảng Ngôn ngữ lập trình C#
• tài liệu Ngôn ngữ lập trình C#
• lý thuyết Ngôn ngữ lập trình C#
• hướng dẫn lập trình C#
• Bài giảng Ngôn ngữ lập trình C và C++
• Ngôn ngữ lập trình C và C++
• Ngôn ngữ lập trình
• Các phương pháp lập trình
• Lập trình cấu trúc
• Lập trình module
• Học lập trình C
• Kỹ thuật lập trình C cơ bản
• Giáo trình kỹ thuật lập trình c
• Tài liệu lập trình c cơ bản
• Giáo trình kỹ thuật lập trình C nâng cao
• giáo trình Ngôn ngữ lập trình C
• tài liệu Ngôn ngữ lập trình C
• lý thuyết Ngôn ngữ lập trình C
• kỹ thuật lập trình
• lập trình c c++ nâng cao
• lập trình c c++
• thủ thuật lập trình c
• ngôn ngữ lập trình nâng cao
• ngôn ngữ lập trình nâng ca
• tài liệu Lập trình C#
• kinh nghiệm Lập trình C#
• cẩm nang Lập trình C#