Design v Requirements, part 1

I am working on the Great American Novel (joke. Does anybody still think in those terms, BTW?) And I use Scrivener, not Microsoft Word. Scrivener seems much more attuned to the process of writing. Which is a lot messier and more chaotic than Word hints at. But Scrivener is not perfect and I was thinking about how I would improve on it. I would keep all that it has already, in the form that it has it. Just add a feature here, a feature there. But this thought process led off onto issues for business analysis–which is always there in the back of my mind.

Two things: in programming it is often difficult to just add features to an existing software system. In this case because I don’t have the source code and can’t just glue new stuff onto the existing code. Another situation is where the existing system is so incredibly old (like in COBOL and CICS) your programmers won’t touch it and tell you it has to be rewritten from the ground up. Well, recreating all the old stuff is very difficult and expensive. For me, it isn’t worth it. Better to adapt myself to what Scrivener offers. And bend Scrivener to my evil intentions. 

Second, I got to thinking that if we were in this beginning systems analysis class and I told the students to write the requirements for a ‘word processor’ I could expect them to write the requirements for Word. Not because Word is the last word in word processors but because what we are used to is the foundation for what we desire. (What was the line in Silence of the Lambs? “We covet what we see…every day”?) We have to be careful about this constriction of vision when we practice business analysis.

More on both thoughts next time…