Requirements for Stack Overflow

Stack Overflow looks simple on the surface — users ask questions, others answer, and the community votes. But beneath that simplicity lies a carefully orchestrated system of reputation points, privilege thresholds, vote tracking, bounties, tag taxonomies, and moderation workflows. Without clear requirements, you'll either over-design (modeling features like chat that aren't in scope) or under-design (forgetting that downvotes cost the voter reputation too).

In an interview, spending 3-5 minutes on requirements signals maturity. It shows you think before you code, and it gives you a reference point for every class and method you'll design later. Every requirement below will trace directly to at least one class in our final implementation.

Let's define what our Stack Overflow system must do:

User Management:

1. FR1: Users can create an account with a username, email, and password. New accounts start with 1 reputation point.
2. FR2: Users have a profile displaying their reputation score, badges earned, questions asked, and answers posted.
3. FR3: User accounts can be in one of three states: ACTIVE, SUSPENDED, or BANNED. Moderators can suspend or ban users.

Questions:

4. FR4: Authenticated users (Members) can post a question with a title, body, and 1-5 tags.
5. FR5: Questions can be in one of these states: OPEN, CLOSED, or DUPLICATE. Moderators and high-reputation users can close or reopen questions.
6. FR6: Questions track their view count, which increments whenever any user views the question.

Answers:

7. FR7: Members can post answers to any open question. A user cannot answer their own question (Stack Overflow rule).
8. FR8: The question author can accept exactly one answer, which pins it to the top and awards the answerer +15 reputation.

Voting:

9. FR9: Members can upvote or downvote questions and answers. Each user can cast at most one vote per post (can change from upvote to downvote or retract).
10. FR10: Upvoting a question or answer awards the author +10 reputation. Downvoting an answer costs the author -2 reputation and the voter -1 reputation. Downvoting a question costs the author -2 reputation (no cost to voter).

Comments:

11. FR11: Members can add comments to any question or answer. Comments are flat (non-threaded) and cannot be voted on — they are lightweight discussion.

Tags:

12. FR12: Tags are system-managed labels (e.g., "java", "design-patterns", "python"). Questions must have at least 1 and at most 5 tags. Tags enable categorized browsing and search filtering.

Search:

13. FR13: Users (including unauthenticated guests) can search for questions by keyword, tag, or author. Search results can be sorted by relevance, newest, votes, or activity.

Bounties:

14. FR14: The question author can place a bounty (minimum 50 reputation) on their question to attract better answers. Bounties are deducted from the author's reputation immediately. If not manually awarded, the bounty expires after 7 days and half is auto-awarded to the highest-voted eligible answer.

Notifications:

15. FR15: Users receive notifications when: someone answers their question, comments on their post, their answer is accepted, or their post is voted on.

Beyond functionality, the system must satisfy:

1. NFR1 — Extensibility: Adding new post types (e.g., Wiki, Poll), new search strategies, or new badge types must not require modifying existing classes. The design should honor the Open/Closed Principle (Fundamentals S6).
2. NFR2 — Separation of Concerns: Reputation logic must be isolated from post classes. A Question should not know how many reputation points an upvote is worth — that's the ReputationManager's job. Similarly, notification dispatch must be decoupled from content creation.
3. NFR3 — Testability: Each component (voting, reputation, search, notification) must be testable in isolation without requiring the full system to be instantiated.
4. NFR4 — Thread Safety (awareness): While full concurrent implementation is out of scope, the design should identify where concurrent access matters — e.g., two users voting on the same post simultaneously, or a bounty being awarded while someone else answers.

In Scope:

• User registration, profiles, and account states
• Question and answer lifecycle (post, edit, close, reopen, delete)
• Voting (upvote/downvote) with reputation consequences
• Reputation tracking and privilege gating
• Comments on questions and answers
• Tag management and tag-based search filtering
• Search with configurable sort strategies (relevance, newest, votes, activity)
• Bounty creation, awarding, and expiration
• Badge awards (gold, silver, bronze) based on achievements
• Notification dispatch for key events

Out of Scope:

• Database persistence — we use in-memory collections
• REST API design — we model domain objects, not endpoints
• Full-text search engine — we model the search interface, not Elasticsearch internals
• Markdown/rich text rendering — we store body as plain strings
• OAuth/SSO authentication — we model user objects, not auth flows
• Flagging/spam detection — outside core LLD scope
• Review queues (suggested edits, close votes) — secondary moderation workflow
• Community wiki / documentation — separate product feature

Every requirement should map to at least one class or method. Here's a preview of how our requirements drive the class design:

Requirement	Drives Class(es)	Key Methods
FR1 (Create account)	User, StackOverflow	StackOverflow.registerUser()
FR4 (Post question)	Question, StackOverflow	StackOverflow.postQuestion()
FR7 (Post answer)	Answer, Question	Question.addAnswer()
FR8 (Accept answer)	Answer, Question	Question.acceptAnswer()
FR9 (Vote)	Vote, Votable	Votable.addVote()
FR10 (Reputation)	ReputationManager	ReputationManager.onUpvote(), .onDownvote()
FR11 (Comments)	Comment, Commentable	Commentable.addComment()
FR12 (Tags)	Tag, Question	Question.addTag()
FR13 (Search)	SearchStrategy, StackOverflow	StackOverflow.searchQuestions()
FR14 (Bounties)	Bounty, Question	Question.setBounty()
FR15 (Notifications)	NotificationObserver, User	User.notify()

This traceability ensures no orphan classes (classes without a requirements justification) and no orphan requirements (requirements without a corresponding class). We'll reference these IDs throughout the remaining tutorials.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should we support threaded comments, or are comments flat like Stack Overflow?" — This affects whether you need the Composite pattern for comments.
• "Is the reputation system in scope? Should we model privilege thresholds?" — If yes, it adds 2-3 classes. If no, you save time.
• "Should users be able to answer their own questions?" — Stack Overflow actually allows this (self-answers), but many interviewers expect the restriction. Clarify.
• "Are bounties in scope?" — Bounties add significant complexity (reputation escrow, expiration, auto-award). Clarifying saves you from either over-building or missing a key feature.
• "How many types of users: just regular users, or also moderators and admins?" — Multi-actor systems need Use Case Diagrams.

These questions demonstrate domain awareness and help you calibrate the design's complexity to the interview timebox.