When writing the title of this post I started to sing “How low can you go…How low can you go?” I told you that so I am not the only one with that song stuck in my head.
On to the blog post. Yesterday, I had a meeting with the technical lead for the project I am working on. We were reviewing some of the initial requirements I had elicited and we started discussing technical design considerations. He asked if I would be documenting some of the technical design details. My initial plan did not have me going that far, but I said I could and would if necessary. In the end, it was agreed he was the most qualified to document the technical requirements for the project.
Now I have a few questions. How technical do you go? Does your current role require you to work on the detail technical requirements for a project. If asked, could you go technical? Do you feel it is best for the business analyst to go technical?
Whether you do or don’t go technical, I feel it is critical for the business analyst to be part of the design sessions to ensure the business needs are being met through the designed solution.
Please share your thoughts. Thanks
12 Comments
Interesting question. I guess there are all varieties of business analysts writing low/high level documents.
For me, the interesting question is, who is best to write a tech documentation?
I have been writing technical documents, and I have written more or less low specifications.
But, what I experienced, being to far into technical details makes me biased, being in danger of losing the business focus and being distracted by technical constraints.
Rather, it is the task of the software architect to find a solution for the business requirements and – if necessary, e. g. due to financial constraints – discuss it with the business analyst to find the best compromise.
On the other hand, I have always found it handy to be able to talk technical language. This enabled me to communicate more efficiently with developers and I also got their acceptance more easily.
I often experienced software architects or developers being reluctant to document things. Often it helped to offer my help – methodically or even writing some of the stuff – better than not having it documented.
Short answer – I would stop at business processes and user goals. I would follow that up with a conversation with the designer on the various options availalble and be actively involved in the decicion, but not the documentation.
Of course there are always exceptions.
“Technical requirements” and “technical design” don’t mean the same to me, Kupe.
For “technical requirements” I read “system requirements”. For “technical design” I read “system design”. To me, the former means: “What I need the system to do” whereas the latter means: “How the system will go about achieving what you need it to do”.
As an analyst, I do not document the latter at all, since it belongs to the solution domain. Moreover, I try to word the requirements as clearly and concisely as possible while allowing the designers maximum latitude.
However, I agree that the BA should be involved in the design sessions on a consultative basis, as long as the BA can understand the design concepts being discussed.
In recent years I have worked a lot with Pegasystems’ PRPC, an excellent BPM / Rules Engine tool. I have been involved with this tool as a developer, team manager and business analyst. Although my involvement has mostly been as an analyst my development experience gives me insight which another analyst might not have.
As a result, when analysing system requirements I am able to advise the customer as to the kind of features the tool can give them “out of the box”, so that they don’t spend time and money re-inventing the wheel. I also like to have someone with more PRPC design experience in the analysis sessions who can help me give such advice.
However, where an “out of the box” component does not exist to satisfy the business need, the language of the requirements refers to the problem domain only and not the solution domain.
Kind regards,
Declan
It all depends on the nature of the requirements. I work for a COTS vendor so most of my requirements documents are customizations to the COTS product.
Most customizations are written from the user’s viewpoint. i.e. Which screens are modified is the primary driver. This format is easiest for communicating with the client and is a good way to separate “what” needs to happen from “how”. The developers then write a Technical Design Document based on my requirements.
In some cases we are modifying tables in the database or are providing new back-end functionality. These documents are typically more technical.
I would almost ask a BA, “How Technical Do you want to Go?”
Although the perception of a BA role is to bridge the GAP, but I believe BAs do /should have a boundary in their role. My mantra is let the “Experts” take care of their jobs.
Depending on the willingness, skills, experience, SME,etc…a BA can choose to be more on the technical side or sway more on the business side during his/her project lifecycle. In my experience, BAs traditionally ,over their entire career, seek to move away from Technology and more towards Business.
As Declan mentioned, BAs should be involved in Design phase. Bas can validate the Tech Specs against Requirements.
Also agree with Andreas, that it is the Software Architect’s role to find a solution. But BAs can add value to their role by being “solution enablers”.
I am always excited to learn more about the Business, their To-Be state, strategy,etc… but at the same time High Level Architecture diagrams, Logical Data Designs(ERD) interest me as well. But any thing more detailed than these documents are a strict no-no for me personally, since I am not the expert.
Thanks everyone for the great comments. I feel it is always best to have the experts in each task take the lead. But, just because you are a BA does not mean there are other things you don’t do, just because of your title. Like Jinesh the technical side is not my passion.
Hello all,
I agree with Jinesh: “Depending on the willingness, skills, experience, SME,etc…a BA can choose to be more on the technical side or sway more on the business side during his/her project lifecycle”.
In my company tthis question depends on the roles defined for a project.
In the past, we used to have a business analyst (BA), a solution analyst (SA) and a development team working on each project. The BA was doing the enterprise analysis, writting the business requirements, the business rules and user requirements as use cases. This was the input for the solution analyst who has the functionnal expertize and writtes the functionnal and non-functionnal requirements. Then the development team take over and writte the design requirements as well as technical seq diagrams… as they know best the implementation.
Now my company has decided to merge the roles BA and SA. Both roles will train each other on their expertize. In the end the BA will be writting BRs as well as functionnal requirements.
May be we can spend sometime to define what does technical means because what is technical for a BA is often functionnal for a developper.
Cedric,
You are right on when it comes functional vs technical and technical for a BA is functional for a developer. Last week I had this conversation with a developer on a data integration project I am on.
Check out this discussion on LinkedIn that dipped into this topic. http://tinyurl.com/m6s49l
Thanks Kupe, for the reference, I am excited to read it.
I can’t actually have access to it as I am not a member of that linkedin group. Please let me know which group is it?
It’s the IIBA group. This link should work. http://www.linkedin.com/groups?gid=92583
What would be a good resource for learning how to write “generic” test scripts?
Tom,
We have some potential resources for you at our site, http://www.b2ttraining.com/downloads/ . Select the Requirements Validation Template download. There are a number of templates for creating test cases, plans, etc.
Let me know if this helps. Thanks,
Kupe