You need to do requirements, just do it! Stop procrastinating...
Why is it so hard to create good requirements? And why do we accept to work without a clear, common view on what is supposed to be done?
This repo is just my way of trying to present a simple and clear way of getting over the requirements anxiety.
There is a 4-step process for this to be successful.
- Vision
- Requirements
- Use Case
- Test Case
This is the high level idea on what the project is going to achieve. Per definition this is not a technical description, but rather an idea, vision in plain English (or whatever language you speak).
It can be as simple as I'm going to fly to the moon
Requirements are a non-technical description of a single "thing" that you want to happen. They can be Functional or Non-Functional, but it really doesn't matter for the process which it is. I recommend not to name requirements as FR1 (Functional Requirement 1), but rather just R1.
Requirements can also be Legal, Constraints, or basically anything you want to happen, or not.
Use Cases are used to iron out any questions or ambiguity about the Requirements. A Use Case should be understood equally by person a or b. Any and all questionmarks needs to be removed, any need to interpet the Use Case must be removed.
Use Cases are non-technical, and should use plain English (non-technical terms) as much as possible.
Why, you wonder? - Use Cases is the last step where non-technical persons has any input on what is supposed to happen.
Test Cases are just the prof that the Use Case works. There is often a 1:1 relationship between Use Case and Test Case.
i.e. R1 -> T1
Requirements, Use Cases and Test Cases should be numbered and prefixed with
Requirements: R
Use Cases: U
Test Cases: T
So Use Case #1 would be U1, or optionally U1-<short desc>
I have put together some examples to get you going.