IT Parable: It's 10 o'clock... do you know where your requirements are?

Joshua and Frank were having a chat over coffee the other day.  Well, Frank was having a chat.  Joshua was mostly listening.

"That guy Alexei is driving me completely nuts!  If he wasn't so darn smart, I'd just ignore him, but I can't. The business loves him.  And he walks around taking pot-shots at all the projects... You can't do it this way!  It won't work for the business!  He didn't write the requirements.  Heck... he works for IT, what right does he have second-guessing the requirements on a system that he's not even part of!"

Joshua just sat quietly.  Frank was a great development lead.  Smart.  Careful.  Methodical.  He'd led many teams to using great techniques for understanding and supporting their code.  His teams delivered working systems on time more often than anyone else... but he had never worked with Alexei before.  That was new.

After a few minutes, Joshua stopped Frank's tirade and asked one question:

"Frank, what does the word "requirement" mean to you?" 

Frank didn't really think about it.  He shot off on another march about how the business must be the source of requirements, not a smart wild-card guy running around the IT department.  Joshua stopped him.

"Frank, what does the word "requirement" mean to you?"

The repetition drove home the fact that Frank hadn't answered the question.

"I guess, it is part of a description of 'what a system needs to do' in order to be successful," Frank finally replied

Joshua looked at Frank for a minute, quiet.  Waiting.  Frank started to think he had said something wrong...

"I mean, it's what the business wants the resulting system to do," he added, a little less certain this time.

Joshua stopped him.  "I think you were more right the first time," he said.  It is not about what one person or a team of people want.  It is about what they need.  Would you agree?"

"Sure!"  Frank had stopped venting.  Now, he was looking curious.

"OK, so what defines "need" in this context.  The business needs a new user interface to their system for managing customer orders.  That's what you are working on, right?  OK.  So they need a new interface, but that's not all they need, is it?  Do they need more than a pretty set of screens?  Do they need it to work?"

"Obviously," Frank replied. 

"So what does it mean, 'to work.' Over the years, various IT systems have come up for handling types of orders and types of customer requests.  Some decisions were good, some were not.  Regardless, we are here.  The logic for deciding what orders would be fulfilled by the ERP system and what orders would be fulfilled by one of the side systems are complex.  Would you agree?"

"Yes.  Of course.  And we already know that.  Tom, on my team, has worked on order fulfillment for three years, so he's been able to provide very valuable insights into how we meet those requirements."  Frank wasn't quite sure where Joshua was going with this.

"I want you to consider Alexei to be a kind of 'additional Tom' who isn't officially on your team, but can offer equally valuable insights into the requirements," Joshua said, and then paused for a second to let Frank absorb it. 

"But Joshua, he's a crazy man.  He drives me nuts.  He says rude things, and says that the code we are writing is terrible.  I can't stand him."  Frank was clearly at the end of his rope.

"Frank," Joshua started, but stopped... not sure what to say exactly.

"Look, Frank, he's got some very rough edges.  This I know, but consider this.  He's worked on nearly every system in this division.  He knows where business rules lie that no one else knows about.  Not even the business.  Don't look shocked.  He's been in this division of IT for over fifteen years.  How many members of the business side have been with the company, let alone the division, for that long?" 

Frank thought about it for a moment.  "No one that I can think of."

Joshua continued. "If you go from a manual system to an automated one, it makes sense to get all of your requirements from the business.  They know them.  And if you go from a simple system that just records things, CRUD style, to a more complex one, the business is still a great place for all of your requirements.  But if you have five mature systems that automate hundreds, or even thousands of finely-tuned business rules, and you want to rewrite one of them, you need to know the rules not only for the current system, but each of the other ones in your space."

"The problem is, no one in the business remembers them.  No one in the business has any idea of how all the rules work together, or how transactions move from place to place.  Alexei knows.  He's been here that long.  He's taken great pains to learn all the rules and he knows them... he really does."  Joshua stopped, finally.  Frank was sitting quietly thinking.

"I went to a meeting with the business, many meetings in fact, where Alexei was in the room," Joshua started up again.

"The Business said, 'We want A, and B, and C' and Alexei replied "No, you don't because if you do C, then these ten things will break" and he'd patiently explain why they'd break, and the business would then ask him what the requirements should be, and Alexei would tell them.  That's where the spec would come from... mostly from Alexei's head."

"It's not enough to say that requirements come from the business, because they come from the business OVER TIME.  Sometimes, it's a long time.  Most of the time, the person who understood a particularly complex requirement on the business side has left or been promoted or taken on some new challenge.  The new person has no CLUE about the complex rule, but Alexei knows.  He's our walking, talking, requirements engine."

Frank stopped him. "But Joshua, if he's ever hit by a bus..."

"We are toast.  We need to get that knowledge out of his head.  But in the mean time, we have to do what we can to ignore his odd behavior and listen to his knowledge of the systems.  If you want your system to actually succeed, you need to run your requirements past Alexei and have him make changes.  Otherwise, you won't have a complete set of requirements.  And things could fail, badly." 

"In a mature environment, requirements have to carry forward.  New requirements have to respect old ones.  And if you don't have a requirements management system where they are all written down, then you need people... people like Alexei." 

Frank sat quietly for a few minutes.  "Maybe I can get him to review the specs, look for flaws."

"I'm sure he'd love to."

Frank and Joshua finished their coffee.  This break was over.

Comments

• Anonymous
  January 25, 2007
  Requirements are not business rules, business rules are not requirements. Business rules do not change as the platform changes, requirements do. Managing business rules should be separate from managing requirements (see http://www.edmblog.com/weblog/2005/11/fix_the_require.html) though they can be gathered using many of the same techniques (http://www.edmblog.com/weblog/2006/11/gathering_requi.html). If you manage use cases, requirements and business rules as separate but interlinked aspects of a design you will do better (see http://www.edmblog.com/weblog/2006/04/book_review_use.html). If you were using a business rules management system to manage your business rules, you WOULD know where they were! JT

• Anonymous
  January 25, 2007
  The comment has been removed

• Anonymous
  January 25, 2007
  Hello JT, In one sense, I agree that rules are not requirements.  An excellent discussion is here http://tynerblain.com/blog/2006/10/18/business-rules-and-requirements On the other hand, once a rule is created in one system, it becomes part of a requirement for another.  In effect, 'play nice with others' depends on who the 'others' are, and that is defined by the rules.  Therefore, for the one that needs to do the playing, the rules in one system may (or may not) become the requirements on its neighbor. Of course, in an excellent design, the rules of one system won't bleed over to another.  Right.  Seen that much?  Me neither.

• Anonymous
  January 26, 2007
  Very nice Nick - that was entertaining!  I'll have to come back here more often.

• Anonymous
  January 27, 2007
  What if the business really need A, B and C? Haven't these new requirements rendered those other things obsolete? Those that will break? I know this is not your point, but aren't requirements, or rules, that no one knows about or understand, in fact obsolete? I don't understand why older req/rules are more important than the new ones.

• Anonymous
  January 28, 2007
  The comment has been removed

• Anonymous
  January 28, 2007
  Good one !!. People like Alexei and Frank exists in every company. Alexei kind of people are gift and risk to company. Gift becoz they can identify gaps much better than any requirement mgmt tool and risk becoz they are still human. Sometimes they make mistakes without any backward track. Way ahead is to capture the vast knowledge of Alexei in some proper mgmt tool. People like Frank are assets to company. They are like people who produces softwares. But they need to understand that there is always pinch of abstraction in requirements which only Alexei's can understand.