This specification was generated by PostIdea from a plain English description of a real-time chat application. The conversation took under 6 minutes — target users, concurrency expectations, message persistence requirements, and presence tracking needs. What follows is the complete functional and non-functional requirements breakdown: machine-verifiable, implementation-ready, and structured so your AI coding tool can act on it directly.
If you're looking for chat application software requirements that go beyond "users can send messages" and actually tell you what "done" looks like in code, this is it.
Version: 1
Generated by: PostIdea pipeline — Socratic discovery → constraint extraction → spec generation
Acceptance Criteria:
room_id and message_content, when POST /api/messages is called, then HTTP 201 is returned with {message_id, timestamp} and the message is broadcast to all connected clients in the room within 200ms.room_id, when POST /api/messages is called, then HTTP 404 is returned with {error: 'room not found'}.Testable Signals: MessageService, send_message, WebSocketHandler
Acceptance Criteria:
room_name, when POST /api/rooms is called, then HTTP 201 is returned with {room_id, room_name}.room_id, when POST /api/rooms/{room_id}/join is called, then HTTP 200 is returned and the user is added to the room's participant list.room_id, when POST /api/rooms/{room_id}/join is called, then HTTP 404 is returned with {error: 'room not found'}.Testable Signals: RoomService, create_room, join_room
Acceptance Criteria:
room_id, when GET /api/rooms/{room_id}/presence is called, then HTTP 200 is returned with {online_users: [{user_id, username, last_seen}]}.room_id, when GET /api/rooms/{room_id}/presence is called, then HTTP 404 is returned with {error: 'room not found'}.Testable Signals: PresenceService, get_online_users
Acceptance Criteria:
room_id, when GET /api/rooms/{room_id}/messages is called, then HTTP 200 is returned with {messages: [{message_id, user_id, content, timestamp}]} ordered by timestamp descending.room_id, when GET /api/rooms/{room_id}/messages is called, then HTTP 404 is returned with {error: 'room not found'}.Testable Signals: MessageRepository, get_room_messages
Acceptance Criteria:
{event: 'new_message', message_id, user_id, content, timestamp} within 200ms.Testable Signals: NotificationService, broadcast_message
Acceptance Criteria:
room_id and keyword, when GET /api/rooms/{room_id}/search is called with {keyword}, then HTTP 200 is returned with {messages: [{message_id, content, timestamp}]} containing the keyword.room_id, when GET /api/rooms/{room_id}/search is called, then HTTP 404 is returned with {error: 'room not found'}.Testable Signals: MessageSearchService, search_messages
Every functional requirement above has two things most chat specs don't: a concrete acceptance criterion written in Given/When/Then format with actual HTTP status codes, WebSocket event structures, and field names, and a testable signal — a specific identifier (class name, function name) that must appear in your source code for the requirement to be considered implemented.
That's what PostIdea's verification engine checks. Not whether your code "looks right." Whether the identifiers the spec requires are actually present in your implementation.
View the architecture decisions →
See how this spec performed against a real implementation →
Want to generate a spec like this for your own idea?
Run your idea through PostIdea →