Sean here from Klariti. Last week I ran a training course on Requirements Writing. A few things came up that I thought I’d share.
You’ve probably heard of the term ‘The Curse of Knowledge’. Essentially, this means that because you know how something works – you have the knowledge – you assume that others will understand it as well.
UPDATED – Functional Requirement Template – MS Office
When you hear someone says, “Well, do I have to explain everything?”, chances are the assumed the other person would intuitively grasp what they were showing them. By the way, this is one of the reasons developers struggle to explain how the software works. The ‘know’ how it’s linked together. Getting them to articulate this is a real challenge for business analysts.
Ok, so with that in mind, let’s look at three common issues that crop up writing functional requirements documents, and some ways to address them:
1. Ambiguity
Mistake:
The functional requirements are written vaguely, using subjective terms like "easy to use," "quickly," or "efficient." This ambiguity leads to misinterpretations and confusion for developers and stakeholders. These terms are so vague you can’t really measure them during test.
Fix:
- Use precise language.- Avoid subjective terms.
- Define specific criteria for success.
- Instead of "easy to use," specify the number of clicks or actions required to complete a task.
- Quantify "quickly" with a measurable response time (e.g., "the system must respond within 2 seconds").
2. Unattainable Requirements
Mistake:
Sometimes, requirements are written without considering technical limitations, budget constraints, or project timelines. As this can lead to delays, frustration, and scope creep, you need to zero in on these details.
Fix:
- Ensure requirements are feasible within the project's capabilities.- Prioritize requirements based on importance and impact.
- Involve developers in the requirements gathering process to provide technical feasibility feedback.
3. Lack of Testability
Mistake:
If your requirements are not clearly defined and measurable, it’s very difficult to verify if the software functions as intended. Once released, this can lead to missed defects and a higher risk of project failure.
Fix:
- Write each requirement with a clear test case in mind.- Specify the expected outcome or behavior for each requirement.
- Use tools like user stories or acceptance criteria to define specific scenarios and expected results.
The Finer Points
By addressing these common issues, you can create functional requirements documents that are unambiguous, achievable, and testable. This ensures a smoother development process, better communications between stakeholders, and a better product.
Did you find that useful? What’s you big ‘lesson learned’ when writing requirements? Make sure to connect on twitter or linkedin
This week, we updated the Functional Requirement Template for MS Office. Make sure to get your copy. It includes the following:
MS Word
- Functional Requirements Template 27 pages
- Requirements Traceability Matrix 6 pages
- Data Dictionary Template 8 pages
MS Excel
- Functional Requirements spreadsheet 2 worksheets
- Reporting Requirements spreadsheet 1 worksheet
- Evaluation Form 1 worksheet
