Architecting with Requirements - A story from my past.

I love Software Architecture.

The essence of Software Architecture is to distill the requirements to the system. Often a developer think that a requirement is absolute: "Our software must do this. To the letter." However, when you dig a little deeper, most requirements are quite flexible. Remember that a requirement comes from a customer, and very often ends up being written by the customer based on his interpretation of your system.

Vivo, a Brazilian operator, had a set of requirements for Nokia that specified how the UI of their mobile phone should look and behave when in idle. For Nokia, these requirements were very hard to implement as written, years or man-hours work. The requirements were sent to Nokia in form of a large document. The document was interpreted by a Customer Representative that 'understood' Vivo's requirements. He entered them into a database where various teams could comment and respond to them. Eventually, they reached a Project Manager that decided to implement them, after which point they went to a Software Lead, who made sure his team got them and coded them.

By the time a developer got these requirements, it was too late. Un-winding the history was impossible, and frequently Nokia spent insane amounts of time not only managing this, but trying to figure out what Vivo really meant in the first place.

As one of my tasks while working as the Chief Software Architect for Nokia (CDMA products), I was sent to Vivo to discuss these requirements. The development teams were stuck, the work was overwhelming, the product would be delayed.

I met with Vivo's lead UI/Marketing person, Raquel, who was responsible for writing the original requirements. As we started discussing, I began asking questions along the lines of "So why do you want this? What is your purpose of asking for that?" Each time Raquel would answer honestly, describing what Vivo was hopnig to ultimately achieve with the feature (Drive revenue, make it easier for users to find and buy content, etc). When we came to the requirements that were hard for us to do, I suggested alternative ways of doing them. Often just a little tweak, but enough that Nokia could easily implement it, instead of making major changes. And Raquel accepted. She was thrilled that we could do it all of a sudden. The phone could be done on time.

In this scenario, what were the essential issues?

1. The requirements were written with pre-conceived knowledge of our UI
2. The requirements lost their original context when processed through Nokia's DB
3. The core reason for each requirement was 'lost in translation'.

My point is... As a Software Architect, sometimes your main purpose is to understand WHY requirements are what they are. Use that to suggest alternative solutions that still fullfill the need, and always... always ask for purpose!