Writing Specs
Last updated
Last updated
Specs help us ship better products, faster.
In terms of deciding what feature to design, there are a few ways to go about this:
There are three key components to a specification:
Functional Specifications: This is how the feature works from the perspective of the end user. In this part, we can completely abstract away any technical or backend considerations.
Technical Specifications: This describes the internal implementation. How are we going to make this work?
Test Cases: How do we judge that the feature is ready to deploy?
tl;dr — Explain the feature in one clear sentence.
Real Use Cases — We should describe at least two real use cases for customers in different industries.
Press Release — concept of working backwards from Amazon. In our case, we write a newsletter and blog post if its a major feature.
Description of V1 — A detailed description of the V1. We describe the functionality of the software in human language, that anyone can understand. Add lots of details.
Open Issues — This is a list of things that we have not yet worked out.
Non-Goals — What are we specifically not doing in this feature?
Future version — a description of what we will do in the future, but now not. This may result in changes.
Engineering approach — The engineer that is going to be working on this feature will write their technical description of the approach to the feature.
We do not have to write the test cases ourselves. We can upload the designs and functional specification to ChatGPT and get back a list of test case scenarios that we can run through, then we can use our brains to expand on these test cases and ensure that things are working.
