Regarding design specification. It’s not just " in order for developers/programmers to be able to get anything done.". More importantly, it’s so you don’t months doing the wrong thing.
As such, I don’t want to start this notification feature without a good understanding of what people will use it for. If you can’t describe what you want to use it for, how am I able to design it, except for a basic system??
If I implement a basic system, the doors will flood open (I know from history) with users asking for notification A but only when C is below X. I will hack a few of these in and then find, I’ll have to rewrite the whole notification system.
For example, I designed the first graph system. Then users wanted “Q” with “G” but not “F”. I started doing a few of these and then rewrote and added the graph editor. The graphs were never designed for multiple sources or other data types, e.g., UV. Just your standard weather sources. So now I’m rewriting them to cope with other data types.
All I’m asking for are descriptions, like, I would like to know when wind is below 10knots and humidity is above 60% and there is a low chance of rain which is ideal plant spraying conditions. Check once a day (at 6pm) for the next 5 days range.
Or, if there is 20+mm of rain each day for the next 5 days which is ideal planting conditions. Check once a day (at 6pm) for the next 5 days range.
These two I made up from a email from a user I read a while ago and from my need to some planting.
It’s not too hard compared to the amount of work that goes into developing the feature. And the advantage is that you’ll have a notification system that works for you on the first go, instead of a frustrating system and a frustrated developer hearing all the conditions for notifications that should’ve been implemented.