What do you do when the client isn't focused on the business outcome?

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don't feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I'm changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn't worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn't want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don't necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the "unnecessary" features, but ultimately it is up to the client to decide if the business case is really the highest priority.

RML™ Requirements Model 5 - The Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) is a very useful part of the Requirements Modeling Language (RML™). The Structured Analysis Wiki contains a great explanation of how to create a DFD, so I’m not going to cover that information here. Instead, I’m going to provide one answer to the question “How do I know when to use a DFD?” This answer comes from my own (unique) view of the world, so some of you probably won’t relate to it, but others will--I’m sure there is at least one more out there…

Sometimes I have what I think of as an "equation" in my head. In vague terms, I may be thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”. But that's not really right, nor is the equation a good representation of the information.

And, the “equation” also misses a few other particulars about creating an order that I’d like to convey: Sales Reps update customer data, the Finance staff maintains the rules for the tax calculations, and orders flow to the Order Fulfillment system after creation.

The data flow diagram is great for representing all of this. Here’s my “equation,” expressed as a data flow diagram:

I have found that business users, as well as developers, react well to this model—it provides a “big picture” with which to begin a conversation about creating an order. It paints exactly the picture I want to convey and validate when I’m thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”.

Display this picture, and you’ll get some interesting questions and comments:

• How is customer data populated initially?


• Does the order fulfillment system update the order store with information about the fulfillment of the orders?


• Where does the product data come from?


• Are all of the tax rules manually entered, or is there also an electronic source for them?


• And, maybe, “No, that’s wrong, updating customer data isn’t a separate process. Customer updates need to automatically flow out of changes made when creating the order.”
  

One note: it doesn’t have to be technically perfect to be useful. I often provide “conceptual” DFDs, in that I intentionally provide conceptual, but not technical information. For example, conceptually, there is a “products” data store. Technically, there may be multiple stores: product list, product descriptions, etc. The important thing is that they work together to provide product data. Developers and architects are very receptive to this; they understand I’m illustrating the behaviors of the system without defining the implementation (which, after all, is their job). Oh, and how does the audience know it is conceptual? I put the word “conceptual” in the title!

You may notice I didn’t number my processes. That’s because I rarely decompose them and many people tend to take the numbering as ordering. So, for my usage, numbering adds confusion rather than clarity.

Happy diagramming!

Related Articles:

How To Choose A Software Requirements Model

Six Requirements Models For Agile Projects

What does "requirements sign-off" mean in agile?

I was recently working with a cusotmer on a project using an agile methodology. The organization was moving towards trying to do most of their projects in agile, so the nature of this is that they have a lot of non-agile pieces to their methodology still in place. We were cruising along in defining requirements and development was well into the first sprint, when the project manager told me we had a target date for the requirements to be signed off.

Wait a minute! Hold your horses folks! Sign-off? In an agile project?

I took it upon myself to remind her of the development methodology of choice for our project… and that she was asking me about sign-off in a methodology where it doesn’t really make sense…. one where the users have the right to prioritize whatever features they want in the backlog at any time. So if they forgot some features during our elicitation process, then that’s ok, they just need to figure out where to put it in the prioritized backlog, realizing something else may drop off. She laughed immediately reassuring me she hadn't lost it and that she understood completely, but the corporate process required this! So we began the discussion of what a “sign-off” would mean to us.

In the end, I think we got pretty creative with it. We did have lots of requirements in the form of user stories and other models like process flows, state tables, etc. And we were working closely with the users to elicit and review them. So what we asked them to do was to “sign-off” that at that moment in time, there were no major requirements missing, that they knew about, and there were no major issues with what we’d written down, that they knew about. The key is this means that they did in fact look at them, they participated in the activity and so development is not developing a prototype of something too far off basis. But it also keeps open their right to realize something new they need after they see it, think about it, sleep on it, or whatever.

What I really like about this is approach is that it doesn’t force anyone into a corner where they feel like they are signing away their life over a massive requirements document that they barely understood or that they are signing on a dotted line to say they are mostly perfect and got it all the first time around. So more or less, I think our version of sign-off allows the spirit of agile methodologies to prevail still.

Lessons from a Bad Haircut

I got a lousy haircut the other day. I’m not happy. And, one of the things I’m least happy with is the fact that I can trace one comment I made to what ended up happening. I still hold the hair stylist responsible, because she’s the expert. I left something unspoken related to the comment, so what I said in total was inconsistent. She should have asked the questions to get it right. She should know that lay people use industry terms incorrectly and she should be restating what she is hearing to make sure her understanding is right. She’s the expert.

It’s made me think about how I do my job. I’m the expert. I do ask questions. I do present information in multiple formats—diagrams and words—to make sure I convey what I heard and get it right. Still, reminders can be good. My lousy hair cut reminded me: even when a person appears to know what they’re saying, they may not. Or, they do know; their use of language is just different from mine.

Next time I’m tempted to accept an answer on face value, I’m going to remember my bad haircut. Because, while my hair will grow back in 6 weeks, bad software can last for years.

Live from REFSQ: Deriving Information Requirements from Responsibility Models

Tim Storer from St. Andrews University in Scotland presented this paper. His underlying assumption is that in large scale socio-technical enterprise systems, you are constrained by the design of the platform you select, integration to other systems, and systems of systems factors. He contends that the functional requirements in these projects are more useful in the procurement process where you select the system to implement, and specifically less useful in the actual implementation. The reason for this is that the system is already constrained by behavior based on what you select. While I don’t entirely agree with the de-emphasis of functional requirements he implied, his overall point is absolutely valid in that you often are in a situation where you must configure the system and adapt business processes around the system.

This paper discusses how beyond the functional requirements, you also need what he calls “information requirements” which help you to configure the purchased system for the given context. These requirements tell you:

• What information is needed


• Who needs the information


• Who produces information for the system


• Flexibility for access to that information


• Consequences of incorrect information flow

And these requirements influence platform configuration, organizational changes, and system integration.

To identify these information requirements, they use “responsibilities” as a starting point. They have defined “responsibility” as “a duty, held by some agent, to achieve, maintain or avoid some given state, subject to conformance with organizational, social, and cultural norms.” They are not goals, but rather more abstract and less formal. They are not concerned with specific types of agents. Then for each responsibility, they determine the resource needs, ultimately leading to information requirements.

In his example, a self service check-in terminal has responsibility of “provide boarding pass”. Then they can look at the resources needs– blank tickets, ticket database which is fed by ticket server, etc.

For the information resources, you then have to look at what happens if it the resource is unavailable, inaccurate, incomplete, late, and even early. And ultimately you get to the details mentioned above to form the information requirements.

What I found useful in this paper is helped validate some of our own thinking we are applying on projects in that we look at something very closely related with data requirements. We’ve written before about our People, Systems, Data (PSD) approach to discovering all requirements using visual models from RML™. In this case, if we break down the Data component of PSD in combination with the People component of PSD, we have something very similar to what Tim spoke to. Very briefly, we use the People models (e.g. Org Charts) to identify the people using the system and then look at what stories they need to execute in the system (e.g. User Stories). Now we can also look at the top-level data model (e.g. BDD – a Business Data diagram), and for each data entity in the diagram, we look at how it is:

• Created


• Viewed


• Changed


• Removed


• Copied


• Moved

(And yes, I deliberately did not call out the CRUD because I’m not a big fan of the acronym!). In doing this, we can actually complete the list of user stories and identify system integration points. Similar to above we would also use the user stories to cross-verify the BDD was complete. Our data actions closely map to the list in Tim’s presentation:

• What information is needed -> the BDD entities


• Who needs the information -> Who views it, changes it, copies it, moves it


• Who produces information for the system -> How is the data entity created


• Flexibility for access to that information -> Who views it


• Consequences of incorrect information flow -> exceptions in the stories that come out of the list

Now in a recent example, we were working with a system that we did not know well. There were six main data objects and a list of about 10 user stories for the system. I wanted to validate whether the list of User Stories was complete, so I proceeded to walk through each of the 6 actions above against each of the six data objects. Not every data object could have those actions performed in the system, but it was useful to deliberately check each. In the end we identified about five new User Stories.

Live from CAiSE'09: The Science of the Web

The opening keynote for CAiSE'09 was Nigel Shadbolt from the Web Science Research Institute. This organization was started in 2006 to try to understand the science of the web and anticipate future developments and threats. It most certainly was a real pleasure to hear Nigel speak. More than proposing answers, he proposed the types of interesting questions they think about with regards to the science of the web.

One fun question he spoke to with regards to the science of the web is to think about how you handle the dynamic characterization of it? Perhaps it is changing faster than our ability to observe it, so literally how do you measure the web?

As an interesting demonstration of the power of the internet, he mentioned an article in Nature that looked at using Google search trends to track flu outbreaks. Apparently, when a flu outbreak happens, physicians report data to the CDC and it takes about two weeks to turnaround a plot these outbreaks. Google used its search trends around flu related phrases and was able to build a model that tracked the actual instances of outbreaks. When they retrofitted this data to actual historical data from the CDC and saw it highly correlated. Instead of two weeks per outbreak, it took them a day to do this analysis.

While I don't think this talk was terribly relevant to requirements (though much of their work is), it was still an enjoyable discussion. You can listen to a similar talk by Nigel here.

REET'09 Workshop - Call for Papers - Due June 29

This is just a reminder that the REET09 workshop, held in conjunction with IEEE's Requirements Engineering 09 conference, is in Atlanta this year on August 31!

I'd like to encourage all of you to submit papers or training activities related to educating people on requirements! If you don't feel like you have enough to do a paper, you could even just submit a fun activity you've done to teach people about them. Here is the workshop site with more details, but the important one is that papers are due June 29.

http://users.cscs.wmin.ac.uk/REET09/

If you aren't interested in this workshop, the greater RE'09 workshop should be a big one being based in the US this year, so I hope to see lots of you there!

Live from RESFQ: The Requirements Object Model (ROM), part 3

Today we have an example to illustrate what I’ve said in the past two posts from Tuesday's setup for the ROM and Wednesday's definition of the ROM.

Let’s say in this scenario we have an online gaming company that historically has only built complex role-playing games. Now let’s say the head of product management wants to build a Yahtzee game. Here’s the process to go back and figure out what the problem is that someone thinks Yahtzee will solve, working our way to the top until we get to a Business Objective.

Note the problem at the top of this diagram finally becomes one that relates to money: The competition is still growing and we aren’t. And the business Objective can now be written to quantify the desire: 25% growth in markets other than 15-30 year olds.

Now that we have a business objective, we can define strategies. There may be 5 or even 100 business strategies and someone must select the ones to be implemented. In this case, 2 possible strategies include building a game for 7-13 year olds and advertising to the retirement community. Out of that, we can believe that Yahtzee is a valid product concept, as long as they develop it to target that 7-13 year old user group.

Finally, we can complete the rest of the ROM by crisply defining our product concept (Online Yahtzee), success metrics (7-13 year olds rate the game fun), and guiding principle (create a social environment). Then we can take on the fun task of defining features that fit within this definition.

If you follow this approach, you will have a constant guide in your Business Objectives to ensure that you are creating features that you need, but only features that you need, to achieve the business value of the project.

Live from REFSQ: The Requirements Object Model (ROM), part 2

What follows is our ROM defined. For context, you can see yesterday's post on why we have a ROM now at Seilevel.





Definitions for the items in the ROM hierarchy:

• Business Problem: Describes a problem to be solved.
• Business Objectives: Desired metrics the business seeks to meet in order to solve the problem.
• Business Strategy: Approach to meet the business objectives. It is not specific to any one product or project solution.
• Product Concept: Proposed solution to follow the business strategy to accomplish one or more business objectives. This becomes a project.
• Success Metrics: Statements about the specific desired outcomes to meet the business objectives.
• Guiding Principles: The approach to meet the success metrics for the product. Common themes to be considered in creating a product. These will drive the feature set and specific requirements.
• Product Features: A collection of functionality that provides a set of services to the users.
• Product Qualities: A collection of desired qualities about the product.

Features and Qualities are derived from business objectives.

The important thing is that your features should trace from your Business Objectives. And in the end, if you cannot make this leap directly, then you use the product concept, success metrics and guiding principles to help define them.

To that point, most projects actually start with a product concept. The team might define success metrics (i.e. a launch date). But they quickly jump in to defining features and qualities and then requirements and design. There are no agreed upon Business Objectives and development strays from the intent of the project. If we lived in a perfect world, we could start with the business level problem and objectives, then define the product level, and out of that define the product requirements. But having worked with many customers, nothing is ever this clean.


So instead, we suggest you do start with a product concept if you have one, and put any pre-defined features aside. Then work back up from the product concept to understand what problem it is supposed to solve. Continuously ask “why is that a problem?” until you find a problem that relates to money and write your Business Objectives at that level. We make it this simple so that you clearly know if you have gone high enough to say you have defined Business Objectives. The reality is that most (if not all) businesses exist to make money so all of their objectives relate to that goal – either in the form of increasing revenue or decreasing costs. Before I go on, I will say that every time I speak about this topic, someone gasps in the audience when I make this claim. That said, we have yet to see a project that doesn’t relate to money (and that’s not to say they aren’t doing other good things too!).

Once you have good Business Objectives, you can determine appropriate strategies to meet them. These strategies may or may not include building software products. But if they do, then you write a clear product concept that may or may not look like your original one. Then you continue through the ROM, developing success metrics and guiding principles for the product. Again, realize that the features may have changed from the original suggestions, in order to map back to actual objectives.

A quick example for today, but tomorrow I’ll give a more complete example:

• Proposed feature: Online training
• Problem question: Why do we need online training?
• Problem answer that relates to money: Online training leads to more trained users. More trained users leads to more sales. Now we can relate this to revenue!

Live from REFSQ’09: The ROM, Experiences with a Requirements Object Model

What follows is a summary of the paper I wrote with James Hulgan (also from Seilevel) and presented at REFSQ’09 last week. The paper is titled “Experiences with a Requirements Object Model”. You can get the actual paper here.


Most software projects we’ve seen develop features that don’t add value or they don’t build what they actually do need in order to achieve the intended business value. This leads to project that are over budget, late, and often canceled because they don’t really satisfy the needs. Fundamental to this, most project teams don’t know the Business Objectives that tell them why they are doing the project in the first place, so it’s not surprising they have a hard time picking the right features to develop.


Business Objectives are hard to elicit. When teams get an answer like “increase profitability” they are complacent to stop there because they don’t want to or know how to push people to give the hard answers.


Our paper discussed the basic terminology as described by many industry experts to describe this “thing”. They use business objectives, goals, needs, business requirements, user requirements, etc. And there are subtle differences behind each of these from person-to-person. But for our work, we are using “Business Objective” to mean: the desired metrics the business seeks to meet in order to solve the business problems.


Terminology is just a small part of the problem, but the bigger issue is this: If you ask a project team why they are doing this project, they often have no concrete idea. They may have a vague phrase associated with it such as “We are reducing operating costs”. Sometimes we hear them say that they are sure the executives know because there was a business case developed – but the project team has not seen it. It’s as if you can develop the business case, start the project, and never need to look at it again. And this is where the problem lies. The Business Objectives, probably in that very business case, should be driving the feature set developed.


We were looking for a model to use to identify and represent these, as well as to train our people on to elicit them. Out of that came the ROM – Requirements Object Model.


Tune in tomorrow for a description of the ROM!

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.

Live from REFSQ’09: A Quantitative Assessment of Requirements Engineering Publications

Al Davis from the University of Colorado at Colorado Springs presented "A Quantitative Assessment of Requirements Engineering Publications from 1963-2008" that he and Ann Hickey (of the same university) put together as an assessment of the current volume and trends in requirements engineering (RE) publications. They have taken on the huge task of creating a bibliography of all RE-related papers they come across. Al started this back in 1989 for his Software Requirements: Analysis and Specification book in 1990 and has been updating it ever since.

You can find the full list of RE publications here.

Some stats that I found particularly interesting from his analysis (as of the data in 2008):

• Approximately 5200 papers on REo 5973 unique authors
• Today 10% of the authors of these papers are new to RE, 10 years ago this number was 40%
• About 1/3 of all countries publish
• The main conferences we publish at are: IEEE Requirements Engineering, INCOSE, REFSQ, IEEE COMPSAC, IEEE ICSE, IEEE HICSS, CAiSE
• The top few periodicals we as a community publish in are: Springer RE, IEEE SW, IEEE TSE

Regarding the number of new authors to the field – I would be curious to understand what it looks like in related domains, for example all of software engineering. They propose a series of questions in the actual paper about why this may be the case. From a relatively “new” perspective, I will say that I continue to see more-or-less the same program committee members reviewing papers year after year, so I do have to wonder how much that plays in. But I also know some of them personally are excited to see new authors submit, so I have to believe they are trying to accept those papers when they are worthy.

And finally, this is quite interesting to wonder about – within country trends, they found that as a percent of the total publications the EU is increasing and the US is decreasing (quite significantly at about 10% over 2 years). So my comment to my European colleagues – well done! And my suggestion to my US colleagues - Let’s write!

For more interesting data and trendes, I encourage you to check out the actual paper.

Live from REFSQ'09: Inventing Requirements with Creativity Support Tools

This paper was presented by Kristine Karlsen of City University London, UK. She started with the statement that requirements elicitation should be a creative process. The stakeholders know their problems, but they don’t necessarily know all of the possibilities to solve those problems. Her research presented here is based on the idea there is a lack of tools to support this creative elicitation process.

In her study, she used existing techniques: web-based scenario walkthroughs and storyboarding first (using their scenario tool, ART-SCENE). Then she used a combinatorial tool that relied on inputting scenario phrases into a search tool that then searching the web for images and text. The person literally sits and watches pictures go by, waiting for some new idea for a requirement to be triggered for their scenario.

The new requirements were then evaluated by SMEs so to their novelty and usefulness. She found that this process certainly doesn’t work for all types of analysts in that some people didn’t use it as well. They actually generated fewer requirements using this process than not (though arguably they had already generated the obvious ones so I’m not sure the point of this result) but they suspect that they did generate more novel requirements. This last point was certainly a point of question. She doesn’t believe they have enough results to say it’s conclusive yet but some of the participants in the conference asked questions about who defines what “novel” is.

Whether or not this particular idea is right is less relevant to me. Her original assumption though is very relevant that what we do is a creative process. I think it is what differentiates a true product management from someone who just elicits requirements. In the absence of a tool, there are various materials out there on how to put people in a creative mindset and do activities that inspire innovation (for example: Luke Hohmann’s Innovation Games: Creating Breakthrough Products Through Collaborative Play)

Live from REFSQ'09: Scenarios in the wild: Experiences with a Contextual Requirements Discovery Method

This paper was presented by Norbert Seyff from City University London in the UK. I’ve met Norbert at previous conferences and heard many talks on this topic by him and his colleagues over the years, so I’m getting to see the research evolve over time which is interesting. Often we hear about research in a very early stage with a small set of data, but then nothing else – maybe the rest all die off?

Anyway, they have a tool on a mobile device that allows you to elicit requirements in the field. The tool provides suggested questions to ask and lets you document requirements while being mobile. In this study they took to the Australian Alps to gather requirements for a ski navigation tool in context.

In previous studies, they found it was hard to interact with stakeholder while using the mobile device so it required two people – one to document and one to facilitate the interview. They have now had an improved ART-SCENE CoRE that allows just one analyst to do the work.

Their results included:

• They discovered new requirements that were not discovered in a workshop.
• They discovered fewer business goals than in the workshop
• One analyst was able to walk uphill and gather requirements!!!
• In answer to whether it allows you to generate requirements at a higher rate, the results were inconclusive because they had to shorten their elicitation time.

To the point that they didn’t develop business goal requirements in the field, one participant in the workshop suggested that this may be a result of focusing on system design in the field and Norbert thought that was a reasonable guess. I would need to think through that further – but Norbert added you likely can elicit these business goals ahead in a workshop setting (not onsite); there is no reason to just use this method. Further, a participant in the audience suggested combining this type of work with the concepts I presented in earlier sessions to really understand the business objectives ahead of being on site and prioritize after. So the mobile device idea is really focused on elicitation of detailed requirements but it is not the end-all-answer.

There were interesting observations around working in a field environment:

• There were unexpected and critical delays in using snowshoes to get around!
• The mobile device batteries died in the cold air.
• As a nice take-away from this, if you are going to elicit requirements in the “wild” (i.e. you aren’t sitting at a table in a room together), you really need to know your environment and plan for it.
• Paula Laurent in the audience commented that you really should try to test your environment ahead of time if you are going to do any work in the field.
• Paper-based method didn’t work well because of the gloves they had to wear to stay warm.

I’ve honestly always been a skeptic about the applicability of this research (and I say that with also saying I have the utmost respect for Neil Madden and his student’s at the City University of London!). That said, each time I see this work presented, I’m more intrigued and a slight bit more of a believer.

For most of the work we do day-to-day, I don’t foresee the mobile device helping. Most of our projects which are not meant to be representative of all software projects, are creating requirements for systems where the users’ environment is typically “a desk”. I can pull up a laptop and use my usual tools to do this type of elicitation. That said, I can think of a few times where I was trying to manage a taking notes in a notebook while walking around with users. These situations included things like navigating a catalog call-center going from person to person for a few minutes at each, walking around a semiconductor fab noting how the various tools operate, and finally and most interestingly – getting on to and off of military cargo planes trying to take photos and notes in the small area of a cockpit! In all of these cases, a laptop wasn’t feasible, so I had to resort to paper and pencil, which slowed me down and was still hard to manage writing on – particularly when I had no surface.

So anyway, as it is every time I hear it, the research is very interesting. And it tends to be the case that this group has very engaging presentations which isn’t always the case in this wonderful world of requirements engineering!

Live from REFSQ'09 Begins

This week I’m at the International Working Conference on Requirements Engineering: Foundation for Software Quality (REFSQ’09) and the Conference on Advanced Information Systems (CAiSE’09) in Amsterdam. The first two days are at REFSQ where there are just over 30 experts in requirements engineering in attendance, primarily from academia and a combination of Europe, USA, and Canada. It’s been great fun to catch up, share ideas, and find new collaboration opportunities with colleagues in the field. And after a few years of attending conferences with many of the same people, it’s really quite fun to develop a community of friendly people who I look forward to seeing at each conference.

I’m actually here to present a paper I co-wrote with James Hulgan, also from Seilevel titled Experiences with a Requirements Object Model (our ROM) - more on that a bit later. And as always in my “Live from…” posts, I’ll post a few summaries of talks or inspiring ideas that come up this week.

The format of the REFSQ workshop is really one of my favorites. Only about a third of the workshop is spent listening to presentations, with the rest focused on discussions inspired by those presentations (or other random stories). For each talk, there is a template for the last slide that everyone follows, including:

• Which quality features are addressed by the paper?
• What is the main novelty/contribution of the paper?
• How will this novelty/contribution improve RE practice or RE research?
• What are the main problems with the novelty/ contribution and/or with the paper?
• Can the proposed approach be expected to scale to real-life problems?

Then they have a discussant assigned to each paper who also read the paper, and this person presents answers to these same questions from their point of view about the paper. And this leads us into the Q&A or discussions.

As a side note: In case you don’t know how to say REFSQ, it rhymes with “rescue”. In fact, every time I hear it said here, I think they are saying “rescue” instead of “refsq” and perhaps this is a sign of what we are doing here!