Taking Out the Trash: Waste Management Sues SAP

Many of you may have already heard about this one - Waste Management is suing SAP over a recent implementation that went sour. The lawsuit is for $100 million, and if you want to read the whole complaint, you can find it here. It looks like there are a few things going on in this case. According to the complaint, SAP over-sold the capabilities of the software. What is really interesting is the lawyer's language around "fake software" when describing the prototypes and mock-ups.

Good requirements practices cannot fix everything, but I believe using them in this case would have saved Waste Management (and SAP) a lot of money. Here are a few things to consider when implementing a packaged solution.

1. Have a well-defined selection criteria/process. I've been around enough of these large package deals to know that a lot of politics goes into the selection process, but there needs to be an objective team that analyzes the potential suppliers against the business objectives and required features. Check out this post for more information.
2. A good Product Manager will help the business understand the implementation process. Is it just the lawyers speaking, or did Waste Management truly not understand that they were seeing prototypes/mock-ups?
3. A good Product Manager will also perform sanity checks with the implementation team. Are the prototypes standard functionality, or do they represent a lot of customization? If there is customization involved, how much? Can standard functionality be utilized and still achieve what the business needs?
4. Don't forget that requirements analysis is just as important in packaged solutions as it is in custom implementations. No enterprise solution is ever implemented "out of the box", so don't neglect the process of identifying what business value you are trying to capture, what processes you need to support, and the specifics of what you need the package to do.
   

Diagrams 2008 Day 3 Highlights: (Useful) Eye Candy

In a word: Awesome. There really is no other way to describe today’s Keynote Presentation by W. Bradford Paley (link). Paley has done a ton of work in Graphical Design and implementation which has touched many industries—from revolutionizing the ways in which Wall Street traders to their job, to creating stunning displays for the New York Museum of Modern Art, to creating tools which aid in literary analysis. To sum up, he has created exciting new ways to model a large amount of very complex information, as well as provide the ability to analyze the information easily and in a visually captivating way. His creations blur the line between design, art, and analysis. Here is one sample of his work, which can be explored more at www.textarc.org



An interactive map of Alice’s Adventures in Wonderland used for literary analysis. The entire story is displayed around the circumference of the map. In the middle, sits all the words in the story, with the more frequently used words displayed the brightest and biggest.
Clicking on a word will display in a map all of the places in the story that word is used. This provides a very simple visual cue to the user. While this tool was designed with structuralist literary analysis in mind, there’s no reason why it couldn’t be used for requirements analysis.
Paley has also designed a tool to create org charts, but in a much more sophisticated way than Visio. Paley’s tool allows the user to define more informal relationships, as well as drag and drop nodes into several different clusters. It looks like a great way to create an org chart from scratch when all you have is a list of people, their positions, and a few loosely-defined relationships among them:



You may be able to make out a tree structure on the left hand side of the diagram. This is a directory structure which mirrors the visual structure on the org chart. It seemed as though, according to the demonstration, that one could drag names from the structure on the left into the space on the right, creating a new node on the org chart.

A few more examples of Paley's work, many of which are described on his website. All of these were fully interactive, allowing the user to pull apart, zoom in, and highlight nodes:



This was a model Paley created of a social network.



A model of the relationships among scientific paradigms.

Finally, something a little more applicable to requirements: A concept mapping of items in an online catalog. One of the cool things about this application was that it allowed the user to design her own icons which represented each concept in the hierarchy using a freehand drawing:



Well, today was the final day of Diagrams 2008. The agenda has been intense and has covered everything from Euler Diagrams to Animation. Because Diagrams was so interdisciplinary, there was no specific requirements engineering agenda; however, that does not mean it wasn’t useful to RE practitioners. Quite the contrary, many of the presentations were not only inspiring, but directly applicable to Requirements Engineers. Just having the exposure to a vast array of brilliant minds thinking about how to represent complex information efficiently and more simply made the conference well worth attending for someone with an interest in RE.

Now, off for a day of sightseeing—and most likely a little more beer, followed by a long commute home.

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.

There is Value in a Good Passdown of Software Requirements

Several years ago, my sister in law (Cathy) went to visit my parent’s at their home. She arrived at the house while my mother was out running a quick errand.

Cathy noticed that there was a pot on the stove with some freshly brewed tea. Being thirsty and the ever-helpful daughter-in-law, she decided to go ahead and pick up where my mom had left off, so she finished mixing the tea.

My mother arrived at the house a few minutes later to find Cathy sitting on the couch enjoying a nice glass of ice tea. Mom walked into the kitchen and asked Cathy where she got the tea. Cathy explained how she had just finished what my mother started and made the tea. At that point, my mom asked her “so where did you put the sock?

Not quite understanding the question, Cathy sat there and just looked puzzled. Mom started laughing and found the blue pitcher where Cathy had made the tea. Calling Cathy into the kitchen, Mom took a spoon and pulled out a ratty looking sock from the mixture.

See, Mom had started out trying to die an old white sock tan for a hand puppet for a school project. She had seen tea used many times as a child to turn things to white material to tan and figured that no one would mess with what she was doing.

Although Cathy had good intentions, she totally missed the mark. Cathy thought she knew what was required to finish the job, so she took over without really getting a good pass down. All of her efforts produced what she thought was the end goal, but had she missed the goal of the original project. As a result, Cathy was embarrassed and had to restart her project of making Ice Tea and my mother ended up with a slightly different sock to use with her puppet.

When transitioning into a project, it is critical that we get a good pass down of not only our role, but understand the expected outcome as well. This way, we can decrease the risk of creating an unusable product. We should never assume that we understand what needs to be done.

Diagrams 2008 Day 1 Highlights: From Models to Code (and Back)

Today's Keynote address, given by Wilhelm Schäfer, discussed something called Mechatronic UML: A subset of UML 2.0 with applications in industries which intersect EE and ME, and actually in use on the Railcab project.

This subset of UML is used to generate code for systems in which there is heavy interaction among several different components—especially designed for safety-critical applications (such as public transportation). Although such a language is definitely beyond the scope of most requirements engineers, it made me reflect on the “Requirements/Design/Implementation” distinction, in that even though the distinction between requirements and design will never be resolved, the distinction between design and implementation always seemed more concrete. I think that Schäfer’s project has sort of blown a hole in this belief for me, as the design work done in UML is used to generate code directly and successfully in very complex systems. Now, if there were a requirements modeling language which could be translated into Mechatronic UML (or even a fragment of it), it would not only blur the line between requirements and design even more, but also the line between requirements and implementation. Scary.

Also, today during the welcome and introduction, it was revealed that the authors for the best paper in the conference would be awarded two Nokia N810s tablets! Cool! One of the great things about a conference such as this, is that despite the diverse interests of many of the participants, all of them almost universally believe in leveraging technology to solve complex representational problems. As a result, I would say that around 50% of the people here are using a tablet PC or convertible.

At the poster session, I encountered some interesting studies about diagram placement and comprehension of supporting text. It turns out that placement of diagrams in relation to the supporting text may not be as important as our intuitions might reveal. Additionally, diagrams with which one must interact in order to view (e.g., a clickable thumbnail) are more likely to be ignored. The sample for this study was college students, however, and not requirements engineers or their audiences. It would be interesting to run a similar study with an RE orientation. By the way, there was plenty of German snack food at the reception and poster session—pretzels, dark bread, wurst, mustard. And of course, beer. It was a long and cold—but happy—walk back to my hotel.

No Reservations: Diagrams 2008


Ok, so I actually did have reservations for this trip, although just barely. Try booking a hotel during the week of and before Oktoberfest near the capital of the annual Dionysian festival. I’m just a fan of Anthony Bourdain, and am shamelessly using the title of his show to help promote my blog posts. I arrived in Herrsching am Ammersee around 6pm on Thursday, September 18th. It’s cold. Really cold. It’s been rainy, too. And I forgot my umbrella.


View Larger Map

So, what am I doing in Herrsching am Ammersee? Attending the Diagrams 2008 conference, of course! It promises to be a fun-filled three days of discussions about Euler Diagrams, Mechatronic UML, and Heterogenous Reasoning. What are these things, you may ask? Perhaps even more important, what the heck do they have to do with software requirements? Well, possibly nothing, but I’m determined to find some way to justify my company sending me to this conference.

Actually, they have quite a bit to do with Software Requirements, at least ostensibly. More will be explained in the coming days, but for now, here is some introductory information about the conference. The header of the conference website says the following:

“From early human history, diagrams have been pervasive in human communication. The recent rise of multimedia technology that has turned advanced visual communication into an integral part of our everyday reality makes a better understanding of the role of diagrams and sketches in communication, cognition, creative thought, and problem-solving a necessity. These developments have triggered a new surge of interest in the study of diagrammatic notations, which is driven by several different scientific disciplines concerned with cognition, computation and communication.”

As you can probably tell, the conference is interdisciplinary in nature. Also quite fortunately, the conference’s themes intersect with some of my own marginally-requirements-related academic interests: formal languages and their applications, as well as diagrammatic reasoning (which is just a fancy way of saying “using pictures to arrive at conclusions about stuff”). Now, fellow requirements folk, are you getting a clearer picture (LOL) of how this conference is related to software requirements? If not, here are some things I expect to learn, based on the paper submissions:

• Leveraging findings in Cognitive Science to help with Model Selection in Requirements Engineering
• Applications for models on very large-scale problems--think about entity relationship or dataflow diagrams with hundreds, even thousands of nodes.
  
• Tools, tools, and more tools. There are some really cool modeling tools and sketch recognition software being demoed. Also, some prototyping tools.
  
• How to analyze models for consistency.

Stay tuned, as there is lots more to come. Auf Weidersein for now.

PresidentWare

Something struck me as I was sitting and watching the convention speeches over the past couple of weeks… politics is a lot like the software business.

Sounds crazy? Let me break down my reasoning by drawing some analogies:

Political Parties (Vendors) – Develop products to sell based on their own ideas and their market analysis.

Candidates (Products) – Products are designed to satisfy various market segments. There are enterprise solutions (presidential candidates), small business solutions (congressional candidates) and products designed for home users (state and local candidates).

Voters (Users) – Users select products based on their needs and on their perceptions of the quality of the available products.

Elections (RFPs) – Every so often, a customer will release a RFP for a product. Sometimes, the RFP is to evaluate a product for replacement, sometimes the product becomes obsolete (term limits).

Proposals (Campaigns) – Vendors respond to the RFP with a proposal to fulfill the requirements of the voters.

Issues (Requirements) – The user community has certain requirements that they need to have satisfied by the chosen product.

Over the course of this process, the vendors make tweaks and present their products in different ways to respond to the feedback of the users (polls) in order to try to influence the buying decision. Just as in a software project, the shifting features and presentations can begin to make it difficult to sort the wheat from the chaff. How do we, as voters, make this important decision?

Fortunately, in the requirements community, we have exactly the right tools to make this choice easy for us. In part two, I’ll discuss how we can apply requirements management techniques to do exactly that…

Prioritizing Your Software Requirements, Part II

In Prioritizing Requirements, Part I, we covered the reasons to prioritize requirements and the basic technique. We’ll now address what to do when there is disagreement about prioritization.

Unfortunately, requirements prioritization exercises can degrade into arguments very rapidly. This is particularly true when there are conflicting requirements that each side feels they must have. The best way to avoid this type of emotional response is to discuss the facts – what will the impact to the business be if we don’t implement this requirement?

The only way to understand this impact for each requirement is to make sure each maps back to one or more business objectives. These objectives provide a measurable, quantitative impact for each requirement. Tracing back to business objectives allows you to rephrase the question from: “Which requirement do you want – System shall allow a player to play in more than one game at once. vs. System shall allow players to create and maintain teams of other players.” to “Which requirements is better for the business with respect to the objectives of this project?”

The trickiest thing here is setting up these relationships in the first place. If it is not clear how each feature enables the business objectives, it is certainly worth the time and effort to uncover the correct links to ensure that the features and requirements being implemented actually will help solve the problem!

The important thing here is that you are reframing the conversation from “what I want” to “why this feature/requirement will help achieve our goal.”

Happy prioritizing!

Live from RE’08: All Done, But There’s Nothing Wrong with a Little Fun!

The conference is now over, and it’s been a great one! Now we can all look forward to RE’09 in Atlanta. But before we leave the live posts behind, I want to share a fun story about some of our favorite requirementers.

Wednesday night they had a conference reception at the Museu Nacional d’Art de Catalunya (that’s National Art Museum for those that can’t read the language!). It was fun, we got to see a part of the museum even. Well after the party, we decided to go for a drink and of course invited others to go along with us. So off we headed with some of our favorite requirements experts, to find a drink in the streets of Barcelona. Along the way we managed to find some more of our favorite requirements experts wandering the streets. We found a nice little bar where we could sit outside and order cerveza and vino.

We also heard some more statements to add to the stupid thoughts list.

• "When I got here, I only knew how to say 3 in Spanish - which meant I had to be really committed to whatever I was asking for." Really?
• While looking at the murals in the Romanesque Gallery, which were from various small churches, one person says “ So, then you think they moved and re-built these here?” … um, as opposed to building the museum around them?
• And what happens when you ask a very literal person (we are at an RE conference after all!) a specific question. I was surprised to hear this person only brought one pair of shoes. So I asked “You wore your shoes on the plane then?” thinking maybe he packed a dress pair and wore another pair. His response was perfect “Well usually yes, I worry about foot fungi. I mean if it’s a long flight, I might consider taking them off, but it depends on the feeling I have at the time.” To his credit he answered the very question I asked!
• In the context of guessing the length of the tunnel "How far are we now?"..."We're at one.."Where did we start?"....."Uh, zero - where else would we have started? Negative?"

And with that, thanks for the good memories RE'08 friends! We learned a lot, some about requirements, a bit about ourselves, and a lot about our colleagues.

Live from RE’08: The Towel Effect

The closing talk today was by Jean-Pascal van Ypersele from the Universite Catholique de Louvain-la-Neuve and Vice-chair of the IPCC working group 1. Say that 10 times out loud fast! Anyway, his talk was “Climage change: Challenges and Opportunities for Software Requirements Engineering”. In general, he discussed the background science behind the warming trends they have measured, and I by no means am going to try to recreate that here!

But I had a couple of interesting take-away thoughts. He discussed what we call the “towel effect”. I’m sure everyone has seen the signs in their hotel rooms suggesting to save resources by reusing your hotel towels. He suggested the results of a study on the effectiveness of such programs would be interesting. Partly because he thinks the presentation of the program is usually quite awful, most people probably do not participate, and even if they did, what kind of impact does it actually have? Dan Berry made a comment that he very much tried to do this in every hotel he stayed in, and yet not once did the cleaning staff save his old towel – they always gave him a new one anyway. Anyway, the speaker’s point was this is a marketing program by the hotel to look better, but proposes that they may not be terribly effective programs for actually helping the environment.

And the other more relevant take-away discussion is – what can we in RE do? Can we help come up with good solutions that solve the towel effect problem? But there really is an interesting large scale system problem here – there are many different stakeholders with variant priorities – how will we ever align them to do the right thing for the environment (whatever that “right” thing is!). You have companies who want to make money and reduce costs. You have individuals who want to recycle everything. You have governments who need to look at their global position on this, find money to fund projects, and of course they have to be elected. The point is there are a lot of different interests, so it’ll be interesting to see if we can come up with solutions that are accepted by all users.

For more related thoughts, see the green post: part 1 and part 2.

Live from RE'08: Creativity Workshops

Neil Maiden presented a paper Use and Influence of Creative Ideas and Requirements for a Work-Integrated Learning System by Sara Jones, Perry Lunch, himself from the University of Manchester and Stefanie Lindstaedt from the Know-Center.

The basic premise behind their paper is that there is an issue with elicitation, in that it assumes that the users know and can articulate what they want. They’ve integrated creativity workshop techniques to address this.

In short summary, they ran a two-day creativity workshop with 16 stakeholders, 1 facilitator, and 2 scribes. Through the workshop they do divergence and convergence of ideas, repeated several times over. I believe the idea is that people come into the workshop with some narrow ideas, so you broaden those ideas. Then in time you converge them back down to something more specific and useful. Some of the techniques they used include:

• Round robin brainstorming, using creativity triggers
• Constraint removal – a systematic technique to remove constraints, even if it is not feasible to remove them for real, but pretending they aren’t there allows for more creativity
• Solution presentation – use technology ideas they already do have to inspire new ideas

They did quite a bit of data analysis and at least can show some tentative amount of “creative ideas” came out of these workshops. Either way, I do think this is important. It reminds me of the work by Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann, which we’ve had some success with.

Live from RE'08: Recreating Industry in an Academic Course

I wanted to spend a few minutes writing more about the first paper from this morning, again that was Requirements Engineering Education in the 21st Century, an Experiential Learning Approach, presented by Gil Regev. In his talk, he described the design of their Requirements Engineering masters course. This class effectively simulates an end-to-end practical project for the students. In the last 2 years, they increased the time spent in this project on the business, RE, and specification topics from 7 to 11 weeks of the course (out of 14 total weeks).

He goes on to explain that industry is full of “wicked problems”, where the problems are difficult to define for all stakeholders, there are no clear stopping rules, they have strong moral/political/professional dimensions which cannot be easily formalized, and there is often no objective measure of success. Their course design is a bit unconventional – which I love – the intent is to reflect industry realities by maximizing confusion, not giving the rules of the game out, and stating goals that are not the actual learning objectives. Also, they do not grade the experience in order to create an active fearless learning.

They give the students vague a problem statement around management believing sales are suffering because of customer support problems. The instructors play the part of subject matter experts, going as far as to dress in costume to clearly separate their role as non-professor. They point out this probably does requires business savvy instructors.

In the end, the students say they would have done better if they knew the rules, if they had theory about RE before they did the exercise, and the course is chaotic. If only! Though at least one student shared a retrospective in which she recognized after the course while working at a company, that this course was in fact simulating the real world.

This class is going to be very hard to replicate in industry (as a training), since it takes 14 weeks and 6 hours a week. And even for the instructors, it is very time consuming to teach it – partly because they play the role of subject matter experts, and partly because they need to do some amount of redesign every year on the scenario so that students don’t hear ahead about how to do the exercise – as it would take away from the learning.

All that said, I like it. I like that they are trying to recreate an industry problem and teach it in academia. And sure, they can’t simulate it exactly, but this is one of the better attempts I’ve seen at it.

Live from RE'08: Learning Research

This morning, Mike and I attended the Learning Research track where we heard 3 research papers presented on the topic of learning.

The first paper was Requirements Engineering Education in the 21st Century, an Experiential Learning Approach by Gil Regev, Don Gause, and Alain Wegmann. I’ll talk more about this one in my next post.

We also saw Gameplay to Introduce and Reinforce Requirements Engineering Practices presented by Renel Smith and Olly Gotel from Pace University. This is based on Renel’s research which lead him to develop a game called RE-O-Poly, to be used to train students on some basic requirements knowledge. In case it’s not obvious from the name, it is based on the game Monopoly. I've been watching Renel's progress on this over the last year and it's nice to see the game growing. I'm certainly a big fan of using games to train, so I think there is some interesting work here.

Finally, Thomas Alspaugh presented Marginal Notes on Amethodical Requirements Engineering: What Experts Learned from Experience by himself, Susan Sim, and Ban Al-Ani. This talk was based on interviews and survey they did in 2006 of various RE’s – what their most important skills were, experience levels, etc. The 5 themes that came out of their feedback were: spanning bridges, communication, selective process, doing less, and business value.

Live from RE’08: Learning Days for Us

Yesterday was the Requirements Engineering Education and Training (REET08) workshop and today was the beginning of the main conference. So when I say they were “learning days”, I mean more than 2 days of us learning - I also mean that most of the talks we heard were about learning, a topic near and dear to my heart.

Mike summarized the workshop well, however he neglected to mention the talk he gave during the workshop. He presented our paper titled “Effective Design and Use of Training Games”. This talk was about specific games we designed for our Req101 training course. Given the nature of the workshop, he was able to actually play one of the games with the participants, and they absolutely loved it. In fact, some of the participants are looking to use the game ideas in their own training programs. One of the neat things about this year’s workshop is we spent end of the day sharing classroom activities with one another for reuse. I had co-chaired this workshop with Jane Cleland-Huang from Depaul University in Chicago and Didar Zowghi from University of Technology, Sydney Australia - so it was really exciting to see it finally come together and have so much participation (25 people!).

Today’s first session was “Training & Lessons Learned”, with the first paper presented by Brian Berenbach on a survey he did of a requirements engineering training program he did at Siemens. He was able to survey the students quite awhile after they took the course, which in itself is a neat thing – to find out what the students found most useful to them from the training course. This would be great data in order to influence the design of your courses in the future. The last talk of the session was by Sascha Konrad, also of Siemens and was about the challenges and solutions of doing requirements engineering on large-scale systems. The challenges they face at Siemens are certainly common to many large organizations – for example, there are many requirements to be managed, their customers’ expectations can be hard to manage, and the teams are globally distributed. And the talk in the middle was actually my talk, based on a paper I wrote with Mike, titled “Games-Based Requirements Engineering Training: An Initial Experience Report”, in which we describe the learning theory behind using games in training and talk about specific games and experiences from our visualization course. The talk seemed to go over well, and I got some interesting questions.

• If you have large teams in your activities, how do you deal with the problem of some people checking email or wandering out of the room and letting the rest of the team do the work? The short answer is that you talk to them individually if it happens. But at the core of it, we are using games in our training in order to avoid this exact problem – we want the students to be so engaged that they want to be there.

• Have you used the games internationally, how well does that work? We have not done much internationally. One of our courses uses Jeopardy, and we did teach it internationally. They understood it but were not as excited by that particular game. However, over the next few months we’ll be internationalizing our courses, so we will have more to say shortly.

• Have you thought to use different types of members of the audience to play different roles in games (i.e. RE vs developer)? We have not. We do have different types of audience members, but typically they are all there so they can learn to speak the same language about requirements, not to use the content differently per se. That said, there is a possibility to do this, but I would have to give it more thought. And we do one exercise in our Req101 class that does actually put the students in the role of a developer.

• What is Jeopardy? (this was a follow-on to our discussion about using games internationally from someone non-American) We laughed at his question, as it made exactly the point about international audiences not understanding USA game references. Most of our games are not actually based on US games, though some are and will need altered. But to answer this, I did explain Jeopardy.

The final session of the day was the panel on “Transforming the RE Classroom Experience”, with Jane Cleland-Huang, Don Gause, Olly Gotel, Zhi Jin, Pete Sawyer and Didar Zowghi. They each presented a snip-it of information about their university courses and then opened it for discussion to the group. My favorite question was (and this is biased since I asked it), how did Jane change her classroom activities for her distance learning (DL) students to be able to do them. She records the courses and they watch it online the day after the in-course stuff. And it turns out she does let the DL students watch the activity performed by the local class, so that they can learn from the local experiences. She then asks them to do the activity on their own. Her feedback has been only positive from the DL students in how this works. There was also a good discussion around whether universities should teach current industry practices or new ideas from research – the consensus is that it’s mostly 80% current practices with a little bit of new to send out into industry.

All in all it was a fun-filled day!

Live from RE'08: Requirements Engineers are smarter than Rocket Scientists

Did you know that you're smarter than a rocket scientist? Seriously! In a presentation at the Requirements Engineering Education and Training (REET08) workshop today, one of the presenters talked about his experiences with teaching Requirements Engineering (RE) techniques to European space agency employees, most of whom had PhD's in math and/or physics -- actual rocket scientists! As part of the presentation, he said that those scientists said that they weren't able to do RE, and that it should be left to people who had those skills. So kudos, RE community -- you're smarter than rocket scientists!

In other (and only slightly less exciting) news from today's workshop, we heard a lot of great ideas from academics and industry professionals who teach the next wave of Requirements Engineers. Tony Gorschek presented his current conundrum in teaching RE, namely that he has only 5 weeks of instruction time to deliver the only RE course in his school's program. Which topics are most important? Do you teach students to write clear, concise, testable requirements, or do you teach them to be great product managers who understand business realities and can plan product releases accordingly? Yes, we did suggest that he teach both, but time constraints won't allow it. And appropriately enough, time constraints in the workshop kept us from discovering the answer!

Several presenters explained that they teach their programs' RE courses at or near the end of students' educational programs. The rationale for the placement of the classes is that students must understand how to be good software engineers before they can understand, apply and appreciate RE skills and practices. At first I thought this was the right order, but as the day went on and we heard about more and more challenges of this approach, I began to wonder if placing RE education at the end of software engineering education sends the right message. If something is as fundamental as we believe RE to be, then shouldn't we make it a fundamental (rather than a capstone) element of RE education? Would the answer be different if the RE courses were part of a different degree program, like Industrial Engineering or Information Systems?

Finally, we talked quite a bit about the disconnect between industry's needs and education's focus, including training both in academia and in industry. Education in RE seems to provide controlled, well-formed, somewhat artificial problems for students to solve. Unfortunately, most of the projects we deal with in industry are subject to political forces, impacted by fickle market conditions, and just plain messy. How can academia best provide Requirements Engineers with both the problem-solving skills and the ability to deal with messes needed to do their jobs well.

Clearly, we identified more issues than definitive answers, but also we came up with a number of great ideas and new tools to help teach Requirements Engineers (and improve our own work on projects). All in all, it was a very educational day.

It's been a great first two days at RE08 -- stay tuned for more exciting adventures of the Seilevel team!

Live from RE'08: Managing Requirements Knowledge, or RE as KM

OK, yes, it's a confusing title. But stick with me, and I promise it'll make more sense.

Welcome to Barcelona! Day one included the Managing Requirements Knowledge (MaRK) workshop. The presentations covered a WIDE variety of topics in Requirements Engineering (RE), some of which seemed directly related to Knowledge Management (KM). Many of the presentations initially appeared unrelated to what I think of as KM, but part of my interest in the workshop was to get a sense of what our community considers KM, so I stuck it out ... and I'm very happy that I did.

My typical understanding of KM is influenced by Information Science and corporate KM endeavors, in which the whole of a company's knowledge about specific topics is cataloged and managed in a central repository. So, I was expecting KM in RE to be similar. What I found, though, was that KM in RE is in many ways more fundamental to our work than KM is in my expected, corporate setting. Sebastian Meyer talked about automatically generating glossary terms from existing documentation. Joao Araujo presented research on automatically generating use case names, again from existing documentation. Jane Cleland-Huang and Oezguer Uenalan each discussed some initial work on using wikis for requirements elicitation. To me, these topics all seemed to be "everyday" RE, not specifically KM-focused.

What I was looking for was something new or different about RE practice, given the focus on KM. What I found instead was a new way of looking at RE as KM. These unique approaches may be focused on eliciting or generating requirements, but those activities are the first step in managing knowledge about requirements. By slightly changing my perspective on the topic and the work we do, I was able to see the entire RE process in a new light. Expect to hear more about RE as KM from these and other researchers.

One of my favorite parts of the day was the small group discussion sessions we had at the close of the session. In my group, we delved deeper into the use of wikis for elicitation, documentation and management of requirements. We got into some interesting topics of anonymity, power relations, and the role of the RE in the overall development process. Again, keep an eye out for Jane and/or Oetzger to give us more to talk about in the near future!

It's been a great start to the week, and I expect the remainder to be as insightful -- stay tuned!

Ask Joy:How Do You Know if Your Software Requirements are Testable?

From our Spring newsletter, we received a question to the Ask Joy column. Here's the question and response!

Question: “How do you determine if a requirement is testable and please answer in concise, understandable English.”

Answer: Hi Jon, I sat down to answer your question, and I honestly found myself a bit nervous about the second part of the it – in which you asked me to write in “concise, understandable English”. My first reaction was that I don’t know any other language well enough to pull off an answer, so the English part is easy. But my nervousness came from the concern that you may not think my answer is concise and understandable.

And there-in lies the problem, this question isn’t measurable in itself! When we use plain English, while it’s easy to read and get the gist of the meaning, it certainly is often up for multiple interpretations.

This is dangerous to software development, because if there are multiple interpretations, there is no guarantee that the solution will be what you asked for. Therefore, we should set out to write requirements that are precise, unambiguous, clearly understood…and testable.

So how can we then know if a requirement really is testable? Simply put, you must determine how you would measure the success of the requirement in the solution, and then decide if you were to actually measure it, that you would have a solid “yes” or “no” answer as to whether it passed or failed. If the answer is not black and white, then it’s not testable.

For further related reading:

Sometimes requirements are vague, and you can find more on this topic in a post that references an INCOSE 2008 paper on this very topic .

Roger Cauvin writes about the idea that requirements need to be testable in principle, but it’s less important if they are actually testable in practice.Scott at Tyner Blain further discusses why we care about testable requirements.

Just remember: in the end, it’s not really about the requirements and whether they are testable or not, it’s about the solution you get out on the other side.Thank you Jon for the question!
Please feel free to comment below if you’d like to continue the conversation.

A Product Manager By Any Other Name...Still Writes Requirements

When I was younger, I used to care a great deal about people's titles. Maybe it was my little brain's way of organizing people like I organized my Tinkertoys (teachers go over here, doctors are over here, mommies are in this section...). In any case, I believed that a person's title told you all that you needed to know about him or her. I had grand plans for my own title when I grew up. I decided to be a "Professional." "A professional WHAT?" I'd often get asked, and I'd simply reply, "Oh, I don't know yet -- but whatever it is, I want to be a PROFESSIONAL at it." The work didn't matter, but the title did.

Many people, as I did, place a great deal of emphasis on titles. On the Seilevel message board there are multiple threads discussing the differences between Business Analysts, Requirements Analysts, Product Managers, Project Managers, Systems Analysts, and even humorous entries like Requirementers, Information Vigilantes and 'Shall'icitors. In my career I've held the titles of Program Manager, Requirements Analyst, Manager of Requirements Management (say that three times fast), Business Systems Analyst, and Product Manager. I've done pretty much the same work in all of those jobs. Instead of worrying about what my business card says, I focus on doing my job well.

A recent example shows how other people may not share my perspective. During lunch a few weeks ago, a friend was describing someone he works with. "She's a 'Product Manager,' whatever the heck THAT is," my friend chuckled. But did she do her job well? Did she help build great solutions to difficult problems? I don't know, because my friend "checked out" once he got to her title. To him, the title might have sounded silly, or been unfamiliar, or been tainted by previous experiences with sloppy Product Managers, but it was all he knew of her. By focusing on her title, he had lumped his co-worker (and me, although he didn't know it) in with the rest of the silly or sloppy people he knew.

So what DOES a Product Manager (PDM) do? Product Managers outside IT typically focus on understanding their marketplace and seeing that successful products are developed and released to that marketplace. Within IT, a PDM has a similar role. He or she is responsible for the end user adoption of and satisfaction with a product. The PDM is also responsible for the return on investment of that product.

In IT, a product may be anything from shrink-wrapped software to customized tools created for use within an organization. The PDM defines or identifies the scope of the program, project or release by understanding it in relation to the related business objectives. The PDM elicits, models, defines, documents, reviews and baselines requirements. She or he also manages changes to the requirements, supports and often participates in user acceptance testing, and supports product rollout and adoption activities.

All of these responsibilities help ensure that the product released meets both the business objectives and the users' needs. Given the wide range and financial impacts of a PDM's responsibilities, what does it mean to do that job WELL? To me, the most important aspect of being a great PDM is taking ownership of and pride in your product. If you believe and act as though you will personally make this product a success, you will do a good job as a PDM. If others are getting frustrated with your constant involvement, your probing questions, and your unwavering focus on product success, you're on the right track!

Whether you're a PDM, Business Analyst, Requirements Analyst, or some other flavor of requirements professional, don't let the debate over titles distract you from doing a fantastic job. After all, it's your work that matters, not your title.

Live from RE'08 Begins

Here we are again, live at RE'08 this time. Like every other year, we'll try to do blog posts real-time. The exciting thing is that I have help this year, both Mike and Rob are here too!

Before we start the serious posts, let's cover what's happened pre-conference. We arrived in Barcelona Saturday morning and so far we have learned many new things:

• The shortest distance to the beach is over a hill. (and for the record, the CE guy disagreed all along)
• Mike now understands that Barcelona is IN Europe
• The torch from the 1992 olympics is no longer lit
• You can't buy liquor here after 11pm
• In a value meal at McDonald's, you can have a beer or Coke for the same price
• "Sin pan" is an important when traveling with me...and it brings about funny looks
• Mister Beatty can get Coldplay tickets
• La sexta does not mean what you might think it does
• People have jobs related to donkeys. Who knew!
• Rum and Fanta make a nice drink, we call it the Rum Fanta.

And in our "jet lagged" state, some stupid things have been said...

• Wow, these buildings look like the ones I've seen in Europe
• Are you using your phone to translate for the taxi driver?
• Hey Rob, passporte means passport
• No Mike, the people are not disappearing, it's a magic beam
• It's almost like we're in another country
• Get Mike to look it up on his watch!
• It's "September", but in Spanish Mr. Sparks that's "Septiembre. s-e-p-t-i-e-m-b-r-e. Septiembre."
• I'm out of pockets, give it to Mike
• "Oh! They do instant replay in some sport...let's see what is that?" long pause "You mean....football?"
• You mean Ron Paul didn't run in the independent primary?

All of that is fun, but the highlight of the trip so far is Coldplay (and only because RE'08 hasn't actually started yet!). We had seats in row 16, next to the stage - they could not have been any better!

After the concert, when there was no taxi to be found, we decided to follow the crowd. They were going downhill, after all! Beers in hand, we strolled through the streets of Barcelona, with a few stops along the way, rest assured we did get home again.

Cheers to an awesome first day in Barcelona, from us to you all!

Creating Accurate Time Estimates

I recently joined a new project where I will be working as the person responsible for the developing and creating the requirements and documentation on a major development effort. As the person on the hook for a significant portion of work, I need to provide accurate time estimates for my portions of the project. I was concerned about providing accurate time estimates on a new project in a new environment. I am also very aware that deadlines are important and know that if I am unable to accurately estimate my deliveries, I will quickly lose credibility with the rest of the team. Underestimating my deadlines might also put other team members relying on my work at risk of missing their deadlines.

My concerns had me thinking that perhaps others might be in a similar situation. After a bit of research and analysis of my own process I compiled the following list of questions and suggestions to help when making time estimates.

1. How accurate do your time estimates need to be?
   If an estimate needs to be very accurate, it is usually a good idea to take a longer period of time to consider and analyze the answer. It is not unreasonable to ask someone who is looking for a timeline for some “think time” in order to provide an accurate answer. However, when not immediately responding, it is a good idea to communicate a reasonable target for when you will have the estimates finished, even if it’s only 15 minutes of extra think time.


2. How well do you fully understand the project/tasks that you are being asked to estimate?
   If a problem is complex, or if you do not completely understand all of the tasks you need to finish, it will be difficult to make accurate time estimates. Getting as much clarification as you can is necessary. Discussing the details of what you have been asked to accomplish with the person making the request might also provide them insight into the complexity of the request and your work process.


3. How long has a task of this type taken to accomplish in the past?
   It is a good idea to maintain a personal log of tasks and an ongoing list of recorded time spent performing a task. I simply use an excel spreadsheet to record tasks I have finished on my projects and update it when I have a few moments at the end of the day or week. Having a realistic idea of the amount of time I spend on my tasks helps me to accurately predict future projects/tasks.


4. Are there any assumptions, conditions or constraints which might affect your time estimate?
   It is impossible to predict in advance every detail of a project with certainty. It will be important to note your assumptions and constraints when you provide your time estimates to communicate your issues clearly. These could all be considered risks to the accuracy of your time estimate and should continue to be monitored as you begin the tasks/project.


5. Do you need to add any wiggle room?
   You should consider adding contingency time if there is a lot of uncertainty about the tasks or many risks associated with your estimate. By increasing time to the estimate appropriately because a project is new and unfamiliar as a way to prevent underestimating your efforts.


6. Are there any other elements to the project/tasks that should be included in your time estimate?
   One area I consistently forget when creating estimates is the amount of extra time I have to spend doing administrative tasks like organizing meetings, sending emails, or organizing documents. At times, these types of activities are not always predictable, but understanding how much of your work might be effected by other project duties is important. There is a small amount of extra administrative work in most tasks, and adding that into your work estimate will help your estimating efforts.

When I employ these methods they have lead me to more accurate time predictions that have also greatly reduced my anxiety over creating self imposed deadlines that are unrealistic. As I also have an intrinsic desire to please the person asking for my time, using some standard processes in producing my time estimates has lead me to win/win situations for both my project and myself.