Request Template
Guidance​
This is the Request template. Requests are intended to be 'pure' problem statements. Well written, it does not step into any particular solution, it solely notes what needs to be solved, and the parameters in which that solution needs to fit.
The closer to a pure problem you can get, the wider the scope there is of allowing for innovative solutions that you would have never dreamed of.
This approach is fruitful because it moves the solution away from one person's head, to openning it up to the world to think about it on your behalf.
However, to make this approach powerful you need to state two things: the Why, and the Parameters. Both are needed for a well written, open Request.
The 'Why' is the overarching aim. E.g. "I have a hot date. I want us both to have a meal and have a lovely time." That's the strategic intent, and really what you're interested in.
The Parameters (Tactical Intent) is the more detailed constraints that you see as important. E.g. must get to the restaurant safely, could get to the restaurant in style, should get there clean and tidy, must not make me look like a dooshbag.
You can also nest Tactical Intents. E.g. what does it mean to get there in style?
By stating the Request in this way you've done two things: first is to make clear what you're actually trying to do, second it to restrict the search space of solutions around not only what needs to be done, but the manner in which it needs to be done. That leaves the space open for anyone to suggest solutions. E.g get an Uber, get a lift from your mate, buy a motorbike...
It also shows your thinking, because of that strategic intent. That's important because tactics can be flexible, but strategy should be fixed. E.g. what happens if there's foul weather stopping all travel? The Tactical Intent can't be met. But why not a virtual dinner instead? That would meet your strategic intent.
Targets​
List all the Requests that this Request aims to target.
Strategic Intent​
<insert NFT image based on title>
This section to give the overview of what this Request is trying to achieve, without saying how it show achieve it.
Tactical Intent​
This section to give a breakdown on the lower level objectives of what the Request should achieve, again without saying how it show achieve it.
Detailed Description​
Tactical Intent 1: Title here​
<insert NFT image based on title>
This section is can recur multiple times, and provides details in the following format, where these words are interpreted as in RFC 2119:
Must​
This word means that the definition is an absolute requirement of the specification.
Should​
This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course
Could​
This word means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
Should Not​
This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label
Must not​
This phrase means that the definition is an absolute prohibition of the specification.
Tactical Intent N: Title here​
etc...