Business vs Functional Requirements: I don't care.

Either I’m getting very lazy or I’ve reached a new point of sophistication in my BA practice because I really don’t care that much about the difference between business and functional requirements anymore. Maybe I’m just sick of the fact that it’s almost a point of pride for people to have their own definition.

Not to mention that fact that half of the time the “business” requirements aren’t from the business they’re from customers or regulators, and that “functional requirement” documents include non-functional things like service-levels and look and feel.

Half the time I don't even consciously differentiate between business and functional requirements. I just elicit a bunch of requirements, get the business to sign off to confirm that it looks like we have a shared understanding, and then specify a solution separately.

For me that's the big separation between classes of documents that BA produce

* Elicited Requirements: Documents conversations and consensus with stakeholders, embodies a shared understanding of situation, with the BA's role being mainly a drawing out from stakeholders.

Elicited requirements could be business, functional, stakeholder, objectives, KPIs, NFRs, show tunes, user stories, wire-frames, or just whatever works best for all stakeholders to communicate.

This is a big mess of "business" and "functional" requirements.

* Specified Solution: Documents a single concrete solution that addresses the situation embodied in the elicitation stage, with the BA's role being to design a solution based on the elicited requirements.

In this model I end up collecting mostly "functional" requirements.

I grant this represents my background working as a system integrator. In a fixed-price environment you really want to manage scope by keeping all that vague text in the elicited requirements separate from the model.

This has always worked well for me, with the following provisos:

* Traceability between elicited reqs and the eventual solution is key. You need to show where you took into account all the things your stakeholders said.

* You still need to understand the difference between business and functional requirements on some level so you know where you can implement something differently from the user request (And note it is such in your traceability)

* I’d never talk like this to someone just starting out as a BA. I think when you’re starting out you need to be much pretty dogmatic about the difference between stakeholders expressed needs, and their underlying objectives to avoid becoming an over-paid stenographer.

Customer Needs, not Functionallity

My Lamy ink pot is so well designed that every time I refill my cheapy $30 fountain pen I get a real sense of satisfaction, because everything just works.

I can feel that they've actually though about:

how a customer will use their product,

the acions they'll take immediatly before and afterwards, and

what place the product has in the customers life.

An inkpot is a fairly simple thing at it's heart. You just need ink in a well sealed container, lamy obvioulsy have great ink, and athe container closes tightly but it's a few little additions that make me willing to pay the %20 price premium over their competitors.



Lamy's have added two main feautres:

An integrated dispenser for plastic backed tissue paper around the base of the ink pot

A little reservoir in the bottom of the pot so that it's easy to get your pen or bladder all the way into the ink, even when you're down to the last of the ink.

So; from a BA point of view what have Lamy done that is so applicable to software design?

Firstly - they didn't think about themselves as providing a function (Ink, Email, holding customer records) instead they saw themselves as supporting an activity (Refilling a pen, communication, communicating with customers). By looking at a wider business-process context they were able to better integrate multiple functional components into something useful to the end user.

From a BA POV they took a wide process, and collapsed distincy activities together by providing a single interface that matches what the customer wanted to acheive. This is putting the customer's needs first, and the functionallity later.

Secondly - they looked at the whole lifecycle of usage. They introduced features that covered the whole product lifecycle, giving the customer unexpected bonuses towards the end of their product use; which usefully for a retail product is just when they're about to re-order.

But what's really great is that there's a synergy between the two, that little reservoir on the bottom is what paper dispenser clips to. There's also ongoing revenue from selling paper refills.

The only thing it's really missing is a way to easily open it when the ink has dried the list shut, maybe if base coudl be made square'ish you could get a grip more easily?