July 1, 2011 – Last week’s INCOSE International Symposium was refreshing. The sessions and events offered great opportunities to network with other industry professionals interested in systems and not just software, and I joined some useful tutorials in systems engineering. I’m still distilling my thoughts on “systems engineering vs. software engineering”.
Participating on the “Is Requirements Engineering Really Necessary?” panel with Brian Berenbach, Mark Sampson, and James Hulgan was great fun. We don’t have the official session survey ratings yet, but we drew an audience of several hundred who never ran out of questions for us. My top 3 takeaways from our discussions are:
- Emphasize activities, not titles. The more stakeholders and team members who understand and can use Requirements Engineering methods effectively, the more the system and business will benefit. RE advocates have to remember, though, that most systems engineers aren’t, and don’t want to become, “requirements engineers” or even “requirements analysts”. They are committed “control systems engineers”, “electronics engineers”, “software system engineers”, or “power systems engineers” who are passionate about their own domains of expertise. To be most useful, training in requirements elicitation and analysis should be aligned to their domain worlds, instead of expecting systems engineers to align with the world of RE.
- System requirements need systems thinking, too. How formally requirements are managed should depend on the risks and consequences – not all requirements are “created equal”. Likewise, how requirements are documented should depend on who they are being documented for – the audience who needs to understand and use them. With today’s increasingly complicated systems and escalating time-to-market pressures, the same old mountain-of-text-documents approaches don’t scale; we need to adapt, and start ’system-engineering’ how we handle our requirements to fit the needs of the business and the system.
- No silver RE bullets. Requirements engineering isn’t a panacea that can solve any and all problems in a system. Requirements aren’t mushrooms to be “gathered” for analysis. They’re more like truffles that need to be carefully searched-for and unearthed. RE techniques can help you find the truffles and ensure that key needs aren’t overlooked. And RE can help you analyze and manage needs to ensure that requirements are well-defined, prioritized, verifiable, and necessary. RE can’t guarantee that you’ll never miss a requirement, include extraneous features, or misinterpret an important aspect. Using a mixture of senior and junior staff can help: experienced people are guided by the pain that came from overlooking key requirements or quality attributes in the past, and junior people can help the team avoid “expertosis”, by questioning assumptions and asking “why?”.
(My “point of view” slide can be downloaded from the Agile Teams website, as well as my 1-page position statement.)
ICGSE 2010 will open today with a keynote by Len Bass of the SEI architecture team, titled “Speculation on Coordination Models”, and will close with a technology panel including Len on “Impact of Future Communication Technology on GSD”. I’m definitely looking forward to both.
In between, the schedule holds a single track of sessions on:
- Tools I: Support and Use
- Processes and Practices
- Management Environments I
Yesterday afternoon’s agile GSD tutorial was interesting and offered a nice preview of Erran Carmel’s forthcoming book, as well as a review of Yael Dubinsky’s HOT framework (humans, organizations, technology). However, I was a little disappointed that more time wasn’t spent on the GSD challenges of implementing specific agile practices. (It could have easily been a full-day session.)
While waiting for the keynote session to start, I enjoyed a good chat with Darja Smite of BTH, who gave yesterday’s REMIDI talk. It turns out that we have similar views on measurement in GSD, as well as knowing some mutual friends/colleagues in Sweden!
Looking forward to a full schedule at ICGSE 2010 today:
* 90-min REMIDI workshop (Tool Support Development and Management in Distributed Projects)
* the first part of the PARIS workshop (Methods and Tools for Project/Architecture/Risk Management in Globally Distributed Software Development Projects)
* after lunch, a half-day tutorial on “Implementing Agile Software Development Across Time Zones”.
The conference also includes a full-day tutorial on “Requirements Engineering for Large Systems-Processes and Tooling”, a doctoral symposium, a half-day session on “What Did You Say? Cultural Influences on Communication and Understanding”, and the KNOWING’10 workshop on knowledge management in GSD.
I chatted briefly with one of the organizers at registration. Attendance for ICGSE 2010 is expected to be around 70 people, lower than usual, and about 70% university attendees, 30% industry. He attributed both the low attendance and the low industry percentage to the still-weak global economy: usually it’s over 100 people, and usually closer to 70% industry and 30% academic participation.
I’ve been taking notes, getting good ideas, and collecting great insights for two solid days now at SATURN 2010. I have to call out one highlight: playing the Hard Choices game.
I’d looked forward to this COOL event since I first heard about it from game co-creator Rod Nord, and it didn’t disappoint. Getting to play the game with keynote speakers Jim Highsmith (his talk this morning on agility and architecture was excellent!) and Linda Rising (I’m looking forward to her talk tomorrow and her tutorial on Friday), and Marco of SEI, was great fun. The Hard Choices game is a useful metaphor for getting people to think and talk about software development strategies and tradeoff decisions, and I’m looking forward to trying it out ‘back home’ shortly.
You can check out the game at http://www.sei.cmu.edu/architecture/tools/hardchoices/!
Here’s the summary I promised on my experiences at SEPG North America 2010. Overall: great people and many good discussions on agile, CMMI, measurements, and practical real-world improvement.
Some related web references:
- A group of people (including @sepgconferences, @hi11e1, @cmmirox, @willjammer, @StagesProcess, @tcagley, @agilemanager, @srosemer, @dagreerdad, @spm221, @pdnielsen, and me-@agile_teams) tweeted during the conference using hashtag #SEPGNA. This was awesome; several times someone tweeted about the same session I was in, and I was able to arrange to meet the person F2F afterwards; when they were in different sessions, it gave me an idea of what they were hearing even though I could be in only one room.
- Several people (also including me) posted blogs here on WordPress using tag sepg-north-america-2010.
- The Week-at-a-Glance schedule has links to presenter bios.
- Presentations are now downloadable from the Session Catalog, but only by attendees (more on that later).
By the numbers (of course!): According to Anita Carleton at the Tuesday opening, nearly 800 people attended, of whom 250 were newbies, and 125 were from overseas (furthest: from Nanjing). One thing that was not clear: how many people actually attended all four days of the conference?
This morning I gave our SEPG NA 2010 presentation on requirements engineering metrics. It went well, and I got some great comments immediately afterward from some front-row participants, including one who said it was the most useful and practical presentation he’d heard all week! That made my day.
A PDF of the updated slides I delivered can be downloaded from the agileteams.com website publications area. Comments are welcome, here or on the agileteams blog or Twitter!
Today was a good start to my SEPG, thanks to a combination of good plans (well-executed) and serendipity.
Today’s journey to Savannah for SEPG was rainy, but otherwise pleasant and uneventful. Things got a bit confused, though, on arrival at the hotel. Continue reading