5 Big CaliberRM Gotchas And How To Fix Them Part 2

In my last post, I covered three different CaliberRM issues that we've found with CaliberRM. In this one, I'll be covering five more.

Individual Object Delete

If you paste into CaliberRM and it doesn’t look right, it will be extremely difficult to delete it because you can’t highlight and select the delete key. You have to select each individual object and then right click and select delete. Trust me this is hard. The easiest solution is to cancel the save operation and it will revert back to the original state. CTRL-Z also does not work.

Tables From Word Are Too Big

Sometimes if you paste tables from Word they get messed up with one table going off to the right off the edge of the screen. In this case cancel the edit and then paste each table individually.

Caliber Shows Wrong Names

Sometimes caliber will show the wrong names in the tree structure as you click around. Don’t worry about it is just a screen defect.

Adding Files Only Adds A Reference

Do not use your local system as a reference. The best thing is to link to a UNC in SharePoint or other document management system. This isn’t as easy as you would think. With SharePoint, you need to view your file share in an explorer window. Navigate to the correct place. Paste the directory into the reference dialog box, then right click on the file select rename, copy the name, then paste the name into the dialog box. If you lose the link to the file i.e. kill vpn to SharePoint, CaliberRM will show the link as unknown. But once you restore the VPN connection it will be able to find the file if you try to double click it.

Adding Web Links Doesn’t Work

Adding web links seems to not work at all. You click the button and it just creates a blank link.

What workarounds, tips or tricks have you found in CaliberRM? We'd love to hear about them. Post them here or on our messageboard. If you have something that you'd like us to cover, let us know we'll do a post on it as well.

Talking about what we do

I have the opportunity to talk about Requirements Engineering (RE) pretty frequently.

Most of the time, I'm talking with people who are familiar with software development in general, and some of the time those folks are also familiar with the specifics of RE. There's a shared understanding of the work that we do in RE, even if there are differences of opinion regarding just HOW we do that work, or the specific outputs of the work.

Today, I had a unique opportunity to discuss RE with a group of people who are not involved with software development or RE. I presented a paper at the American Society for Information Science and Technology (ASIST) conference (as a bit of background information, I'm currently a grad student at The University of Texas's School of Information).

My paper is a review of the work on Information Behavior (generally speaking, the theories and models of how people identify an information need, look for that information, and then put it to use) in RE. My audience today was quite familiar with Information Behavior, but only a few people there had ever been directly involved with software development.

Now, we've probably all had that moment when we have to explain what we do or what RE is. And usually we're explaining it to a relative or friend or someone on the elevator who has no exposure to the ways in which software development takes place, so we say things like "I'm a translator between people who NEED software and people who BUILD software," or "I take the requirements from the users and give them to the developers. I have people skills."

But today I wasn't talking about MY job, I was talking about OUR collective job. I was trying to explain what RE is and what Requirements Engineers (or Requirements Analysts, or Business Analysts, or....) do and how those both overlap with the world that ASIST members work in.

What I discovered is that, in some ways, it was easier to explain RE to a "foreign" audience than it is to talk about it with "insiders" like fellow analysts. All I had to do was provide an overview of our work, and then I could spend more time drawing parallels between the specific aspects of that work and the theories of Information Behavior.

What's more, I could use the language that my audience was familiar with to help make my point. I could have spent 30 minutes trying to explain the nuances of eliciting requirements, but when I said that it's like the reference interview for a librarian, everyone in the room knew what I meant. Of course, being able to talk that way required that I be an "insider" in both camps -- RE and Information Studies -- but it worked, and it worked well.

So, what's my take-away point for you? Figure out what YOUR audience understands, get familiar with that domain, and learn how to use examples from it to do a great job at analysis. You don't have to understand the entire domain at an expert level -- just get familiar with a few of the main practices, problems or current issues, and you'll be able to connect with people much more effectively. That skill will help you with everything from elicitation, talking to librarians, and explaining to Aunt Sally exactly what you do for a living!

PS - If you're interested in talking about RE and Information Behavior, post a comment and let's chat!

Webinar Update: How To Successfully Manage Software Requirements In A Global Organization

We've been getting quite a few requests for our most recent webinar. I thought that I would make it available for the folks who missed it.

We'd love to get your feedback, so please post your comments below. Also please feel free to share the slidecast with your friends and colleagues.

| Get your Presentation Pack

3 Big CaliberRM Gotchas And How To Fix Them Part 1

So we have been using Caliber RM for awhile now. Joy Beatty wrote about our selection process in a prior blog post. Since that time we have gotten some more experience and overall we are very happy with our choice of CaliberRM. However no tool in life is perfect and we are analysts afterall, so rather than post all the things we love about CaliberRM, here are some gotchas that we have found when using it.

Since we had a lot of projects in progress, one of the first tasks was to import a lot of docs into CaliberRM. It turns out that the import tool has a tough time, unless the document is very structured and makes extensive use of styles, so we ended up doing the imports by hand. These gotchas apply regardless.

Drag And Drop

Moving requirements around doesn't work quite right with drag and drop. You will find that sometimes no matter how hard you try it is incredibly difficult to move a requirement to the top of the list. It will either drop to the level above or you will drag the wrong requirement even though you definitely grabbed the correct one.

The key is to click the folder to move and wait a second, then when you move it make sure it is the right folder. The target position will be indicated by a line between folders, however that doesn't work if you are dragging a folder to the top position of a subfolder. Sometimes it was easier to just drag folders to the second position, then drag the first folder to the correct position.

You Can Only Paste Images

If you try to paste something that isn't an image (OLE object) it will show up as dead in CaliberRM as a tiny rectangle with an X inside. I will typically be gutsy and paste a whole section then go look to see how bad it looks. I will fix any images by hand.

a) If you did custom drawing in visio the easiest way to get them in is to cut the visio diagram and then paste special back into word as a bitmap. You can then copy the bitmap into caliber

b) If you did custom drawing in word itself it is VERY difficult to get in because you can’t copy and paste all the shapes into their relative positions. Direct drawing in word is by far the worst thing I encountered. I had to print the page to Snagit (screen capture/editing program) and then cut and paste out of Snagit into caliber.

c) Sometimes some images in word docs aren’t truly images but they aren’t Visio pastes. Just copy and paste as a bitmap.

d) Sometimes the object is an OLE object that when you paste as a bitmap the color scheme changes to an inverted color map. In those cases, pasting into MSPaint first helped. MSPaint proved to be the most reliable source for pasting images.

e) Sometimes CaliberRM will get into a weird state where it will paste the last image you pasted vs. the one that is in the clipboard. Restart caliber.

f) Sometimes CaliberRM will show you that you pasted the images but after you save they will all be gone. Restart caliber.

g) Sometimes CaliberRM will resize your image in a funny way. You can resize it back to the approximate shape. We believe that typically happens when you have an image embedded in a table. If you are able to find the frame of the cell sometimes you can delete it and paste the image outside of the table and it will size properly.

h) To delete an image in caliber you have to right click it and select delete. The usual paradigm of selecting and delete button doesn’t work

Tables Can Be Too Big

Some tables have a large amount of html and so a medium size table will actually exceed the 200,000 character limit of the fields. Turn change tracking off, remove formatting and pasting into excel first can all help. Pasting into excel took a 400k character table down to 200K and it looked exactly the same.

Stay tuned for Part 2, where I'll cover 5 more CaliberRM gotchas.

Live from ProjectWorld: Virtual Workplaces

I am at ProjectWorld this week, and on the first day I attended a Virtual Workplace forum. We started by defining what “virtual workplace” meant. These definitions include everything from “having no assigned physical desk to work at”, to “any two people working in two different physical locations” to “all vendors”. In this case, the facilitator, Karen Sobel Lojeski, suggested we let it be defined as “any environment where you are using a laptop or PDA to get work done”. The point is that communications are electronic. She explained some common thoughts along the lines of this virtual communication topic. She then went on to explain the “same as me bias”, where when we meet someone new, we assume they are just like ourselves. If we meet face-to-face, then we quickly learn about one another, specifically what communications are working or not. But in electronic communications that s much harder, takes much longer. So with electronic communication, while we are more “connected”, ironically we are actually more “separated” from each other as humans.

Karen explained an interesting study described in “Why Distance Matters: Effects on Cooperation, Persuasion and Deception” by Bradner and Mark, in which groups of people were told either that they were collaborating with people in another country or with people across town. She explained the study demonstrated that people who perceived they were closer to the other people were more collaborative and persuasive. In reality, all of these groups were in the same building. And when using electronic communications, there is a perceived long distance. Furthermore, her research shows innovation, job satisfaction, and role/goal clarity are all negatively impacted by a virtual distance.

I thought it was interesting how she tied this to the election even. Obama was able to take a situation in which he had “physical distance” from his voters, lessen the “operational distance” by matching their communication desires for his messaging (txt, email, etc.). He also lessened the “affinity distance” by making people feel like he was one of them.

So if you have to work virtually, then what? Well she suggests when setting up contracts with vendors, partners, etc. to do work, it is useful to build a “trust building” effort into the contract f the teams will be remote from one another. Her research explains that this connectivity can be measured, so you can plan to reduce t and know if you have reached a productive state as a team.

Why Do We Model Software Requirements?

The other day, I was flying to California to visit my customer. On the plane, I was seated next to a gentleman who worked for a small engineering firm in the Silicon Valley.

We quickly struck up a conversation about work and when I began to explain what I do), he got this perplexed look on his face. Seeing the confused look, I decided to try and explain in greater detail what I do as a product manager.

The gentleman quickly explained that he understood the idea of requirements but did not see how there would be enough demand for someone to do this for a living. Then he said "So, tell me what your company does that is so different from what I might do."

I briefly began telling him about requirement work and when I got to modeling he just laughed. "How and why do you model a requirement?” he chuckled. “A requirement is just a statement that says what functions you want the software to do.

I compared Use cases to an assembly instruction for one of his mechanical devices, and an ERD to an exploded view of one of the fully assembled parts that he might design. We discussed benefits of modeling in opposition to just creating a lot of "System Shall" statements.

I summarized things this way:

Requirements Models Allow Us to Organize Our Data in Multiple Ways.

There are only so many ways to say that someone needs a log in screen. But who needs it? And why?

By placing information into models, such as context diagrams or organizational charts, we can see information from angles that we wouldn’t normally have. We can use the images to gain perspective that we wouldn’t normally have.

Models Help Us to See Things That Might Be Missing.

When you’re sitting down with someone, it’s pretty easy for them to take a first stab at telling you everything they want.

But how many times have you had someone say, “Yep, that’s it,” when you asked them if you’ve covered everything only to find out that that there were, in fact, a few pieces missing.

Putting things down on paper helps us arrange information visually so that we can see the gaps that we normally wouldn’t see in a long list of requirements.

Models Create a Visual Representation of What’s Expected.

Ever tried to describe a web page without building a wireframe?

You’ve probably discovered by now that even if you scratch out a design on piece of paper and hand it to someone it’s more effective than writing 1000 words.

Plus when you put a wireframe in front of your customer, you can get them to say, “Yep, that’s what I was looking for,” or “Nope. That’s not it.” In either case, you’re able to get their feedback on something solid before you give it to development.

As we continued talking, I saw the light go on.

Models aren’t just fancy drawings that product managers use to eat up time and paper. They are an effective and powerful tool that helps us communicate with our users and developers. Don’t get me wrong, you need to be able to write up functional specifications clearly and concisely.

But do yourself a favor. Add a few models to your toolkit.

Join our Webinar: How to Manage Requirements in a Global Organization

I just want to make sure that everyone is invited to our upcoming webinar on 11/13/2008 at 2pm CST/3pm EST. Click the link below to sign up.

https://www2.gotomeeting.com/register/980887368

We’ll cover some of the top questions that people have asked us about successfully managing requirements with distributed teams:

o People: What skills do you need to develop in your teams?
o Processes: What process frameworks should you put in place?
o Tools: What requirements tools are out there and which ones should you consider?

Anthony Oden of Dell and Joy Beatty of Seilevel will be hosting the presentation. Anthony has built a successful requirements community at Dell with just a handful of collaborative tools: SharePoint, blogs, and wikis. He’ll be on hand to lend his experience with the challenges of communicating across time zones.

Joy’s been writing about requirements and developing new services at Seilevel for several years now and recently presented two papers at the IEEE Requirements Engineering forum in Spain.

If you’d either like to drop me a line with some feedback or register for the webinar, please don’t hesitate. I’d love to keep the channels open so that we can keep providing you with the information you need to do your job better.

We'll see you there!

PresidentWare, part 2

In part one, I showed the similarities between politics and the software industry, likening an election to a software RFP. In this post, I’ll go further into the discussion of how requirements management techniques can be used to help us make the important decision of which candidate to vote for.

As humans, we can get emotional over issues and allow it to color our decision-making process, often missing other important considerations as we do so. This is true in many aspects of daily life, and politics is no different. By applying the same techniques we use in our work, we can make better decisions about other aspects of our lives as well.

Elicitation - Granted, this is a conversation with yourself, but still, it’s a discovery of all the things you want from your president. Get them all out on paper, without consideration of importance or applicability. An affinity diagram would be useful for this exercise. Affinity Diagrams are a way to brainstorm out requirements and classify them into groups. A very popular way to use this method involves writing requirements on sticky notes as they come out, until either there are no more ideas to capture or until a given amount of time has elapsed. After this phase of the process, you can sort through the issues and classify them into categories. For example, in this context, some categories might be "Social Issues", "Economic Issues", "Security Issues". Collect your ideas/issues and group them according to the categories you've created.

Prioritization - Here’s where the rubber meets the road. The chance of having your personal set of requirements agree with any one candidate is unlikely at best. Finding where your priorities lie will help you determine how well the positions of the candidates match up with your own. For example, building on the affinity diagramming method above, you can rank your categories in order of importance, and then rank the issues within those categories. If you used sticky notes, just re-arrange them. Otherwise, you can number them in a way that makes sense to you.

Gap Analysis - So, now you've got your ranked and categorized requirements. Since we’re evaluating our requirements against established products (political platforms), we need a gap analysis to determine which system is a better fit for our requirements. In this context, you can simply take each issue in turn, look at the positions of the candidates, and decide which candidate more agrees with your position on the issue. Again, if you're using the ubiquitous stickies, you can move them around, either to one candidate or another, or into a "tie" area. Another way you can do this is to create a simple matrix, listing your issues down the side in priority order, and across the top listing the candidates and a box for "tie". Then, simply go down your list and mark your choices in the correct box for each.

By now, you should have a clear understanding of your issues, how important each one is to you, and which candidate best supports your position on those issues. Now that we’ve used the tools in our toolbox to evaluate our decision objectively, we’re ready to make an informed decision on which way to cast our vote – without the cloud of emotional involvement with a single issue.
Whichever way your requirements point you, please remember to vote on November 4th!