I agree with Bruce here. Unless you actually want to take such a project as an opportunity to learn lex/yacc/bison... then it's not just overkill, but also a huge waste of time IMHO.
Now if OTOH, you master those tools, and are actually less inclined to write a parser yourself, then why not.
But, in any case, it also depends on what exactly you want to implement. Of course a disassembler alone (which was the original topic) doesn't require any kind of parser. (Or you may reply that it does, but it's such a simple "parser" of binary data that it wouldn't make sense to use a classic parser for this.)
For an assembler, you'll need a parser, and then its complexity will largely depend on what you really want to support in your assembler. Merely translating assembly code is easy. But now if you want to support complex expressions - needed for defining constants, for instance, or for implementing some kind of macro-assembler, then it becomes a bit more complex. It's not ultra difficult, certainly, but if you've never implemented that before, it will probably be much harder to get right than you initially thought.
Now you'd have alternatives for this, of course: you can implement a very basic assembler with a very simple parser, and then support constants and macros using an existing preprocessor to preprocess the input assembly code. Flexible enough. The parsing itself for a simple assembler would then be a matter of a few hours of work, even if you've never done it before. Just my 2 cents.