I work as a Snr. BA in a large Manufacturing company and I’ve just implemented a new Requirements Management Process.
We have a large range of internal developers who in the past have never been asked to define solution via a Technical Design Document once they have received an approved Requirements documents. They normally just go ahead and code without any written reference of their solution or why it was chosen and any associated risks involved.
Now our release manager states that it should be the BA who writes the solution and Technical Design documents. I disagree as I believe it should come directly from the Developer, especially as there is an easy-to-complete TDD template.
I feel it’s a waste of the BA’s time to repeat and try to interpret a Developers solution and it runs the risk of misinterpreting the Developers solution. BA’s aren’t supposed to be THAT technical! 🙂
In my experience it’s been the Developer / Architect who writes it.
5
Unless the BA is also an technical architect, they should concern themselves with the “what it does” not the “how it does it”. As a result, the BA writes the requirements and the technical architect writes the solution, and the developer writes the code.
Sometimes (or quite often) these roles are shared by someone, so a dev could also be the architect of their own code, or could be an expert in an area writing the Tdd for a junior to develop. Occasionally the BA will also be the TA, but only if they come from a technical and not business background.
Where I work now, we have a technical design authority who takes the basic requirements from the business people and turned them into technical requirements (ie makes them sensible), the senior developers write a solution document saying how they intend to fulfil the requirements which the TDA reviews, then the developers code it all up. The technical requirements are also used by the test team to write their system tests.
1
At my current job, we have BAs who are more technically inclined than where I’ve worked before, but we still have never expected them to write technical design docs. Developers always wrote those, and then architects signed off on them.
In support of xmojmr’s comment, though, I would point out that while we were very diligent about documentation during our waterfall era, we noticed some weaknesses with it:
- Technical documentation was expected to be completed before development began. In reality, the best we could do was document an educated guess at the technical details, and revise it frequently as development progressed.
- Much of what went into the document was boilerplate, and thus had little or no real meaning to anyone.
- The intended audience for the technical document was the developers (anyone who would be maintaining the code down the road). In this regard, it was utterly useless. Someone who needed to fix a problem or tweak some output would find nothing of value in the tech doc. The kind of detail needed by maintainers lives in the code itself. If you try to beef up your tech docs to approach the level of detail present in the code, you’ll not just duplicate effort, but the code and the doc will inevitably fall out of sync (probably before version 1 even ships).
When we switched to an agile workflow, we deliberately ditched technical documents, and nobody misses them. We adhere to the idea of “just enough documentation,” which means if there are decisions that need to be written down, or sticking points that need to be explained, we have a wiki for that kind of thing. Some processes still have formal flow diagrams, because those are useful to the product owner. But shifting focus away from documentation and more toward fulfilling customer needs has made all of the stakeholders happier, and the product is actually more stable than ever.
3
The response to this question is highly dependent on the organization of each company. As mentioned, the ideal is that the technical documents are written by the Software Analyst, after having discussed with the software developers/engineers of the project. However, when there is no Architect in the group, the workload has to be shared. In other words, why don’t you stop considering writing the technical documents as a burden and start considering it as a perfect chance to obtain more technical knowledge ?
In my opinion, you cannot write this document on your own, because you lack significant technical background. However, neither the developer is fully capable of writing a well-structured technical document, since he misses other qualities. Even if the developer is really qualified and can write a perfect technical document, I think he will lose significant amount of time, that can be spent much more efficiently in the implementation phase.
So, I suggest that you write the technical document, after having multiple discussions with the Developer. In this way, there will be 2 benefits :
– You will acquire significant technical knowledge, e.g. around design patterns, protocols etc. This knowledge will be an important asset for your future.
– The project duration will be shorter, since the Developer will have more time for the implementation. And he will also appreciate you more 😉
2