Building in Public | My First Foray into Eliciting Requirements
- erinvh620
- Jul 31
- 6 min read
Updated: Aug 27
TL;DR My first go at writing a requirements document!
After researching comparable apps and websites, my logical next step is to write requirements for the app I'm developing. I've never written requirements before, so I started out by doing an afternoon's worth of research.
Karl Wiegers is an author that's already on my radar because of his 2002 book on peer reviews in software, and I'm aware he's written quite a few books about requirements. He also regularly posts articles on Medium, many of them about requirements. So I sat down and read the following articles of his:
I found these to be a super helpful starting point. Next, I went back through my previous blog post to consolidate all of the "likes" and "dislikes" from my research of comparable apps. I also jotted down some other notes, things like:
Apple User Interface guidelines and other stuff to get on the app store
acceptable crash rate?
acceptable rate of bugs reported?
not retaining any user information
not taking up much space on the phone
not using much battery
not exposing user to security vulnerabilities
quick launch time!
Some requirements categories
usability
reliability
same answer every time guaranteed
i.e deterministic behaviour
aesthetics
i.e. nice icon, nice colours and fonts
Then, I copied and pasted my first two "Building in Public" blog posts, the consolidated list of likes and dislikes, and my rough notes into chatGPT and asked it to write me a requirements document.
It spit out something half decent. Not perfect of course--I've adjusted quite a few of the details myself, and got rid of a good bit of redundancy. But I liked the overall structure of the output, and I love the emojis. For me, it was a helpful starting point, as I often find it easier to iterate than to create.
Below is the requirements doc that I've ended up with.
🧶 Knitting Calculator App – Requirements Document v0.1
🧠 Overview
A mobile app for knitters that helps distribute increases and decreases evenly across a row or round—eliminating mental math, minimising cognitive load, and supporting different stitch types. Designed for knitters of all experience levels, with a beautiful, minimal UI.
🎯 Goals
Support knitters in maintaining their knitting flow
Provide clearly explained solutions to common increase/decrease instructions, eliminating confusion and decision fatigue
Serve as a high-quality portfolio app for design and iOS development
Experiment with code review tools and services
👤 Who Are My Users?
Hobbyist knitters (of any level, beginner to advanced)
who want help with "knitter’s choice" instructions
who want to avoid breaking their rhythm to do math
who want an easy way to record their choice in their Ravelry notes
Knitters who read other knitters' Ravelry notes for help
As Karl Wiegers says, "Your customer's customers are your customers."
Knitting pattern creators
📱 Core Features
🔁 1. User Inputs
Increase vs decrease
default: increase
Knitting flat vs knitting in the round
default: flat
clarify that this is not about using straight needles vs circular needles
Row length and number of stitches to increase/decrease
default to something like, "I have 52 stitches on my needles. I want to increase by 8 stitches (over 1 row) for a total of 60 stitches."
Type of increase/decrease stitch (e.g. m1, kfb, yo)
increase default: m1
decrease default: k2tog
🧵 2. Support for Different Stitch Types
Each type should be explained with:
Text description
Visual preview (photo or diagram)
Guidance on when to use (visible vs invisible, left-leaning vs right-leaning, beginning of row, etc.)
video explanation?
👁 3. Verbal Instructions and Visual Representation of Each Solution
Traditional pattern instructions (e.g. "k4, m1, k5, m1, k4")
Diagram showing how stitches will be distributed
🆘 4. Help & FAQs
Optional help overlays, info icons, or tappable FAQ links
Address common points of confusion (stitch types)
Explain default assumptions (e.g. stockinette, flat vs in-the-round)
✍️ 5. Knitting Project Context Questionnaire
Small guided flow to help choose the best stitch for the situation
E.g., “Do you want a visible increase?” → suggest YO
🧶 6. Pattern Assumptions
Assume stockinette
Let users override for other fabrics (e.g. ribbing, reverse stockinette, garter)
📤 7. Export/Share Options
“Print these instructions”
“Copy to clipboard”
Possibly “Save to Ravelry notes” or "Share as image"
✉️ 8. Frictionless User Feedback
Include an easy way for app users to send comments, questions, or bug reports to the development team
♿ 9. Accessibility
Fully support Dynamic Type for users who adjust text size in iOS settings.
Ensure VoiceOver compatibility:
All interactive elements must have clear accessibility labels.
Visuals (like diagrams) should have descriptive text alternatives.
Maintain sufficient colour contrast and avoid conveying meaning by colour alone.
Prioritise touch target size for tappable elements (minimum 44x44 pt).
🛠 Technical Requirements
📱 1. iOS Platform
Built with latest stable version of iOS (e.g. iOS 18+)
Swift + SwiftUI
Optimised for both phone and tablet
🧪 2. Quality
Deterministic behaviour: Same user inputs always yield same outputs
Reliability
Low crash rate (<0.1%)
Not dependent on cell data or wifi
I often knit on long flights where I usually don't have access to wifi (or cell reception)
Performance:
Launch time <2 seconds
Minimal CPU + battery usage
Target a small install size (ideally under ~100 MB) to avoid cellular‑download warnings and create a low‑friction experience, even though the App Store allows up to 4 GB.
User Analytics
Capture anonymous, aggregate usage data to inform product improvements.
Track key flows (e.g. calculator completion, stitch type selection, FAQ usage) to identify pain points and UX friction.
Use privacy-conscious tools
No personal data collection or user tracking.
🔒 3. Security & Privacy
No user login required
No personal data stored or transmitted
No third-party tracking or analytics
⚙️ 4. Maintainability
Clean architecture to allow adding backend or login later
All logic unit-testable
CI/CD setup
Software design decisions should be well-documented
To facilitate on-boarding / open-source contributions
To make it easy to re-visit assumptions later on
✨ Design Requirements
🧪 1. Usability Principles
Minimal UI that avoids clutter
Minimise cognitive load (use defaults, clarify terminology, offer guidance)
Keep screens focused—one task at a time
Hide optional features until needed
Error messages should be clear and helpful (not technical)
No notifications
No annoying pop-ups asking to track or prompting for an AppStore review
🎨 2. Aesthetic Goals
Clean, modern UI with delightful touches (e.g. "Do the math!" button)
Calming, non-corporate colour scheme (soft greys, cozy pastels)
Good typography hierarchy and whitespace
A polished, aesthetically pleasing, and intuitive/fitting/appropriate app icon
📈 Out of Scope (For Now)
Light/dark theme toggle
Support for multiple languages
Other calculators
decrease shaping tools (e.g. for sleeves),
calculators for blankets,
calculators for picking up stitches,
raglan shaping,
buttonhole spacing
Crochet calculators
iCloud sync
macOS version
Android version
web version
Allowing user to adjust solution
This set of requirements is meant to be a living document. It will change as I:
learn more about how to write a requirements document
start working on the app
collect user feedback
That's why I'm choosing to version the document. Now that I have some requirements, I think that some possible next steps are:
coming up with a name for the app, as well as an app icon and a splash screen
developing wireframes for the app
making a prototype of the app (?)
laying the foundations for the technical work: choosing a project management tool, setting up a repository, deciding on a Git workflow, and other things like that.
As I was working on this document, it struck me that "upstream" skills (as in, upstream from the coding), like eliciting requirements, might become more and more important as AI gets better and better at writing code. Hard to say for sure though.
If you think I've missed anything important, or have any opinions on the requirements I've put together, please feel free to comment below or contact me directly at erin@thepassionatecoder.com! I am always open to feedback as I'm always looking to learn and grow. Thank you for reading!
EDIT: The more feedback I get, the more I think I need to read one of Karl Wieger's full requirements books, rather than just his Medium articles!
Comments