Thursday, July 9, 2009

Technical details in a requirements document

The thought of writing about how much technical information should contain in a BRD (Business Requirements Document) came to me yesterday when I was working on a requirements for a new feature for our product.

I come from a technical background, but not all business analysts comes from programming or technical background, I feel both categories of BA have advantages and disadvantages, especially when you are working for a software company.

Let me stick to the topic and focus on BA with technical background, I feel when you start the requirements document it should be entirely based on business outcome and you should not think about the solution or any other technical details, this ensures that your document covers all the business needs and is not compromised by technical limitations.

If your company promotes and allows JAD (Joint Application Development), then you will have to talk to the technical team, I found it very handy if you are able to talk the technical language, but getting too much technical could risk the business focus. On the other hand based on my experience technical team are a bit reluctant to document technical details in that case documenting technical information can be very handy (QA team will thank you for that).

Personally I would rather focus on defining requirements clearly and free from ambiguity then worry about technical details, but BA needs to understand the design concept, in past I have experimented with semi technical document by adding Workflows, UI, Data Modelling and sometime ERD diagrams, that has worked in some cases some and some cases it did not, you will have to use your judgement as to how far you need to go on the technical side, it may also depend upon your audience, too much technical details makes it difficult for a business user to review,understand and verify the requirements.

There is also some overlapping between functional and technical, what is technical to BA is functional to the development team, BA usually have to write functional and non functional requirements so sometime there is no way out but to write technical details.

So in short depending on the willingness, skills and experience, BAs can choose to be more on the technical side or stay focused on the business side, a balance of both side is what I will recommend.

No comments:

Post a Comment