DTA’s – Developers-Turned-Analysts
I was a developer (by title) for 15 years before I got my first position as an Analyst. I was warned that being an Analyst meant that I didn't have to program and that I had to change my mindset from the technical side to the business side. I thought this would be an easy transition, however, it proved to be anything but. My first Detailed Functional Requirements (DFR) document was full of technical jargon and implementation language. Another analyst pulled me aside and gave me the same advice I recently had to give a new developer-turned-analyst, heretofore known as DTA's. The DTA asked me to review his first DFR and to give him some advice.
To be fair his document was more technical in nature than your typical DFR because it was detailing a process that involved more than one program on more than one platform. I decided to use the document as a teaching tool for him by also giving him a copy of Ivy Hooks "Writing Good Requirements" article from 1993. I then tied in the recommendations that I made to him to that document as much as possible.
Abstracting from Technical to Business Level
When I first started writing requirements I did the same thing, including technical info instead of abstracting to a higher more ‘business’ language level. The thing to remember is that this document (and all ‘Requirements’ documents) is a ‘contract’ between the business and the developer. If we put in our ‘contract’ that a developer utilize COBOL (for instance) then the developer’s hands are tied and he must use COBOL. That is why we tend not to use implementation language in requirements. This gives the developer the freedom to use whatever he wants (COBOL, Java, etc).
Thinking in terms of Testing
Another thing to keep in mind as an Analyst is that testers will be reviewing our requirements to determine if the program is meeting the ‘terms of the contract’ so to speak. So the requirements also have to be testable. When I think about whether a requirement I wrote is testable, I think, ‘Yes or No’. This means can the result of this requirement results in a ‘Yes, it worked’ or ‘No, it didn’t work’ answer. Some of the suggestions I made in the document will help drive this home. I then reworded some of his requirements to make them testable. For example, he had a requirement that stated: “Set and export a variable called ORACLE_HOME.” I suggested the following: It might be easier to specify what the value of the variable is, rather than its name. Also, with this being a requirement, you are telling the programmer that he has to name the variable ‘ORACLE_HOME’. Remember, requirements are like a contract between the business and the developer. Ask yourself, what does ‘ORACLE_HOME’ contain? Then I suggested that he try saying something like “The system shall set the environment name”.
The advice was well-received and my manager asked that I save it to our team drive for other new analysts to refer to. Transitioning from Developer to Analyst can be difficult. It is not just giving up the coding part of your job, it is having to think at a less technical level and still conveying your message, not always an easy job.