Business Analysts and NFRs

I posted this to the Linked In group The Business Analyst Forum

In answer to the question “What words of wisdom would the community have to ensure that analysts reliably identify and accurately describe all relevant NFRs?” I posted

Business analysts are not usually equipped to identify and describe NFRs. That is because NFRs are mostly about how the system works, rather than what the system does, as seen by the business.

NFRs are much more closely connected to the technology and can have huge cost implications. If you take availability, business continuity and disaster recovery as a group, of NFRs, then the cost of business hours availability and a two day DR/BC objective is much, much less than that of 99.99% availability and a two hour DR/BC objective.

Functional requirements are relatively simple. You ask the users what they want the system to do, write the answers down and get the code to reflect these requirements. I know, it’s not quite a simple as that. As a minimum you also need to work out error and exception processing, but it is relatively straight forward and linear.

However, when it comes to NFRs, working out their consequences, the technology needed to deliver them and the costs of delivering, operating and maintaining the resultant systems is not easy and requires a deep technical understanding, an understanding most BAs probably don’t have.

My advice to BAs is: identify the person who is/will be responsible for the infrastructure architecture and work with them. If you can’t find such a person, then your project will probably face some major problems down the track when you come to implement it and put it into production.

This is a link to the discussion:

Leave a Reply