I'm NOT Going to Read Your Requirements

Ever get the impression that your stakeholders simply aren't going to read the requirements documents you create? Better yet, have you ever had a stakeholder actually tell you directly that he or she just isn't going to read the requirements? I haven't, but I wish someone would. That sort of direct, honest communication would be a shock, but sometimes that's exactly what we need to shake ourselves out of familiar, yet unproductive, patterns of behavior.

In a recent post, Joyce explained the importance of context in our work. Her post was about providing context for both your current and future audiences. But what if those audiences can't or won't use the documents? Even if you provide context for your requirements like Joyce suggests, if you don't deliver your requirements to your stakeholders in a way they can or will use (in other words, provide them in the context of their use) then you've completely missed the boat.

Unfortunately, many times we don't find out that stakeholders can't or won't use the documented requirements until it's too late -- the system has been built, it doesn't meet the requirements, but it's too late to change anything and still meet the delivery date. When pushed to explain WHY the system doesn't meet the requirements, the stakeholders explain that they thought something was included in the requirements but it wasn't, or the development team explains that they couldn't understand the requirements so they just built what they thought was right, or the test team explains that they were unfamiliar with the format of the requirements so they tested against the existing system instead. Sound familiar?

It would be great if your stakeholders told you up front that they wouldn't use your documentation. That way, you'd have a chance to talk with them about what kinds of documentation they could or would use. You could discuss all of the options for capturing, documenting and managing requirements, and then you could choose the right set together. You could pick the right tools for the context of their use. If only those darn stakeholders would just be straight with you up front, right?

Let's be honest -- it's our job to know that requirements reviews and use are challenges in software development, and more importantly it's our job to find ways to make the process work. Talk with your stakeholders about past projects and requirements efforts. Find out what their context is for the work you're doing. And then use your expertise to come up with and use new approaches and tools that make this project better than the last for everyone involved.

What Problems Are You Spending Your Time Solving?

One of the things I find interesting is the news pundits who ask the question “If a woman is elected president, what will her husband be called?” To me, the answer is completely obvious. If the wife of a president is a “First Lady,” then the husband of a president is the “First Gentleman”. Question answered, move on to discussing a real problem.

I just asked this question to a group, and none of them came up with “First Gentleman”. When I stated it, the responses were that it made sense, but… “It isn’t snazzy enough”, “It doesn’t fit in today’s catch-phrase world” and “We’ll probably invent a new term and change the term for the First Lady as well.” All this in spite of the fact that “First Lady” has worked just fine for over 200 years.

This is very analogous to some of the problems we have in software development today. We spend our time solving fake problems instead of real ones. We look for the snazzy, catch-phrase, new solution. So much time and effort is spent on finding the “best possible solution,” when with the current state of software, most users would be pleasantly surprised by a reliable, adequate solution.

Think about it next time you’re solving a problem—is it a real problem?

Dr. Changelove (or how I learned to quit worrying and love change)

I was in a meeting recently in which some great ideas were presented. The ideas would result in a number of improvements which would benefit the company and the users, and they were all pretty easy to implement. However, the ideas weren't product features ... they were changes to behavior. While I wholeheartedly agreed with what was being proposed, I didn't LIKE the ideas because they meant that I'd have to change.

I'm a creature of habit. I get into a routine and like to stay there. So, even though I could see the benefits these changes would bring, I felt myself digging my heels in to argue against the ideas. My reaction was emotional, not rational ... but it was also typical. I could feel myself resisting the changes even while I thought they were the right thing to do. Based on that recognition of the benefits to the changes (along with the obvious frustration my boss was feeling with my comments), I knew that I needed to find a way to embrace the ideas. But how?

I realized that I knew the "what" of the situation, but not the "why". It was easy to understand what the changes were and how they would be helpful. What I didn't know was why we needed to make a change. I didn't understand the background, the context, or the situation that had led to the need for the change. So I asked. And, as is most often the case, there was a good reason for the changes. They HAD been well thought out, and they WERE good solutions to the problem. And once I understood the need, my attitude changed.

I talked with my boss about my reaction after the meeting. She suggested a great way to understand my reaction. She said that I was the developer, and the presenter was the Requirements Engineer. I understood what was being asked for, but I didn't understand why. The RE didn't set the context, and I didn't ask for it (at first). The RE knew why the ideas he presented were good ones (they met the business objectives), but I didn't. It was only after I knew the business objectives and how the requirements supported them that I felt good about the changes. I also felt like a part of the team which was solving the overall problem, not just an interchangeable resource performing a task.

Remember that any change, whether it's to an existing system or to someone's behavior, is difficult. Use your RE skills and experience to help yourself and others accept and support changes by providing them with the right information. When you do, you'll make the change easier and more effective for everyone involved ... and you may even come to love change, too!

How Do You Make Requirements Processes Environmentally Green - Part 2

On yesterday's post, I covered how we can reduce the use of paper in requirements practices. Today I’m going to look at how we might reduce the travel as well.

Reduce travel

The second area for improvement is in reducing the necessity of travel. With the globalization of the industry, there is significant travel around the world, for teams to meet to elicit requirements. In large companies, there is even quite a bit of site-to-site travel within the same city.

Remote Tools

In order to reduce our travel (local or long distance), we need better tools for working remotely with teams. Video conference can work, as long as it’s a reasonable cost and internet bandwidths are sufficient. The technology needs to be seamless (i.e. easy to use, no delays). There need to be whiteboard solutions that make it possible for remote teams to see the same work on the board as the people in the room.

Videos

There is a time difference issue when teams are globally distributed. Currently, teams often document requirements separately and email the thoughts back and forth. They might send documents to share or emails with questions and comments. One suggestion would be to use videos to capture each team’s ideas to share back and forth. The body language and tone would not be lost as it is in text. Obviously this has to be very easy to use technology, or text will win out. Ideally some sort of voice recognition would minimize having to speak and type the thoughts.

Team rooms

For the teams in the same room, having a team room environment can work well. For some period of time, people could sit in the same building and the same room and get a lot of work done together. This would include main stakeholders, subject matter experts, requirements analysts and even the development team. The company can avoid shifting permanent desks around by just temporarily locating them to this environment. They will have more opportunities to whiteboard solutions. They could keep lots of diagrams and other thought up on the walls without having to print them to look at. It would also minimize the need for video conferencing if they were to relocate for a period of time.

Today’s take-away thought:What are your current successes and issues with video conferencing solutions you have tried? Post your comments here.

It would seem that there are many opportunities that the requirements work we do could can be less environmentally impactful. However, I think much work has to be done on software and hardware tools for users to adopt such solutions.

How Do You Make Requirements Processes Environmentally Green - Part 1

Subtitle: It’s not easy being green

The theme for IEEE’s RE08 conference is “Requirements engineering for a sustainable world”. The obvious topics that relate to this theme are about how we gather requirements for projects that are targeted at being “green”. However, I decided to look at the problem from a different viewpoint. I was curious about how we can reduce our impact on the environment when eliciting, documenting and reviewing requirements.

The two areas that jumped out at me were:

1. Reduce the amount of paper we use
2. Reduce the amount of travel we do, particularly on airplanes

Today’s post focuses on the paper reduction and my next post will cover the travel aspects.

Reduce Paper

The first suggestion for greener requirements processes is to reduce the use of paper. It has been my experience that people print more “stuff” for requirements activities than for most other parts of the software development process. My initial thought is that we print so much because we need to see things next to each other that do not fit nicely on a screen. For example, we like to quickly flip between pages of text, look at large diagrams of a system, and draw on documents. A document is inherently linear in its organization. If requirements relate to multiple sections of the document, it’s hard to switch between non-adjacent sections. And, for whatever reason, it’s easier to read some things on paper than on a screen. A few immediate solutions come to mind around software and hardware tools.

Requirements Tools

A well-designed requirements tool that is widely adopted in an organization (over using Word and Excel) would reduce a lot of the need to print requirements documents. Ideally, a requirements management tool would manage text requirements and associated diagrams and allow you to link objects at any level, quickly and intuitively. Unfortunately, the requirements tools offered to date are not solving this problem well.

Bigger Viewing Areas

I recently increased the size of the monitor on my home computer. It’s amazing how useful the increased size is for working on large volumes of information, simply because I can view more items at once. Potentially, we could use larger LCD monitors in our primary working spaces. This would require less flipping around within documents and reduce the urge to print everything out.

Portable solutions

I sometimes see people print documents to bring to meetings to read once or share with others. The first obvious solution to this problem is to ensure the people creating requirements have laptops. Secondly, we need projectors to easily share information with others. I’d like to see a projection option built into a laptop so we can avoid lugging projectors around. Imagine you could run to someone’s desk and just project onto their wall without any setup. A final suggestion here is to use tablet PCs. I have no personal experience with them but, if they allowed us to easily sketch diagrams, move things around on the screen quickly, and jot notes on existing documents, tablets could be easier to use than the current common solutions (and require less paper of course!).

Reusable resources

When there is no option other than hand-writing and drawing things, we should use whiteboards as much as possible (ideally scanning ones that can capture your work electronically). We could also use sticky flip-chart paper that is reusable like a whiteboard. Heck, maybe even use reusable whiteboard-style sticky notes!

Disclaimer: There are some obvious assumptions here around the technologies being more energy efficient than the resources used in paper waste.

Take-away question: Notice every time you print something in the next week. Why did you need to print it? Post your realizations here.

Practical Tips for Conducting Requirements Audits

In a previous post I discussed the value of conducting requirements audits. I'd like to give some (hopefully) practical experience on how to conduct audits.

Define Standards/Guidelines
If your organization doesn't already have standards for what makes a good requirements artifact, then you need to start here first. This doesn't have to be a big effort to define, and there's plenty of material out on the web and in books if you need some help (here's a post to get you started).

Use Checklists
Once you have your guidelines, make sure you use them during your audit. Running an audit should be like using a recipe - everything you need should be in one place. You should decide if you are going to review all portions of deliverables, or just do a sampling of each. You should also list all of the quality standards that your reviewers should assess the deliverables against. Put these in a checklist form with yes/no or a scale marked on the page - this makes it easy for the reviewer to document their findings.

Assign Ownership in Advance
An important consideration in implementing audits is that they don't happen by themselves - you have to plan for them. If your organization is large enough, you may have QA or Compliance staff that can conduct the audits for you. If not, you need to find someone that can perform the audits. Identify who will conduct the audits and also when before the project starts.

Training
Conducting audits is not a natural skill - most people will need some kind of training. At a minimum, hold a session where you explain why audits are important and how they will help the organization and individuals, roles and responsibilities, and the use of checklists. It's great if you can give good and bad examples for each of the standards.

Use the Results!
Most importantly, don't forget to use the results. Review past findings at the start of a project so your team doesn't wind up repeating previous mistakes.

Positive Random Reinforcement

As requirements consultants we sometimes find ourselves working with people who have learned through painful experience that requirements are not fun. We like to think the process we use is actually pretty interesting and engaging but it is not uncommon for us to start a new project and find people who are dreading the thought of being involved in requirements sessions because of bad experiences they’ve had in the past. This is a challenge for us of course because to be effective we really need people enthused and actively involved in the process.

We’ve had a lot of discussion lately about how to deal with this type of situation and this led me to thinking and reading about incentive systems based on positive random reinforcement. My thinking is that we need to find ways to encourage people to actively participate in the requirements process and we need to do this in ways that promote the kinds of behaviors we are looking for but also make the experience a very positive one. Research has shown that one of the most powerful ways to incent behavior is through positive random reinforcement. This means repetition of the desired behavior is rewarded but the rewards vary in frequency and strength.

One interesting way to accomplish positive random reinforcement is to reward behavior with opportunities to play a game of chance. This can be done simply by handing out tokens when people do the things you want them to do. (In our case, actively participating in the requirements process in some positive way.) Each token gives the recipient an opportunity to play a game of chance. Almost any game of chance would probably work but some would be better suited for our purposes than others. There should be a relatively high probability, but not too high, of winning a small reward and a relatively low probability of winning a large reward. How large is large will depend on your audience and your budget, but it should be enough to be meaningful. The game should be fun of course and should be simple and quick. There are many to choose from.

Incentives work better if they are more immediate so recognize people right away for doing the right things. Handing out lots of tokens for small things gives people lots of opportunities to do the right things and to get more chances to win the big rewards. The rewards need to be things people actually care about so think carefully about what the prizes should be. One of the easiest prizes to arrange may be a re-loadable gift card or debit card that people can spend as they wish.

I haven’t had a chance to try this yet in the real world but it sounds like an intriguing idea. I’d love to hear from anyone who has had any experience with using games of chance to provide positive random reinforcement.

Too Briggs for Your Breeches? Personality Type and Requirements.

Is there a “type” that is more suited to requirements elicitation and documentation? A survey of our experience identified four useful personality roles that have direct application to the requirements gathering process: Openers, Closers, Handlers, and Hunters.

Jung at Heart
Personality typing rubrics seems to be a surprisingly touchy subject for a neutral “instrument” (the word “test” is deemed judgmental). I notice the Wikipedia article on Myers-Briggs actually had sections discussing personality attributes labeled as having disputed neutrality. What do people think is the best personality type that is a better fit for requirements elicitation and documentation? Should teams be a phalanx of a certain type like the Spartans? Or perhaps more like a salad of different personalities, like the A-Team? Or are personality types just a lot of bunkum?

Openers, Closers, Handlers, Hunters
Our team identified a few roughly defined types that may help build a team that addresses many of the common needs of a requirement gathering project:

Openers (XNXP)
Generally speaking, NP’s (iNtuitive Perceivers) abstract visionary skills are ideal for project kick-offs and “getting” the big idea quickly.
Strengths: Openers give a strong positive first impression for the whole team with their quick-draw, right-on analysis.
Weaknesses: Openers don’t always follow through on… ooh, look a bird!

Closers (XSXJ)
On the other end, SJ’s (Sensing Judgers) obsession for detail and resolution are ideal for making sure the big idea gets realized and the scope of the project is achieved.
Strengths: Give them a ship and a star (ok, and maybe a map and sextant) and they’ll not leave the wheel till the project gets fully into port.
Weaknesses: Uncharted waters make closers seasick. First the details, please!

Handlers (ESXJ)
A Handler’s action-oriented detail-driven style can be a perfect complement for working with those quirky, high-production subject matter experts—the Architects (aka the INTP’s). The Handler makes sure the Architect’s time isn’t wasted.
Strengths: ESXJ can put the Architect’s mind at ease, knowing that their vision will be heard and fastidiously recorded.
Weaknesses: If the Architect isn’t secure in their role as Super SME, they may feel bullied and not protected by their handler.

Hunters (INXJ)
A Hunter’s single-minded zeal to systematically arrive at a solution make these types are ideal for elicitation and documentation, especially when there are missing pieces. They can work their relationships to stalk problems.
Strengths: They can sniff out the answers when no one else can.
Weaknesses: Not always comfortable in the spotlight.

Requirements Sci-Fi

Science fiction authors have had a huge impact on the development of science and technology. The flip-phone and PDA were inspired by Star Trek. Submarines were inspired by 20,000 Leagues Under the Sea. I thought the requirements space could use some similar visionary input (not that I'm on par with any of those sci-fi legends). I hope you think this is fun.

---

Some time in the not-too-distant future...

I walk into my requirements gathering meeting and boot up the room. It takes 15 seconds to warm up - this old hunk of junk is getting on my nerves. Before long, the walls light up with the familiar Windows VistaXP SP5 logo. I refuse to upgrade to Panorama.

People's avatars start filtering into the room. Bob is running late (as usual), but his Personal Assistant Program is here to fill in until he arrives. I don't really mind. Bob's PAP usually makes more interesting conversation anyway…

"Okay, our new sales portal is launching at the end of the week. We need to figure out what this thing is supposed to do in the next 45 minutes so the codeMonkey programs can create our prototype by this afternoon's meeting," I say.

"Well, let's make sure we get the users involved this time. We don't want a drastic reduction in traffic like we had with the last release," says Mary.

I had heard about the last release and its abysmal traffic and I was determined to get the requirements right this time. After all, my career chip said I was supposed to be a Business Analyst, I should be good at this stuff.

I pull up our User Profile program and open a few representative personality downloads. Single Mom, Busy Professional, and Corporate Purchaser all pop into existence, ready for the interview.

"Okay, if you wanted to buy a new personal transportation device, what would you look for first?" I ask.

The walls of the meeting room light up with images, half-formed thoughts, and desires pulled straight from the personality programs' database. I reach out and grab a few pictures and save them for later.

"What would you do next?"

Again, a flurry of still images, video, and text flash all around. I pull the next set of images from each user into one corner of the room.

This goes on for several minutes until I have a complete set of thoughts from each of the users in the room. Now for the fun part.

"Okay everyone, I want to craft a User Experience Model from all of the requirements we just elicited here. Please feel free to chime in with any suggestions as I go along," I say.

I look through the different impressions pulled from each user. Their personal goals, needs, and wishes are all laid out in front of me. I think back to the corporate goals and pull those into the mix as well. I try on different formats, flows, and presentations, quickly scanning for the set that fits as many goals as possible. Before long, I have the features, functions, and behaviors that the systems needs to satisfy everyone.

I play back the User Experience Model I just created for all of the stakeholders and users. Everything flows smoothly, no problems, no concerns.

"Looks good. Let's start building it." says Mary.

"Okay everyone, I'll see you at the prototype walkthrough at 4. Thanks for coming," I say.

Three keys to success in Agile Modeling

For Agile development teams, there are three key modeling concepts that are critical for successful requirements modeling.


First, create model artifacts “just in time” and make them “just good enough”. Creating model artifacts just in time means not trying to produce detailed models too far in advance of when they are needed or when the decisions about the details cannot yet realistically be made. Making models just good enough means not wasting time building models that are more elaborate than needed for the task at hand. Of course, what is “just good enough” depends on the situation and knowing when your models are good enough is critical. A model that is “a little better than necessary” would be far better than a model that is “not quite good enough”.


Second, create model artifacts in an iterative and incremental manner. This goes hand in hand with creating the models just in time and making them just good enough. Each iteration will add depth and breadth to the models. As the scope of each iteration or release is defined it will become clear which parts of the model should be elaborated for that iteration or release. Rather than trying to build a completely detailed model all in one attempt, a more realistic way to construct a complex model is to use progressive elaboration over a series of iterations.


Third, create and manage model artifacts in a way that anticipates change. White boards, flip charts, and note cards are all useful modeling tools and it would be hard for many of us to imagine working without them. They are easy to use and can help us move modeling efforts forward quickly and without a lot of overhead. Unfortunately, they lack the persistence and maintainability we need for progressive elaboration. We need our models in a modeling tool but how we use the tool can have a big impact on our results. Whatever tool you use, think about how you will change and maintain the model as new information becomes available.


There are lots of little details that go into making good models but for the most part they fall into one of these three categories. Focus on these three concepts and your agile modeling efforts will be headed for success.

The Santa Approach to Requirements Gathering - part 2

Story continued from yesterday...

Systems

Now, as anyone knows, if you are going to develop new toys, it is very important that you understand which other toys the new toys will need to interact with. For example, if a kid has a Lego set, you cannot just buy Duplo’s and expect them to work together. The elves therefore must spend a bit of time peeping around to really understand what toys each kid still has and uses, which toys need upgraded with new features and which ones are legacy and need replaced. For the ones they know they must integrate with, they take some detailed notes around compatibility issues.

Functional Requirements

Once the elves have narrowed down the scope, determined who the kids are, how well they have behaved and what toys they must integrate with, they must take on the most important step. They must determine what the children actually want! The elves are pretty tricky about how they elicit these requirements. They rarely actually interview the children directly. Certainly they talk with the parents a little, but we all know that talking to “management” doesn’t necessarily get us to the right requirements. Sometimes they will do surveys via commercial-watching monitoring. However, the elves’ preferred method is to use passive observations of the children going about their daily lives. They hear the kids talking to friends about the latest toys, see the dreams at night of cool games and watch catches the kids’ eyes in toy stores. And to clear something up - when Santa visits the kids at the malls at Santa-fiscal-year-end, you might think he’s still requirements gathering – but that’s really the elves’ last chance to validate the lists of requirements they gathered.

Development through Release

Throughout the year, as the elves gather new requirements for the children in their regions, they immediately enter them into ReqPole, their requirements management tool of choice. That way the elf teams still up at the North Pole can start developing and testing toys very early in the year. This is the only way they could possibly get them all done in time for a December 25 release.

And so, when December 24 arrives, the sleigh is loaded and Santa heads out with his star reindeer to deliver the toys around the world. After the elves watch the sleigh launch, they immediately go nestle up in their beds to rest up for a solid day. Because they all know, on December 26, they start the cycle all over again.

And whether you like the Santa Approach to Requirements Gathering or not, you have to give it to them, they ALWAYS deliver on time!

The Santa Approach to Requirements Gathering

‘Twas the day after Christmas and all through the world, everyone was enjoying their Christmas surprises. Everyone except the North Pole’s favorite elves. These little elves had just helped deliver gifts to homes all over the world, but it was already time to start planning for next year’s surprises! And so the little elves begin their requirements gathering for next year’s holiday toys.

Scope
To kick-off next year’s project, the elves gather for a scoping meeting in the North Pole (except those that are based at the South Pole, they typically conference call in). Santa facilitates the effort to elicit the year’s gifting objectives. They debate the big scope decisions – do they think the kids will take a liking to electronic gifts (can they really top the Wii again so soon?) or maybe an outdoors focus (can they innovate a next generation of roller-blades?). This is a big decision to make because all the elfs’ requirements activities for the next year will focus around this decision. Once they have their scope defined, the elves set out to elicit requirements using a favorite approach of looking at the People, Systems and Data.

People
Once they have gifting objectives to define their scope, the elves have to divide up their work for the year. First, they draw the global org-chart in the snow. They find that it works best if teams of elves own regions of the world. For example, a team of about 30 elves could easily own the southwest part of the US. Within the regions, they break the org-chart down to cities, neighborhoods, houses, gender and finally into “good” or “needs improvement” children. This was all based on the prior year’s data of course, since we all know it’s really hard to keep an org-chart up to date. But once they get to work on their region, they can make updates to the chart pretty easily. And so, with their org charts completed, each elf team heads out to start their requirements analysis for the children in their chart.

Data
The elves find that after focusing on “who” they needed to build toys for, they need to look at the data involved in this project….the often-dreaded “Behavior Records”. We all know they are out there. We all know Santa knows what’s in them. And to the elves, they are the foundation of the requirements work. The elves have to quickly get to work to analyze the existing data records, interview SMEs to understand where they may be out of date, and update the records to guide their year. And of course, they have to create new records for any new children!

Tune in tomorrow to find out how the elves uses Systems, gather their functional requirements and hit their deadline!