Sequence Detector forced to wait a specific number of bits
You have two possible inputs -- a "0" or a "1". What happens when one of those is entered? 

It seems like you need to maintain TWO counters, one with how many digits have been entered, and one with how many of them are "1". 

There are shortcuts you can take to minimize the number of states. For example, if you've already got two "1"s or three "0"s, there's no longer a need to maintain the counter with the number of "1"s. Also, history of the sequence doesn't count in your example case; e.g., if you have reached one "1" after two inputs, you don't care if the history that got you there was "01" or "10", so you don't need to maintain a state for each.

Generalizing these things involves truth tables, Karnaugh maps, and tedium. I don't think you really need to do that. In your sequence, you have 2^4 possible combinations of inputs. Brute force will thus bring you to 16 states you can end up in, plus a starting state, plus 2+4+8 intermediate states. Truth tables will show you some duplicate states, so you can reduce. 

I've drawn up something real quick.  The left to right columns are the number of inputs entered, and the down to up rows basically correspond to how many ones have been entered.  I've labeled the states with how many "1" have been entered so far, and you can see where I've reduced duplicate states, as those states are labeled with \$&lt;\$ or \$\geq\$ signs, or have more than one input path to them.  You can also see that the arrows with two numbers show that success or failure (given you reach four inputs) has already been determined.  Note that I did not include the final step of returning to the starting state.