2 of 2 people found this helpful
traditionally, conditions were used in SRDs to connect different tiers of questions -- upper tier's question's type were limited to radio buttons, check boxes, or static menus. In your case, you'd define question Server Type as Menu, Static and populate list of Displayed Values and Stored Values with pairs of (Database Server, 1); (Web Server, 2); (Application Server, 3); (File Server, 4) (numbers can, of course be replaced with appropriate text), then attach four conditions to that question (one for each defined Displayed Value/Stored Value pair) and add one instance of next four questions (Development, Quality Assurance, UAT, Production) to each conditional branch, so you'd end up with 1 question and 4 conditions in 1st tier and 4 instances * 4 questions in 2nd tier. Just imagine how many questions and conditions you'd have to use if you really had to deal with multiple tiers! Not to mention that you'll probably use gathered values in fulfillment mappings, and that means mapping all instances of all questions, or adding intertwined actions to ensure correct mapping.
Have you considered using one menu and four numeric questions without any conditions? From your sketch, columns two to five are functionally identical for all choices, so it's much quicker and simpler to construct SRD this way, and the only difference from submitter's perspective is visual -- in this case, all questions are visible all the time.