A requirements model is a detailed, clear, and well-structured description of an upcoming product’s properties and capabilities. It gives developers a feature reference and creates an agreement with the customer. Building one means investigating information from customers, experts, documentation, examples, and other available sources, then resolving unclear or contradictory facts. section 2.1.4
Organize requirements systematically with complementary investigation techniques:
- Questions and answers clarify the software’s purpose, domain terms, expected functionality, and architectural expectations, though the results may lack a convenient structure. section 2.1.4
- Use case diagrams show what actors can do with a subsystem inside a logical boundary. section 2.1.4
- Mind maps support domain analysis with diagrams, lists, notes, external links, and embedded media; user scenarios provide another way to investigate product requirements. section 2.3
Clarifying a multiplayer application
Instead of assuming what the customer means, ask targeted questions: “Should the Minecraft application support multiplayer?”—“It’s the central idea.” Then clarify the architecture: “Should it be a classic client-server architecture or a distributed nodes network?”—“Classic client-server architecture would be enough.” section 2.1.4
Figure 2.9 Use case diagram for the main menu of Minecraft
A use case diagram makes subsystem boundaries and actor actions visible, complementing conversational requirements discovery. section 2.1.4
