Why Should You Use Requirements Models?

Why should you use requirement models? Isn't it faster to just start listing the functional requirements? In this post I'll explain why you shouldn't do that - and why requirement models are so powerful.

Provide Context
You cannot pick up a list of 500 system shall statements and quickly get a grasp of what the system needs to do. Higher level models, such as System Context Diagrams, Entity Relationship Diagrams, Process Flows, and Organizational Charts are great ways to understand the complete picture. Other models can provide important contextual reference for developers, testers, and others that need to consume the requirements (Use Cases are great for doing this).

Help Derive Requirements
Models can help you generate requirements quicker than you could than without them. Use Cases are a great example of this - once you've generated the series of interactions, it is relatively easy to examine each step and ask the question "what does the system need to do to support this step?" Likewise, you can examine interfaces within a System Context Diagram and start thinking about what requirements are necessary to support them.

Prevent Missing Requirements
Going back to the proverbial list of 500 system shall statements - it is nearly impossible to look at a list like that and determine if anything is missing. There's a post here that describes this in more detail.

Easy to Utilize
Most models are easy to read and use. If you've ever had difficulty getting stakeholders or end users to review your 200-page document (and who doesn't love to read those!?), consider leveraging models to shorten the review time. It's a lot easier for someone to validate requirements while using a Process Flow or Use Case than it is without them.

So avoid the temptation to jump straight into the requirements - your requirements will be more complete, have more context, and will make it easier for others to validate and use your requirements.

A 2-year old can do this

I was driving somewhere with my 2-year old daugther the other day when she started asking me questions. More specifically, she asked me one question, "Why are their no clouds today?" I quickly gave an answer, and (those of you with kids know where I'm going with this) she proceeded to follow up every answer I gave with, "Why?" It forced me to really get to the root of what we were talking about (and recognize the limits of my knowledge of cloud formation. :) However, I also realized that a 2-year old would make a great Business Analyst! One of the fundamental rules of elicitation is to ask "why?" Keep asking "why" to get to the bottom of whatever topic you are discussing with a SME, and you'll almost always find out what the real issue is. In addition, you will gain a deeper understanding of the topic being discussed. So if you ever find yourself at a loss for words when eliciting requirements, just remember to act like a 2-year old.

Know Thy Product

I read a post recently in the Austin Product Managment Yahoo Group stating that Product Managers should not know their products. The author's theory is that PdM's who know their product will not be able to effectively manage their product.

"In a nutshell, the more product knowledge you have, the less product management you're doing because your product knowledge gets you sucked in to a plethora of non product management issues."

I disagree with his underlying premise that product knowledge and product management are incompatible. I think a good product manager does need to know their product, but as important, they need discipline. As it turns out, the author partially agrees with me.

"Product managers need to know their products, but not so well that they mortgage their ability to lead others, influence key decisions and articulate value."

However, he appears to believe that once a PdM has too much product knowledge, the discipline needed to perform the duties listed above is lost. While it may make being a PdM harder, it doesn't make it impossible. In the end, a PdM with strong knowledge of their product and discipline to excute their responsiblities is a winning combination.

Bridging The Gap: Best Practices In Translation For Business Analysts

Requirements analysts often play the role of translator. They listen to, understand, and document the needs of system users in the users’ natural language and they present the users’ needs to system designers and developers in a more formalized ‘language’ made up of models and other artifacts. It is critically important to project success for the analyst to communicate effectively with both audiences.

Most analysts do this without really thinking much about it or examining the process and the best analysts do it quite well. But translation is actually a complex undertaking and it’s worth spending some time on it to understand what is really going on and exploring for ways to improve the process and the results.

Know The Requirements Process

The simple description of the translation process involves just two steps: Decoding the source content and re-encoding the meaning of the content in the target language. A more in-depth look at these two steps reveals some significant complexity. Translating from one ‘natural’ or spoken language to another requires that the translator understand the syntax, grammar, and nuances of both the source and target language. This is a much more involved process than simply taking one word at a time from the source and finding the equivalent word in the target.

For requirements analysts the task has a further challenge in that the target must be precise and rigorous while the source will usually contain vague and indistinct literary constructs that are normal in the everyday use of a spoken or written natural language.

Know The Language Of Your Target Audience

I could not find any research on translation specific to the work of requirements analysts, but there is a fair amount of evidence that deep knowledge of the target language is more important for a translator’s success than expert level fluency in the source language. The research suggests that while perhaps coding experience is not necessary, it is important for RAs to have extensive knowledge of the models used in requirements specification and this knowledge should be from the perspective of the consumers of the specification, designers, developers, testers, etc.

Research and best practices from the translation business also suggest that the draft translation should be reviewed by a second translator with deep knowledge of the source language.

Many software requirements analysts do have a background in software design and development but many come from other disciplines as well.

The ideal situation may be for the requirements specification to be first drafted by an analyst with deep knowledge and background in software design and development and then reviewed by an analyst with deep knowledge and background in the business. Not every project team will have access to the ideal mix of analysts but if your project does it may be worth a try.

Good Faith

Let’s say you take your car in to have it worked on and you get a $1000 estimate and are told you have to leave it for 2 days to get the repairs. It turns out that once the repair shop opens up the engine, they find out the cost is an extra $500 and it will take another day. Here are two possible responses:

• Repair Shop A. The repair shop calls as soon as they find this out and lets the customer make an informed decision about how to proceed or abandon the work.



• Repair Shop B. The customer shows up at the end of day 2 to pick up his car, and he’s told his car is not ready, sorry, and, by the way, you’ll owe an extra $500 when we are done. Or, you can take it today, but it won’t work right. Regardless, you owe use $1000.

As a customer, I’d readily consider going back to Repair Shop A. They made a mistake in the estimate, but they kept me informed and gave me options. I’d feel they acted in good faith.

On the other hand, Repair Shop B would never see me (or my friends) again. I’d feel they were unprofessional and acted in bad faith.

Yet, I see this happen in development all of the time. There are situations where the development team has control of the schedule: their estimates are accepted and scope is controlled to allow development to complete in their estimated time frame. The development team does not report any problems or schedule issues during development. However, when the software reaches code complete and is turned over to the quality assurance team for testing, it is a frightening mixture of buggy and undeveloped features.

Why don’t developers understand they are acting like Repair Shop B? That they are acting in bad faith when they do this, and that their credibility is damaged? Again, the problem is not that they made a mistake in the estimate; it is how they handled it.

I wish I had a solution to this. I realize situations like this are usually complex and perhaps loaded with baggage. Right now, I’m hoping that my analogy will help developers understand the consequences of such actions are not only to the product they are producing, but also to how others view their credibility. Act in good faith.