Gaining Perspective on Your Requirements

When working with large, distributed teams, requirements can often get lost in translation (sometimes literally). There is no way to prevent this completely, but there is a technique you can use to help reduce your risk in this area - perspective.

If the development team was directly plugged in to the product manager's brain, you would end up with the ideal solution every time. Unfortunately (or fortunately!), developers aren't plugged in to the product manager's brain. There are often large barriers, both physical and mental, that can prevent the team from understanding exactly what to build. This is especially true if the product manager uses a single method to communicate the solution. In this case, the team can interpret the requirements in several different ways. This doesn't happen due to a problem with the information in the requirements, it's simply due to the lack of alternate perspectives.

Think about the image to the right. Nothing in the photo is faked. All of the information it contains is accurate. The issue is that you only have one view of the situation. If you looked at this image from another perspective, you would have a much better understanding of what is actually being portrayed.

Let's think about how this applies to software requirements. To get the most accurate picture possible, you need to present several different views of the solution that are different enough to provide alternate perspectives. This will drastically reduce the probability that something will be misinterpreted. You can do this by creating more than one model of each problem. The more the better.

Of course, some of the models will contain redundant information. There is also a risk that the models will not overlap enough to provide an alternate view of the same context. Time is also a factor, so you can't make an infinite number of models. Generally speaking, 2-4 different views is sufficient.

One example of using this technique would be to create use cases, wireframes, and click-action-response tables for the same user interface. Each one of the models is useful by itself, but may leave the solution up to misinterpretation. When all three are used in concert, a much clearer picture of the requirements emerges.

Making large projects more agile

We are on a large project for a client (>100 developers) and one of the issues that keeps coming up is how can we reduce the cycle time.

At one point in the project we were using a waterfall model, all the requirements had to be done and approved before the requirements could be handed off to the development team (3rd party company). The development team would then look at the requirements and write functional specifications and design documents. Sometimes we would need to make changes to the requirements, but they were locked so we weren't allowed to. Unfortunately we were also not allowed to attend the functional spec reviews because we were directed to begin on the requirements for the next phase. One of the impacts of this process was that even if the requirements were effectively done, we weren't allowed to give them to the development team. If stakeholders took any time at all, we could lose a week or more on every document. Another impact is that the requirements process was at least 3 releases ahead of the developers. By the time development got to the requirements almost everything had changed based upon the outcomes of the prior release. Frankly it was a bit crazy.

Fast forward a year and now we have a much better process in place. Each topic area has it's own parallel development path. Once the requirements are complete for the topic the topic can move to the next phase. Now delays in one topic don't impact any other topics. This has helped to reduce our cycle time significantly. We would like to push the lifecycle to be more agile to reduce planning time and to improve the end user satisfaction of the software. One of the things we are contemplating changing now is how much overlap we can have with the functional specifications and the requirements efforts. If we can get the developers involved earlier we think we can get much higher fidelity on the requirements as the developers have a lot of good input plus we can reduce the elapsed time by overlapping requirements and functional spec phases.

There are a number challenges to doing this though, first, the 3rd party development team has around 100 developers, but not enough senior designers (I would call them architects) - it seems like there are around 5. What this means is that they are maxed out and they simply cannot afford to be in meetings unless the requirements are very firmed up. They also aren't willing to invest any time into functional specs that may be based on changing requirements. Second, the project is so big that the 5 designers can't keep every topic in their head. This means they must have requirements documents that describe the decisions that we all agreed to in a lot of detail with a lot of pictures (low-english speaking developers). Third, everytime we get developers into a meeting with users all they want to talk about is messaging between system layers and feasiblity of various designs. The users frankly are completely baffled and tend to tune out. Our job has been to keep them on track, but you know how developers are sometimes. Fourth, the developers sometimes badger the users into accepting less functionality by constantly focusing on what is possible instead of what the users need. Finally, there is a bit of an antagonistic relationship between the vendor and the client. This is expressed as the requirements being viewed as a contract. Therefore the vendor is not willing to work on anything unless it is in writing and approved by the client.

Despite these challenges the project is moving along quite well. We are probably on our 6th release in 1.5 years and we have come a long way since we started with a very immature development lifecycle. The client and vendor teams are both not software companies but really want to define the process themselves. We have been working diligently with them and things get better every release. This release we are going to experiment with giving the developers draft copies of the requirements documents and having the developers participate in some of the later requirements sessions. I'll let you know how it goes as we get more agile on this relatively large development project.

Why Bother?

Why even bother? When's the last time you asked yourself that? Was it something trivial -- "Oh, I forgot to get canned lentils on aisle 6, but I'll be back in the store tomorrow, so why bother to go back and get them now?" Or was it something more meaningful, like, "Nobody ever reviews my process flow diagrams for this project, so why bother to spend any real effort on them?" Hopefully the majority of your "why bothers" are trivial, but I'd expect there's a more serious one every now and then.

My personal favorite "why bother" is around making the bed. I've had this argument with every person I've lived with for decades now, from my mom and dad, to my college roommate, to my wife. For the longest time, I simply couldn't see the point to making the bed! I go to sleep at night, get up in the morning, and then will go to sleep at night again ... so why do I need to make the sheets neat and tidy for a few hours in between? Their answers, invariably, were "because it's the right thing to do," and I simply didn't buy it. It wasn't until I saw a more personally meaningful benefit that I believed in the importance of making the bed.

So what does my opinion on making the bed have to do with requirements? Well, probably not much ... but hopefully it'll provide a good parallel with a common frustration on requirements projects. It's easy to get caught up in the day-to-day challenges (aka frustrations) of software development efforts, and when you're caught that way, it's easy to have those challenges carry over into your perspective on your own work. At home, you may feel like you're already doing too much housework and making the bed is just one more chore you're too tired to do. At work, you may feel like your deliverables don't matter, or like there's nothing you can do to have a positive impact on the project, or like ... well ... why bother?

If you've been involved with requirements engineering for a while now, this may sound like an all-too-familiar scenario. I know that I've found myself feeling this way more often than I'd like over the years. What I've discovered, though, is that these "why bother" moments are opportunities for me to learn and, more importantly, make a positive impact on my project.

Chances are that if you're feeling frustrated, others on the project are too. If you can recognize the challenge, you can use your requirements role to help shake the entire project out of its slump. Play games in your next requirements workshop. Bring cookies to a document review "just because you think everybody deserves a cookie." Open a meeting by saying that you don't see any reason to keep creating requirements and see what the reaction is (OK, maybe this one isn't the BEST idea!). By shaking yourself out of the "why bother" mindset, you make a difference to the other people on your project, and hopefully you can also see how your work makes a difference to those people and the overall project itself.

One simple change of perspective can impact countless numbers of people - and that's why we bother.

(Editorial Note: I now DO make the bed, and I do it because it's important to my wife, it's what I want my son to learn to do, AND it's the right thing to do!)

*Special Guest Contributor*

Featured Article

Data, Data Everywhere

As a requirements guppy, I focused on the user experience when developing requirements - when were messages displayed, what options were available, what were all of the things they could do? I was a hard-core use case junkie. Use cases seemed so simple to conceive and so simple to write. I loved meetings with users where we deconstructed what they did. I loved thinking of all the different scenarios, all the different paths to achieve their goals.

And then I had my first requirements review with the technical team. They had a lot of annoying questions – questions I hadn’t expected. In fact, I didn’t expect questions at all. What I expected was them to look admiringly at me and say, “How did you think of all this great functionality? This is going to be the best software EVER. I can’t wait to start coding all these fantastic options.” Instead I got this:

“How many characters can they enter for person name?”

“What are the valid values for a numeric result?”

“What if the ordering tech changes the person’s age – wouldn’t that affect the valid numeric values available when they enter results?”

“What if a user is entering results for a person, and they don’t have security to see all of the person’s demographics? What will be displayed instead?”

And the hits just kept on coming. I stared blankly and stammered. I felt like I was drowning in all the data details I had missed. All the flows to meet the user’s goals would mean nothing if the information wasn’t handled or displayed accurately. The next day I tried to figure out what I had done wrong.

1. I hadn’t specified the functional details of the information the user was viewing and entering.

2. I hadn’t handled the exceptions. What does the system do if information is modified, is entered incorrectly, or is missing?

3. I had expected the technical team to not only value, but compliment my requirements.

I developed a method for helping me think of everything related to the functional details of data and help me catch the exceptions. I even have been complimented on my data requirements. No, really, it happened once.

So, for your consideration, I present my Data Digging Questions (DDQs for the acronym-lovers):

1. What information needs to be displayed to the user?

a. Where does the information come from?

b. Does the information need to be filtered?

c. When is the information displayed? What if the information changes during a user action and that changes what the user can do?

d. In what format is the information displayed? What if the details don’t match the display format? Are there user, system, or regional preferences for how that information is displayed?

e. What should happen if the user doesn’t have security to see part or all of the information displayed?

2. What information needs to be captured from the user?

a. Is the information required or optional?

b. Does the information need to be unique? Does it need to be unique for the record or the system?

c. In what format is the information entered? Does the user need to be able to flex the entry format? What coded values are available? How are the coded values organized? Can the user select more than one value?

d. How is the information validated? What information needs to be validated immediately, and what information can be validated later? Does an entered value need to be within a certain range? Are all characters valid? What is the minimum number of characters that need to be supported?

As I transition from a requirements guppy to shark, these have served me well. If nothing else, they get my thoughts going so that I can make the data flow like, well, water.

POSTED BY: Ginger Nedblake

That's a Completely Useless Answer!

Have you ever asked someone a question, only to have him/her respond with, "Well, it depends..."? It can be extremely frustrating, especially when all you want is a simple, direct answer. For example, if I'm looking for directions to a restaurant and someone tells me that it depends on whether I want to take the most quick, the most direct, or the most scenic route, I probably don't mind the clarifying question. If, on the other hand, that person just says, "It depends" and stops talking, then a very annoyed look will probably appear on my face.

But the answer to many questions DOES depend on additional information that the asker doesn't provide. I may know that my car is low on gas, or that the dinner reservation is in 10 minutes, or that I just rented a convertible and want to drive around with the top down, any of which would allow someone to suggest an applicable route to dinner. But because those things are an integral part of my world that I don't consciously consider when phrasing the question, they're probably not on the tip of my tongue when I'm posing my question.

As a result, what often happens is that the person asking the question gets either a non-response ("It depends...") or an inappropriate response given my specific (but unstated) objective. The answer is either annoying or just plain wrong for the situation -- and in either case, the person who asked it probably thinks "That's a completely useless answer!" Unfortunately, if you ask enough vague questions, people stop answering them, and if you answer enough questions inappropriately or with only "it depends," people stop asking you for answers. Neither of those situations is good for someone in the requirements business!

In earlier posts, both Joyce and I extolled the virtues of context, and this is another great example of the importance of that kind of additional information. When you're meeting with stakeholders to gather requirements, explain the context for your involvement with the project and the questions you're asking. When you're answering requirements questions, don't just stop with "It depends" -- tell them what it depends upon and what some possible answers are for each situation. You'll build credibility with your team, establish a reputation as a reliable source of information, and (perhaps most importantly) not be the cause of that annoyed look on anyone's face!

Requirements Management Task List

Found this oldie but goodie in a file named - Requirements Management Task List. While not exactly what I would put together today, it still holds a lot of value for what it asserts (and doesn't). Enjoy.

Requirements Management Task List

1. Agree on a common vocabulary for the project.

2. Develop a vision of the system that describes the problem to be solved by the system, as well as its primary features.

3. Elicit stakeholders needs in at least five important areas: functionality, usability, reliability, performance, and supportability.

4. Determine what requirement types to use.

5. Select attributes and values for each requirement type.

6.Choose the formats in which requirements are described.

7. Identify team members who will author, contribute to, or simply view one or more types of requirements.

8. Decide what traceability is needed.

9. Establish a procedure to propose, review, and resolve changes to requirements.

10. Develop a mechanism to track requirement history.

11. Create progress and status reports for team members and management.

The Glossary--Project Litmus

The Project Glossary defines terms/acronyms relevant to the project.

You all probably know that.

What may be news to some of you is that it singlehandedly provides a valuable and telling insight into the overall health of your project.

Here's how.

Our project roles are primarily about communicating and ensuring common understanding of what is communicated. I have not been involved in a single project that did not have its own argot and tangle of acronyms.

When there has been a concerted effort by the entire team to define and understand these terms/acronyms it is an indication that this project team has made an investment in at least one task/artifact that will contribute signifcantly to the goal of clarity of project communication. And I believe the converse is also true, namely, that a project that fails to invest time in defining the terminology that is elemental to the project communication sets a dangerous precedent for sloppiness and imprecision of its communication.

Rescuing Knowledge from Ivory Towers

We had an email discussion in the office the other day about the term "Requirements Engineering" and I began thinking about most of the research I have read on the subject over the past 6-8 months. The vast majority of RE research is not being used by anyone in the 'real world' today.

But why? Most companies recognize requirements are important and many product managers are looking for a 'recipie' for their software project to make it a success. RE doesn't promise that recipie, but it does offer some interesting tools that would certainly help.

The answer is that this knowledge is not accessible to those that need it. Much of the research falls into two broad categories that limit its usefulness to product managers and business analysts in a business environment. First, there is research that is incredibly specific to one application. I have read articles about how to create requirements around the timing circuit of an embedded control. While interesting, these articles are of little use to most people who gather requirements. Second, there is research that is too theoretical. It may be stimulating to imagine creative ways of modeling complex patterns, but much of this research is not grounded in reality.

It is important to find the middle ground and build a knowledge base of practical tools and techniques for requirements analysis that can be used on a wide variety of projects. Use cases are a great example of this kind of tool.

Why Do I Do the Things I Do?

I’ve been around software development for quite a while and have trained others in many different activities. Here is one of the most important questions I’ve learned to ask myself when telling someone how to do something: Am I telling them “my way” or “the way”?

Sometimes what I am telling someone is simply “my way” of doing things. In these cases, it is important to convey the true goal of the task, and that my way is simply one way to meet the goal. Other approaches are fine, as long as the goal is met. While I like to think that “my way” is the best way, the truth of the matter is that frequently “my way” is tailored to my particular strengths and weaknesses, and might not work for another person at all.

On the other hand, sometimes I am telling someone “the way” to do something. This really is a best practice, only way to meet a policy, or maybe even a legal requirement. In these cases, it is important to convey the importance of following the method presented.

There’s one other benefit of asking myself this question: sometimes when I realize the approach I am using for doing something is simply “my way,” I find a better way of doing it or the person I’m teaching suggests one.

Here are some examples:

• “My Way.” I often get into a situation where I am going to create a new document by editing a copy of an existing document. When in this situation, the first thing I do is open the existing document in my editor and perform a “save as” to a new name for the new document. The need here is to not overwrite the existing document with the edits. Knowing that along with all of my wonderful strengths, I am also absent-minded, I save the file under a new name first, so that I won’t absent-mindedly save my edits to the existing file. People who are not absent-minded like me don’t need a procedure that guards against this problem. They know they will rename before they save (I don’t really know how they accomplish this, but I’ve seen them—they do!).


• “The Way.” The general rule of defect reporting is one defect per defect record. The purpose is clear resolution of defects. Each defect is typically prioritized, fixed, and re-tested. Some are resubmitted because they fail re-test. Some have even more states they go through. If there are multiple defects in a record, tracking and determining the prioritizations and states of the defects becomes time consuming and confusing. It is much easier to have priority and status fields which apply to the defect record. Thus, the best practice is one defect per defect record.

TED Talk on the Need for Simple Products

One recent Saturday morning I got sucked into watching neat things on TED. If you haven't seen it, go look now!

I found one that was very relevant to product management called When it comes to tech, Simplicity Sells. Oh, and it's realy fun to watch or listen to! It’s about how simple technology really should be – with lots of the common examples we’ve all seen from Microsoft vs Apple. That said, in its basic form, it is a good reminder to product managers since we are creating software with lots of features - stop cramming features in and build something that works.

There are some neat products highlighted in here, like the voice recognition software that seems to work pretty well. That's got great potential for those of us in a field that spend a lot of time typing!

P.S. If you like math, this one is fun: http://www.ted.com/index.php/talks/view/id/199

Analyze like a Quantum Physicist

People are often intimidated by the word 'quantum'. It has a whole set of connotations behind it that make people afraid they're going to get in way over their heads. In truth, quantum mechanics isn't all that hard to understand, it just isn't very useful in everyday life. Some of the methods used to analyze quantum mechanical systems, however, have analogues in the world of requirements analysis.

The first thing to understand about quantum mechanics (QM) is that you can't fully understand anything about a quantum mechanical system. One of the postulates of QM is that you can't ever know a particle's total momentum. You can get close, but never pin it down 100%.

The second thing to know about QM is that real systems are incredibly complicated. There is no theoretical reason you can't describe every atom in the universe with an equation, it's just that those equations would be mind-bogglingly complex.

How do scientists get around these problems? They use a model that simplifies things in order to gain a better understanding of the system. They also use different types of models to examine different aspects of a system. Through iterative refinements on these models, they learn gain valuable insights into the system without ever knowing everything about it.

The classic model professors use to describe a quantum mechanical system is known as the 'particle in a box'. By thinking of an electron as a particle in a one-dimensional box, scientists were able to realize that it can only exist in discrete (quantized) energy states. This model is an extreme simplification of the behavior of an electron on an atom, but it still provided early scientists with key insights into the nature of the universe.

How does all of this relate to requirements analysis?

Software systems are nowhere near as complex as quantum mechanical systems, but they can still be quite hard to comprehend. In fact, it may not be possible for one person to fully understand every moving piece of a large enterprise-level system. It can also be hard to nail down everything there is to know about individual pieces of a system.

Models in requirements, as in QM, can help solve these problems. Let's look at the first one - systems can be very complex and hard to comprehend. Use of a model allows you to pare down your analysis to the parts that are important to you right now. You can use a model to focus on user interface, performance, usage, or any number of other system properties. The important thing to remember here is that the model is only showing one aspect of the system. You need several different models to fully understand what is going on. Furthermore, if you make any single model too complex, you lose the benefit of modeling the system in the first place.

Second, models can allow you to analyze every detail of portions of the system. In this case, you aren't interested in abstracting detail but rather exploring all the detail you can get. Models help here as well. Having a framework around requirements allows you to iteratively refine the picture, look for gaps and vague areas, and continually improve your picture. Without the model, you wouldn't know where you needed to improve.

At first, the connection between the world of quantum mechanics and requirements may seem like a bit of a stretch, but the concept of using a model to analyze a system is universally applicable. Next time you start requirements analysis for a complex system, remember that the abstraction, simplification, and structure that models provide can make even the most complex systems easy to understand.

The Secret to Making Sure a Task Won’t Get Completed

You attend a meeting, identify a task that needs to get done, and end the meeting with “We need to accomplish X.” And… nothing gets done. Why?

Identifying a task is the first step. But, assigning ownership of the task is critical to actually seeing it performed. In today’s world of multi-tasking over-allocated people, the old adage “When it’s everybody’s job, it’s nobody’s job” is truer than ever.

Want a task done? Assign it to someone. Simple, I know, but frequently forgotten.

Models. And Cake!

The other day I overheard someone say that all they needed to write code was the list of functional requirements--that they didn't need the accompanying use case (that we were producing as part of our reqs methodology for the project).

Well, here's a list of requirements (ingredients): sugar, flour, salt, butter, cocoa, baking soda, buttermilk, eggs, vanilla, powdered sugar, milk, and pecans.

Go bake me a cake.

Seems pretty obvious that the "order of things" is pretty important in this case. In fact, to not have the order of steps to take (and to follow them) means failure. (Full cake instructions below.)

Here is another set of requirements (muscle groups): triceps, abs, legs, chest, biceps, back, shoulders.

Go work out.

Order is also important here (although less so since each of these exercises is independent), but if I said that it is recommended that you work out large muscle groups before smaller ones, and that you should design your regime around working opposing muscle groups on the same day, you'd want to know this information.

A use case might not be the best model for defining a work out routine, but I recommend some model to help you extract the full set of requirments for the functionality.

A model is like alcohol--it gets people talking about stuff they wouldn't otherwise talk about under normal circumstances. "Under the influence" of a model, you are going to find more information--some of it extraneous, but some of it valuable and necessary.

Chocolate Sheet Cake


Combine in a mixing bowl:

2 cups flour
2 cups sugar
1/4 teaspoon salt

In a saucepan, melt:
2 sticks butter
Add 4 heaping tablespoons cocoa.

Stir together.

Add 1 cup boiling water, allow mixture to boil for 30 seconds, then turn off heat.

Pour over flour mixture, and stir lightly to cool.
In measuring cup, pour 1/2 cup buttermilk.

Add:
2 beaten eggs
1 teaspoon baking soda
1 teaspoon vanilla

Stir buttermilk mixture into butter/chocolate mixture.

Pour into sheet cake pan and bake at 350-degrees for 20 minutes.
While cake is baking, make icing:

Chop 1/2 cup pecans finely (optional).

Melt 1 3/4 sticks butter in a saucepan.

Add 4 heaping tablespoons cocoa, stir to combine, then turn off heat.

Add:
6 tablespoons milk
1 teaspoon vanilla
1 lb minus 1/2 cup powdered sugar

Stir together.

Add pecans, stir together, and pour over warm cake.

Is your software a project or a product?

One of the most common mistakes made by software development teams and others in thinking about software is the confusion between the concept of software as a project and the concept of software as a product.

When asked, most people would agree that software is a product, not a project. After all, the software will exist long after the project comes to an end so it is obviously something fundamentally different.

However, since most of the work we do on software is done by project teams, it is easy to fall into the habit of talking and thinking about the software in project terms. This can cause a variety of bad results, from confusion to outright project or product failure.

A project is a temporary endeavor that produces a unique result. Projects have start dates and end dates. Projects have life cycles. The words people use to describe the phases and artifacts of a project life cycle vary but all projects have some version of a project charter, an initial or start up phase, one or more intermediate phases, and a closing phase. A project has scope and constraints of time and resources. A successful project produces its intended result, a result that meets the needs and expectations of the project stakeholders within the time and resource constraints.

A product is the unique result of a project. A product also has a lifecycle. A product has scope, requirements, and constraints and we can measure product quality, in part, by assessing whether the product functions as intended.

We use many of the same words to describe projects and products: lifecycle, scope, constraints, quality, etc. For software development project teams the result is often confusion. Are we talking about project scope or product scope, project lifecycle or product lifecycle? It is a good idea to be clear about which you are talking about or working on.

The project and the product are obviously tightly linked and can’t realistically be considered completely in isolation. We should however avoid comingling and confusing the project and product lifecycle, scope, requirements, quality, etc.