When I was first working in IT, I was used to coding from a specification. I was so busy struggling with Cobol, JCL and DL/1 - yes, I'm that old! - that I didn't stop to think about where these specs came from.
A couple of years later I was working for VSEL amending some programs (as we called them in those days) and having been told what we needed to do, we'd look at the existing code and the database and work out what to do, often coding as we went.
It was only on my first contract that I began to see a better way of doing things. There were some people on the development team who didn't write code but whose job was to write these specification documents that I remembered from my first job. We all sat in one open plan office and each developer worked with one systems analyst.
I found this tremendously interesting, especially as I began to get a say in how the programmes might work, and over the course of my next couple of contracts I made the transition from developer to systems analyst.
At this point, you might well be saying to yourself "this is all very well but what's a systems analyst?"
Good question.
The business analyst collects the business requirements. So, for example, a new system might track books in and out of a library and each card holder is allowed to have three books at any one time for up to a fortnight. That's a nice simple piece of business analysis.
The systems analyst, though, has to design the system, the database and the logic. It's the systems analyst who will typically find the gaps in the business analyst's documentation, sending them scurrying to the client with questions like "but what happens when the card holder has had a book for a fortnight?"
It is this final specification that the developer will code from and, whilst the developer has some leeway in exactly what they build, it is that specification written by the systems analyst that determines what will be tested. The programme should do what the specification says and no more.
Of course, this additional step appears to be very time-consuming and it is but, as is so often the case when a company does things properly, it pays dividends. The approach that simply sets the developer coding with a bunch of requirements often means that the developer will get halfway through before realising that he needs to go back and change something he's already written. It means that the client isn't suddenly presented with quite fundamental questions during the build process, which may be a little unnerving. And, in a constructive way, it presents a contract between the analyst and developer, who have agreed what is being built. If the requirements change and the spec needs amending, the developer can very reasonably ask for more time.
Furthermore, the specification forms an excellent basis for system testing, as it details precisely what the system is supposed to do.
As a business, Meantime prides itself on delivering on time, on budget and to specification. The systems analyst's role is key in helping us to keep this promise to our clients.
