An Actual Case of Software Requirements Re-use

We have been using Caliber for a few years and we recently decided to research whether there was a requirements management tool that more cleanly supported working offline. I actually wrote a bit about our vendor selection process and our search for a requirements tool awhile back, so if you read it, you’ll know we did this project working from software requirements written at the level necessary to do a vendor selection. Well, here we are again a few years later, with a pretty important feature request that we didn’t recognize the priority of when we did the first analysis. The issue is that we often work on cellular cards, which with Caliber has doesn’t work well – the connection is too slow. So we really need to be able to just work offline and sync. We have a few anecdotes about other vendor tools in the market and how they handle offline support. We even have thoughts of building some offline tool ourselves to sync with Caliber or another backend. In the end, we are trying to follow our vendor selection process. We have done a bit of research on the other tools we know might work – including reading feedback and doing a mini demo ourselves. And at the same time, we have our existing software requirements from the first time we selected a tool that we are reviewing.




Our intent is to review any tools we consider against those original requirements. Ideally we really need reprioritize those as our needs may have changed, but for the most part we can select a new tool with MUCH less work than the first time. My estimate is it’ll take a tenth of the time this round through.




The only downsides to this, our old requirements aren’t in a tool (since we didn’t have a tool when we did the first analysis) and I don’t know how easily we can get them in one. But the bigger issue is there is no organization to them at all – they are about 150 features, not organized by any other useful models (and that’s because we didn’t use models as consistently then!). So, while we do have our software requirements to reuse, we probably could do a pass on improving them too. But even at that, it’s still so much less time committed.

4 Tips to Not Destroy Your Project if you Must Use Spreadsheets for Software Requirements

A year ago, I was working on a project where we created a list of features in Excel to help development understand at a high-level what would be in the new system we were building so that they could provide quick and dirty estimates. Out of these estimates, a solution design for the project was chosen and the team headed down the path of a full blown software development lifecycle on these features. Before too long, we recognized the nightmare that Excel was going to cause us, so we uploaded the features from Excel into Borland’s Caliber requirements management tool. The great thing was we could continue to export to Excel pretty quickly for delivery to our customer, since they didn’t have the tool and they were used to that format.

Now also of note, the team decided to use something a bit like SCRUM for this project, so we just treated the features list as a “backlog” of sorts. As sets of features were prioritized for an upcoming sprint, the business analysis team did its elicitation and documented requirements in the form of models from RML™. Throughout this process, we wrote user stories instead of formal use cases, used other visual models as appropriate, and instead of traditional “shall statements”, we wrote “confirmation statements” to describe the functional requirements and business rules. They were used to describe in detail what the system actually needed to do. Oh and by the way, these were all put in Caliber and exported into Word docs as needed for review and development.

Let’s jump ahead 6 months. Our team actually wasn’t on this project for about 3 months, and when we came back to it, we found what I would label “a requirements mess”. I have analyzed this a million times to understand what happened when we transitioned off for that time period that it went so wrong to land the team in this situation. And while I have ideas, the point of this post really is that it just was a mess.

Unfortunately the team stopped using Caliber completely, so all requirements changes and new additions were done in Excel and Word. As is expected, they had lost chunks of work in overwriting newer versions with older versions by accident. There used to be traceability between features and detailed system requirements, but that was completely lost.

What was most alarming and damaging was that the development team believed that the Excel list (which represents just a list of features with one-line sentence descriptions) was the full set of requirements. They weren’t even looking at the user stories, models, and confirmation statements to develop the system! As one might expect, the system developed didn’t really meet the requirements.

And so we headed down a path of narrowing the gap between what was developed and what was required, as well as completing analysis on areas not yet developed.

Over the next few months it became completely apparent how much people love to use Excel. I mean LOVE. Sure enough, one year later, the Excel file still lives as the source of what the scope is on this project. And while they are now using the detailed requirements documents to develop, the Excel list is still the master of all information. And did I mention, there are now about 60 columns to it? And 3 versions of the document that have different information in different columns? I had the exciting task of trying to merge the 3 back into 1, but while I was doing that, someone was editing one of those versions so now we still have 2 versions. Alas we are trying to get approval to get a few licenses of Caliber in place so we can move this spreadsheet back into a management tool.

But the moral of the story is….well Excel sucks for managing requirements, but if you must absolutely use it:

1. Do more than just use Excel – put your requirements details in other formats as well.

2. Be cautious about what information belongs it and what does not.

3. Be careful what you communicate that it actually represents to the project team.

4. And please use a tool behind that Excel to house your data.

BluePrint Tool

I attended a talk by folks from BluePrint and LexisNexis at BAWorld on Tuesday. The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from someone who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and BluePrint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for BluePrint, but it was given by an actual user....and you could tell she was being honest about it.

BluePrint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes

I haven't used BluePrint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Live from RESFQ: Lessons Learned from Open Source Requirements Efforts

Paula presented a paper by her and Jane Cleland-Huang of DePaul University titled “Lessons Learned from Open Source Projects Facilitating Online Requirements Processes”. The idea behind her paper was to suggest that forums and wiki-style tools might be used to collect and prioritize requirements across a large volume of stakeholders. She looked at forums used in vendor-based open source software projects for this purpose, with the idea that the lessons learned good be applied to any type of distributed project.

Some of her observations about what is needed to make forums successful for this:

• Features need to be organized or grouped in some way so it’s not just a massive list of many feature requests. This would allow users to participate in discussions similar to the feature they are interested in.
• There needs to be high visibility on the status of feature requests so users understand if it’s low priority, not in discussion, or not looked at yet. This helps them understand what to expect.
• Analysts need to stay actively involved in the conversations with stakeholders and not let it be a passive process.

These things have something in common – they are all things you need to do in a typical requirements elicitation process too. I think that perhaps there are some things we can do to adapt this to large distributed teams contributing to the requirements, but it will by no means be an easy task. I think most importantly, you have to keep the community aspect of requirements gathering and not let it just be a text-based one-way conversation.

Software Requirements Screencast: Pasting Images Into Borland Caliber RM

In the following screencast, I demonstrate how to put images into Borland Caliber RM so that they reliably can be output into document factory. This is a demonstration of part of Anthony C's post in December "3 Big Caliber RM Gotchas And How to Fix Them Part 1".

You can also find this video in the media section of our software requirements resource page.

Screencast: Getting the Most Out of Caliber RM And Your Requirements

In this post, Anothony C describes how to export your Caliber Requirements Grid into an Excel spreadsheet. In the following screencast, I demonstrate how to copy a Traceability Matrix from Caliber RM into Excel using a similar method.



You can find this video as well as many more requirements templates and tools in our resources page.

Diagrams 2008 Day 2 Highlights: Tools, Tools, and more Tools

Most of today’s sessions were all about Tools. Most exciting was a demonstration of Inkkit and LADDER by Beryl Plummer and Tracy Hammond. A colleague of mine had already told me about the exciting work done by Dr. Hammond and her Sketch Recognition Lab at Texas A&M University , but today, I actually had a chance to see it in action. Imagine entering a requirements elicitation session in a room with no whiteboard. In most cases, the requirements engineer would need to either collect several sheets of freehand drawings, or (if you are lucky enough), allow the subject matter experts to capture their thoughts on a tablet PC. In either case, the RE still needs to transcribe these drawings to Visio or some other tool. This is not only time-consuming, but transcribing introduces the possibility of errors. It was so impressive, that I think I will begin testing it in elicitation sessions.
Here is a picture of Ladder in Action. Includes some "before" and "after" the sketch recognition algorithm is applied. Note the various types of drawings:








As a side note, Dr. Hammond mentioned that designing the algorithm for the entity-relationship diagram is especially tricky, and is still not completely refined. The sticking point? Those pesky claw-foot connectors which depict the cardinality of the relationship between two entities.
Some other high points:

• David Barker-Plummer of Stanford University gave a demo of Hyperproof. Initially, this was designed to grade logic proofs for undergraduate students, but it has been and can be extended to capture and check reasoning for any type of system.
• A presentation of the VAST system by Peter Cheng. This tool was designed to create schedules for large institutions with many complicated interrelated constraints. The way in which so much information was presented, but yet easily understood was quite clever.

The day ended with a tour of Mühlfelder Brauhaus followed by quite possibly one of the top 5 best meals of my life: A six-course Bavarian meal with a spectacular dessert. And of course, plenty of beer from the brewery.



Oh, by the way, the winners of the best paper (and the Nokia N810s) were Atsushi Shimojima and Yasuhiro Katagiri for their excellent paper An Eye-tracking Study of Spatial Constraints in Diagrammatic Reasoning. I also had the opportunity to meet Atsushi Shimojima, and he is a really nice guy. The best student paper went to Krista DeLeeuw and Mary Hegarty for What Diagrams Reveal about Representations in Linear Reasoning, and How They Help. This paper, among other things, describes the power that visual tools can provide in helping people think about problems.

Your Requirements Best Practices Are Not Your Reality

To begin with an analogy: I have a friend that can be unreliable sometimes and show up late when we have plans to meet. This is especially difficult to manage when we are meeting to see a movie – if she shows up 30 minutes late, then the movie date is off because the show has already started by the time she gets there. She’s a great person to be around, just difficult to manage at times. We agree that we need to meet 15-30 minutes before the show time (best practices), yet something happens and she shows up after the movie starts.

If our plan to see a movie was instead a project for which I was the requirements expert and she was the project lead, then the concept of showing up 15-30 minutes before show time would be a recognized best practice. So what to do when an acknowledged best practice conflicts with what the project lead wants (the right to show up late in the case of the movie example)? The lead wants the benefit of the best practice (seeing the movie), but things happen or constraints are in place that create a situation where this cannot be done.

What I should do (Best Practices) ≠ What I’m going to do (Reality)

The first step I take in these situations is to first fully understand the project lead’s reasons for not being able to apply the best practice. From the movie example: perhaps my friend is taking college classes at night, and they end right before the movie meeting time. In that case, we could just meet for a later movie, or wait until the weekend. Can the lead and I find a “movie time” that works for everyone where we can still apply the best practices?

In the very rare case that the project lead is simply in disagreement with the use of the best practices, then I determine if it is something worth arguing for. How will the project be affected if we do not apply the best practices in question? If the impact is minimal or can be easily negated and/or managed, then it makes sense to apply the practice that the project lead is requesting. If the impact is too great to ignore, then I work to convince the lead to trust me and let me demonstrate the benefits of applying the best practice.

By the end of the project, we are laughing and munching on the last of the popcorn together as we exit the theater.

When Faucets Fail: Keys to Successfully Adopting New Tools

Example of Failed Adoption

In 1928, the wild cabbage cultivar known as broccoli was still new to the United States when E.B. White, channeling his inner scamp, penned his most famous caption for a cartoon in the New Yorker. The scene: An earnest mother admonishes her child to try the new vegetable, and the little girl, even in her tenderest youth, is positively awash with jaded cynicism. The runt, ruefully eyeing the plated abomination, seems weighted to the breaking point with all the hard-won wisdom that the better part of a decade can afford a kid. For this little girl has heard this song and dance before: the endless ruses of airplanes and choo choo trains and dessert. Not today, Mommy. To leave no doubt that she was onto mother's nefarious shenanigans, the daughter crisply replies:

"Well, I say it's spinach and I say the hell with it."

No doubt the child felt not only vindicated and proud of her own insight, but that she was doing everyone a service. The reality was that she would have no dessert and the hellspawn vegetable would sit there until it was finished. A bad experience for all involved.

New technology, like broccoli, promises to make our lives better, healthier, easier. Unfortunately, new tools don't have that reassuring patina of established use: the cultural acceptance, tribal knowledge, desktop shortcuts et al that tools develop over time. New tools (most especially in requirements, which often have many steps involving many people) may be abandoned for the old methods, which have no period of adjustment, yet also no prospect for improved experience. Even worse, initiative fatigue, a form of plain old change fatigue, can automatically short circuit a new technology.

I was recently browsing the "non-corporate press" section of the famous City Lights Bookstore in San Francisco and found a collection of old cartoons mercilessly lampooning a foolhardy new technology: the automobile. The message was clear, "My horse and buggy work just fine, thank you." It was a striking reminder that technology and change can turn the nicest of folks into braying jackasses that you couldn't move with a Chinook, let alone a carrot and stick. And no one is immune. Like Mr. White, we all have an inner scamp that has an inherent tendency to childishly reject change.

Even if the requirements for the tool have been vetted (hardly a forgone conclusion, even in departments that specialize in requirements management), you have to prepare the users for the change.

Keys to Successfully Adopting A New Requirement Tool.
Talk about your expectations for the new technology with new users. What are your specific objectives for use in this instance? Is it performance improvement, for example? How do you measure that? Here are some basic points you should address:

1. What are your specific conditions for disuse/rollback? (Are there conditions?)
2. Plan and set expectations for some frustration as natural (Don't promise silver bullets!)
3. Account for attention spans
4. Be realistic in your expectations
5. Develop an implementation plan
6. Develop a training plan
7. Establish success metrics
8. Identify subject matter experts and a communications plan

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.