requirements-scoping

Name: requirements-scoping
Author: proyecto26

48installs1forks

How to install requirements-scoping?

proyecto26/system-design-skills/requirements-scoping

$npx -y skills add proyecto26/system-design-skills --skill requirements-scoping

Installs into the current project.

Summary

This skill should be used when the user needs to "clarify requirements", separate "functional vs non-functional requirements", "scope the problem", figure out "what questions should I ask", state the "requirements for <X>", or otherwise pin down a vague design prompt before build

Files · 1

View on GitHub

SKILL.md

1	# Requirements Scoping
2
3	Turn a vague prompt ("design a news feed") into three written lists: what the
4	system does (functional requirements), the numbers and qualities that shape
5	it (non-functional constraints), and what is deliberately excluded
6	(out-of-scope). Skipping this step is the most common way a design goes wrong —
7	it ends up solving a different problem than the one in front of it, and every
8	later decision rests on an unchecked assumption. The discipline is not
9	about being slow; it is about making the problem concrete enough that the design
10	choices have something to be measured against. Without it, every component is a
11	guess, and the first hard follow-up question collapses the whole picture.
12
13	## When to reach for this
14	At step 1 of any design, before drawing a single box or naming a single tool. Any
15	time the ask is broad ("design YouTube"), ambiguous ("a real-time system"), or
16	silent on scale, consistency, or audience. Reach for it again mid-design when a
17	new constraint appears that may invalidate an earlier assumption — a re-scope is
18	cheaper than a rebuild. The clearest signal is the reflex to reach for a familiar
19	architecture before being able to state, in one sentence, what problem it solves
20	here. That reflex is exactly the trap: applying a remembered solution to a prompt
21	no one has actually read.
22
23	## When NOT to
24	Don't interrogate forever. The goal is enough clarity to choose a first
25	hypothesis, not a complete spec — three to five sharp questions usually suffice,
26	with written assumptions for the rest. Don't gold-plate scope: every accepted
27	feature is one to design and defend, so push the nice-to-haves into out-of-scope
28	(YAGNI). And don't re-scope on every challenge; distinguish a genuine constraint
29	change from a clarifying nudge.
30
31	## Clarify first
32	The questions that change the design the most, asked in rough priority order:
33
34	- Who uses it and how? Audience (consumer/internal/B2B), client (mobile, web,
35	both), and the one or two core user journeys. This bounds everything else.
36	- What are the must-have features? Force a ranked shortlist; the long tail is
37	out-of-scope until the core works.
38	- What scale? DAU/MAU, growth horizon (3/6/12 months), read:write ratio,
39	object sizes. These are the inputs `back-of-the-envelope` turns into QPS and
40	storage — capture them here, quantify there.
41	- What latency and availability targets? A p99 number and a nines target,
42	tied to the journey (a feed read vs a payment differ).
43	- How fresh must data be, and how bad is loss? Strong vs eventual consistency
44	and durability expectations drive the hardest later trade-offs; capture the
45	requirement (can a read be stale? can a recent write be lost?) here, and leave
46	the consistency-model theory to `consistency-coordination`.
47
48	If the user can't answer, state an assumption out loud and move on ("assuming 10M
49	DAU, read-heavy, eventual consistency is fine") — written assumptions are
50	revisable; silent ones are landmines. Capture each answer in the actual words used
51	("up to 5,000 friends", "must survive a region loss"): a stray detail now often
52	turns out to be the constraint that forces a structural choice later.
53
54	## The method (recipe)
55	A repeatable pass from prompt to scoped problem:
56
57	1. Restate the prompt in one sentence. "A service where users post short
58	messages and read a reverse-chronological feed of people they follow." This
59	surfaces hidden assumptions immediately and gets early buy-in.
60	2. List functional requirements as user-visible capabilities, verb-first:
61	post a message, follow a user, view a feed, search. These answer "what does
62	the system do" — each is an action an actor can take. Keep them testable and
63	free of implementation ("store in a DB" is not a requirement; "view a feed"
64	is).
65	3. Rank and cut to the core. Pick the two or three that define the product.
66	Explicitly defer the rest — deferral is a decision, not an omission. The core
67	is what the design lives or dies by; everything else can be a follow-up.
68	4. Derive non-functional constraints from the clarifying answers. Where
69	functional requirements say what the system does, non-functional ones say *how
70	well* it must do it: scale (DAU, QPS inputs), latency (p99), availability
71	(nines), consistency, durability, and any cost/compliance limits. These are
72	the numbers a design is measured against, and the o

People who liked this also viewed

6 picks

Type

requirements-scoping

48installs1forks

View on GitHub

How to install requirements-scoping?

proyecto26/system-design-skills/requirements-scoping

$npx -y skills add proyecto26/system-design-skills --skill requirements-scoping

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Requirements Scoping
2
3	Turn a vague prompt ("design a news feed") into three written lists: what the
4	system does (functional requirements), the numbers and qualities that shape
5	it (non-functional constraints), and what is deliberately excluded
6	(out-of-scope). Skipping this step is the most common way a design goes wrong —
7	it ends up solving a different problem than the one in front of it, and every
8	later decision rests on an unchecked assumption. The discipline is not
9	about being slow; it is about making the problem concrete enough that the design
10	choices have something to be measured against. Without it, every component is a
11	guess, and the first hard follow-up question collapses the whole picture.
12
13	## When to reach for this
14	At step 1 of any design, before drawing a single box or naming a single tool. Any
15	time the ask is broad ("design YouTube"), ambiguous ("a real-time system"), or
16	silent on scale, consistency, or audience. Reach for it again mid-design when a
17	new constraint appears that may invalidate an earlier assumption — a re-scope is
18	cheaper than a rebuild. The clearest signal is the reflex to reach for a familiar
19	architecture before being able to state, in one sentence, what problem it solves
20	here. That reflex is exactly the trap: applying a remembered solution to a prompt
21	no one has actually read.
22
23	## When NOT to
24	Don't interrogate forever. The goal is enough clarity to choose a first
25	hypothesis, not a complete spec — three to five sharp questions usually suffice,
26	with written assumptions for the rest. Don't gold-plate scope: every accepted
27	feature is one to design and defend, so push the nice-to-haves into out-of-scope
28	(YAGNI). And don't re-scope on every challenge; distinguish a genuine constraint
29	change from a clarifying nudge.
30
31	## Clarify first
32	The questions that change the design the most, asked in rough priority order:
33
34	- Who uses it and how? Audience (consumer/internal/B2B), client (mobile, web,
35	both), and the one or two core user journeys. This bounds everything else.
36	- What are the must-have features? Force a ranked shortlist; the long tail is
37	out-of-scope until the core works.
38	- What scale? DAU/MAU, growth horizon (3/6/12 months), read:write ratio,
39	object sizes. These are the inputs `back-of-the-envelope` turns into QPS and
40	storage — capture them here, quantify there.
41	- What latency and availability targets? A p99 number and a nines target,
42	tied to the journey (a feed read vs a payment differ).
43	- How fresh must data be, and how bad is loss? Strong vs eventual consistency
44	and durability expectations drive the hardest later trade-offs; capture the
45	requirement (can a read be stale? can a recent write be lost?) here, and leave
46	the consistency-model theory to `consistency-coordination`.
47
48	If the user can't answer, state an assumption out loud and move on ("assuming 10M
49	DAU, read-heavy, eventual consistency is fine") — written assumptions are
50	revisable; silent ones are landmines. Capture each answer in the actual words used
51	("up to 5,000 friends", "must survive a region loss"): a stray detail now often
52	turns out to be the constraint that forces a structural choice later.
53
54	## The method (recipe)
55	A repeatable pass from prompt to scoped problem:
56
57	1. Restate the prompt in one sentence. "A service where users post short
58	messages and read a reverse-chronological feed of people they follow." This
59	surfaces hidden assumptions immediately and gets early buy-in.
60	2. List functional requirements as user-visible capabilities, verb-first:
61	post a message, follow a user, view a feed, search. These answer "what does
62	the system do" — each is an action an actor can take. Keep them testable and
63	free of implementation ("store in a DB" is not a requirement; "view a feed"
64	is).
65	3. Rank and cut to the core. Pick the two or three that define the product.
66	Explicitly defer the rest — deferral is a decision, not an omission. The core
67	is what the design lives or dies by; everything else can be a follow-up.
68	4. Derive non-functional constraints from the clarifying answers. Where
69	functional requirements say what the system does, non-functional ones say *how
70	well* it must do it: scale (DAU, QPS inputs), latency (p99), availability
71	(nines), consistency, durability, and any cost/compliance limits. These are
72	the numbers a design is measured against, and the o

People who liked this also viewed

6 picks

Type