Created
May 27, 2025 23:35
-
-
Save rsalas6/ac24fe1c88e7a0b814ba90ade3008989 to your computer and use it in GitHub Desktop.
Rubrics vague
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Please help identify vague constraints in a set of requirements or design criteria. Any requirement that is not specific, not measurable, or open to interpretation should be flagged. | |
For each vague constraint you identify: | |
- Provide the full criterion (do not abbreviate). | |
- Write a brief justification in English explaining why it is vague. | |
- Use the following format: | |
- (#<criterion number>) "<full criterion>" - <brief justification of why it is vague> | |
A vague constraint is one that: | |
- Uses subjective terms (e.g., “clear,” “good,” “optimal”) | |
- Lacks a measurable outcome | |
- Cannot be objectively verified | |
Examples of vague constraints: | |
- The code runs optimally | |
- The code is well designed for scalability | |
- Properly follow all the described instructions | |
- Documentation sections are correctly formatted | |
- Ensure good user experience | |
- Write clean code | |
- Keep functions short and simple | |
- Use intuitive variable names | |
- Design with performance in mind | |
- Maintain thread safety where applicable | |
We should instead provide clear, testable, and objective constraints. For example: | |
- Function `processData()` must run in O(n log n) time complexity | |
- All section headers in the documentation must be bold, size 16px, and left-aligned | |
- All button elements must be at least 44x44 pixels in size for accessibility | |
- Variable names must follow the snake_case convention | |
--- | |
**Example Input (set of constraints):** | |
1. The response should display a window with a white background on code run. | |
2. The response should include good documentation. | |
3. The code should be scalable. | |
4. The response should label the rectangular button as 'Make Investment.' | |
5. Ensure clean and readable code. | |
6. The user interface should be easy to use. | |
7. Follow the described instructions properly. | |
--- | |
**Expected Output (flagged vague constraints):** | |
- (2) "The response should include good documentation." - The term "good" is subjective and lacks specific quality or formatting criteria. | |
- (3) "The code should be scalable." - Scalability is not defined; there's no measurable way to evaluate how scalable the code is. | |
- (5) "Ensure clean and readable code." - “Clean” and “readable” are subjective and not defined in terms of style guides or formatting standards. | |
- (6) "The user interface should be easy to use." - “Easy to use” is subjective and lacks measurable usability metrics. | |
- (7) "Follow the described instructions properly." - “Properly” is vague and open to interpretation; it does not define what constitutes correct adherence. | |
Input: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment