Planetoid: Created page with "Best Practices for Request for Proposal Documentation {{LanguageSwitcher | content = English, 漢字 }} == Avoiding Common Errors in RFP Development == The following examples illustrate common vague requirement phrases and suggested improvements to create clear, verifiable specification documents. Example 1: Browser Support Scope * Not recommended: "Does not s..."

2026-01-15T14:51:00Z

Created page with "Best Practices for Request for Proposal Documentation {{LanguageSwitcher | content = English, 漢字 }} == Avoiding Common Errors in RFP Development == The following examples illustrate common vague requirement phrases and suggested improvements to create clear, verifiable specification documents. Example 1: Browser Support Scope * Not recommended: "Does not s..."

New page

Best Practices for Request for Proposal Documentation

{{LanguageSwitcher | content = [[Best Practices for Request for Proposal Documentation | English]], [[Writing suggestion of request for proposal | 漢字]] }}

== Avoiding Common Errors in RFP Development ==

The following examples illustrate common vague requirement phrases and suggested improvements to create clear, verifiable specification documents.

Example 1: Browser Support Scope
* Not recommended: "Does not support IE" (<strike>IE must die</strike>)
* Problem: Only lists unsupported browsers (negative list) without clearly specifying the scope of support (positive list)
* Recommended approach: Explicitly specify supported browser versions and features, such as "Supports Chrome 90+, Firefox 88+, Safari 14+, and other browsers compliant with HTML5 standards." Refer to [https://html5test.com/ HTML5test] to verify browser support for specific features. If the website's target users' commonly used browsers are already known, these can be explicitly specified.

Example 2: Browser Version Specification
* Not recommended: "Supports HTML5-compatible modern browsers such as Chrome, Firefox, etc."
* Problem: "Modern browsers" is vaguely defined and cannot serve as an acceptance criterion
* Recommended approach: "Supports Chrome version 90 and above, Firefox version 88 and above," with specific version numbers

Example 3: Responsive Design and User Experience
* Not recommended: "Backend database input forms must follow RWD principles for elderly users" (Source: AMOS introduced by Lai Qun-Zu)
* Problem: "RWD principles" and "elderly users" are too vague and cannot be quantified for acceptance
* Recommended approach:
** RWD specifications: Clearly define supported screen sizes, such as "Supports mainstream resolutions including 1920x1080, 1366x768, 375x667. Refer to [[Research_surveys#Global_browser.2C_operating_system.2C_screen_resolution.2C_and_search_engine_market_share_statistics | Global browser, operating system, screen resolution, and search engine market share statistics]] to research which devices currently have high market share or meet project requirements, then specify 'supports which mobile devices at which screen sizes'"
** Accessibility design: Specify verifiable items such as "minimum font size 16px, minimum button touch area 44x44px, contrast ratio meets WCAG AA standards"

Example 4: Breaking Down Vague Features into Specific Sub-items
* Not recommended: "Website analytics must include machine learning capabilities"
* Problem: "Machine learning capabilities" is too broad and vague, encompassing multiple domains such as prediction, classification, clustering, etc.
* Recommended approach: Clearly list required sub-features and acceptance criteria, such as "Provide product recommendation feature: recommend 10 related products based on user browsing history, with click-through rate of 15% or higher" and "Provide user segmentation feature: classify users into 3-5 customer segments based on consumption behavior and generate characteristic reports"

Example 5: Data Export Functionality
* Not recommended: "Information charts provide export and download functions"
* Problem: Does not specify export format or field scope
* Recommended approach: "Provide CSV format export including fields: date, category, value, notes; provide PNG format chart download at 1200x800px resolution"

Example 6: Converting Vague Experiential Descriptions to Quantifiable Metrics
* Not recommended: "Website must be user-friendly"
* Problem: "User-friendly" is a subjective feeling and cannot serve as an acceptance criterion
* Recommended approach: Define measurable metrics, such as "Member registration process not exceeding 5 steps, average completion time under 2 minutes" or "After testing with 30 users, average SUS satisfaction scale score reaches 70 points or above"

Example 7: Maintaining Flexibility in Technical Solutions While Keeping Acceptance Criteria Explicit
* Not recommended: "Use TF-IDF and TextRank techniques to analyze social media article content and extract the top 10 trending keywords"
* Problem: Technology iterates rapidly; currently viable techniques may not always remain the best solution. Recommend maintaining flexibility for different approaches; also lacks clear functional acceptance criteria
* Recommended approach: "Analyze social media article content and automatically extract the top 10 trending keywords. Acceptance criteria: (1) Input: Over 1,000 social media articles daily (2) Output: Top 10 keywords, weight scores, and data reports, updated daily (3) Accuracy: Through manual sampling verification, keyword relevance reaches 80% or above (4) Technical approach: Proposed by vendor and executed after confirmation by Party A"

[[Category: Design]]
[[Category: Programming]]
[[Category: Communication]]
[[Category: Revised with LLMs]]

Best Practices for Request for Proposal Documentation - Revision history