Eric has worked in the software development industry for over 20 years and is co-author of UML for Database Design and UML for Mere Mortals both published by Addison Wesley. Eric is currently responsible for capabilities marketing of Rational’s application lifecycle management solutions including Agile Software Delivery, Quality & Test Management, Requirements Management and Collaborative Lifecycle Management. He rejoined IBM in 2008 as the team leader for InfoSphere Optim Solutions and later was responsible for Information Governance Solutions. Prior to rejoining IBM, he worked for Ivar Jacobson Consulting as VP of Sales and Marketing. Before joining Ivar Jacobson, he was director of product marketing for CAST Software. Previously working for IBM, Eric held several roles within the Rational Software group including program director for business, industry and technical solutions, product manager for Rational Rose and team market manager for Rational Desktop Product. He also spent several years with Logic Works Inc. (Acquired by Platinum Technologies and CA), as product manager for ERwin.
As I think about IT today, there comes a rebirth in some ways of the importance of architecture and requirements. We are in an era of “ANY” -- meaning that applications and data can be accessed from anywhere, by anyone, and at any time.
Looking back at the applications of yesteryear (two or three years ago), we didn’t expect much from the web or mobile-based applications. We could view, run some reports or do some basic tasks, but to do the real work, we needed to go to the fat-client. Now, in today’s era of any, the user interface may look different, but the capabilities had better be the same since we expect near full capabilities no matter our device or interface.
This puts a new found set of requirements on applications and their development, and is making modeling and requirements (analysis and design) relevant again, but with a new twist – AGILITY. It is no longer a question of “what platform am I developing for” – the question is how quickly can we get it up and running on the latest version of Apple, Android, HTML 5 and whatever other platforms our clients expect the application to run on … and it had better run on all of the latest versions, with no delays, when updated operation systems come out.
And the question that I often receive now, however, is “can I be agile and meet these needs at the same time”? The plain answer is, yes, you can. However, agility doesn’t me you cannot ignore requirements and design. I am not talking about write-once, run-anywhere, rather instead understand the true requirements so that the various development teams can articulate them in code brought to life as features for the users, as they expect to see them. Users are looking for the application to be specific to their hardware/OS (iPad/AppleOS, Droid/Android…) as the hardware has become the platform for not just running the application, but the expected look, feel and usability of it now, too. This often means different developers for different deployment platforms, certainly at the User Interface level.
Designing applications requires that we are prepared. Architectures must be solidified and communicated. Requirements must be consistent and shared. We must model architectures so that developers can build to the designs and not recreate their own, wasting time and resources, and we must share those designs across the team.
Does this get in the way of agility? NO, it will speed agility. By sharing designs, assigning tasks based on architecture needs, we can speed time to market and our ability to deliver high quality software. In the era of any, we may have multiple teams working on the same front-end capabilities for different platforms even though the back-end is the same. But the more they can share, the faster they can be deployed and having the right requirements from users, the more satisfied they will be. We see people changing their desired platform as employers, vendors and suppliers change requirements, so we need to be prepared for the customer who is using an iPad today to be using an Android device tomorrow with the same requirements on the application. Just look at how the world of Blackberry has evolved.
So, as you think about your next project, don’t skimp on requirements and architectures or you may be limiting your agility in the future rather than speeding your time to satisfied clients.
In my career I’ve been deeply involved with both modeling and requirements management disciplines and tools, so it always intrigues me when I hear debates over whether largely textual based (sometimes referred to as ‘traditional’ or ‘document-based’) or model-based approaches to defining and managing requirements are the right way to go.
We’ve all heard the argument that a picture paints a thousand words, but I’ve always vividly remembered something I heard at a conference some years ago which was “I’d have taken a 1000 words over this one unreadable diagram.”
My belief is that it is not an either-or decision. You need both. Models can add clarity to requirements specifications and can bring together a more holistic understanding of what’s expressed in the requirements. Models can be walked through with stakeholders and with the right language and tools (like SysML or UML in IBM Rational Rhapsody), they can even be run to validate that what is captured in the model is correct, consistent and complete. But what if you have contractual requirements to manage, documents of regulations or standards to comply with, or complex performance or availability constraints – you don’t want to clutter your model with so much detail that it becomes unusable.
My preference is for a combination of textual requirements and models, that can be described by the ‘Systems Engineering Club Sandwich’ (references 1&2) where textual requirements, which form the layers of bread - and maybe a bit dry on their own, are supplemented by models that form the layers of filling – they are richer and more expressive, together forming a tasty combination to help explore and elaborate requirements, perform decomposition and allocation, and maintain traceability. I recently got together with my colleague Paul Urban to record a 30 minute webcast entitled ‘The Tasty Way to Tackle Complexity - The Systems Engineering Club Sandwich of Requirements & Models’
where we take a look at some engineering challenges, where requirements work goes wrong, how the club sandwich approach works and how to use requirements and models together effectively. So if this hors d'oeuvre has made you hungry for more, please take a look. Paul and I are really interested to hear what you think.
1. "The Systems Engineering Sandwich: Combining Requirements, Models and
Design", Jeremy Dick, Jonathon Chard, INCOSE International Symposium,
Toulouse, July 2004.
2. Requirements Engineering, Hull, Jackson
& Dick, Springer 2004.
I was lucky enough last week to travel to the INCOSE
(International Council on Systems Engineering
) International Symposium 2012
near Rome, Italy.
An excellent opportunity to meet the systems engineering community and hear
about their interests and concerns. We had lots of traffic to the very stylish
IBM booth where we talked about the IBM Rational solutions for systems
engineering and the latest from IBM Research on tool interoperability and
design optimization & trade-off. I’d like to claim the traffic was to due
to my presence but in fact there was lots of excitement and interest in the
must have giveaway of the conference, the IBM Limited Edition of Systems
Engineering for Dummies book
(if you weren’t there and don’t have a copy, you
can download a PDF version
Being at the INCOSE event reminded me of the very active and
I recently provoked on the INCOSE LinkedIn group with the posting of the link to my
previous blog post ‘Traceability – How Much is Enough?’
It’s a great read with some very provocative statements about whether
traceability is at all useful and that it’s the root cause of failure on
projects that overrun and overspend versus those that say it’s absolutely vital
on safety-critical systems or where the project is contract-driven. In the end I
think some consensus was reached between these two camps that ‘just enough’
traceability to keep a project on track, provide customer/market need context
to engineers, facilitate impact analysis, and (if needed) to meet industry
standards and regulations, is sufficient. Any more is excessive and wasteful
and likely to bog down progress towards to delivering innovative products and
During a quiet time at the IBM booth, I also had chance to
chat with my colleague Brian Nolan (marketing manager for aerospace &
defense industry at IBM Rational) about effective traceability, since Brian
is very interested in this topic and has presented on a Dr Dobbs
webcast on ‘3 Ways to Improve Traceability and Impact Analysis’.
Brian believes in what I would describe as ‘traceability by design’, meaning
that traceability is automatically established while you decompose your system
design (for example, use case to use case realization to sequence diagram and
so on). This discussion also reminded me of what another colleague Greg Gorman
(program director for IBM systems and software engineering solutions and the
INCOSE Corporate Advisory Board member from IBM) described several years ago as
‘link while you think’, meaning traceability is created by the tools, while you
are performing requirements decomposition, design and development, rather than
as an overhead activity afterwards.
I think we’ve now moved some way beyond ‘link while you
think’. While an information model with ‘just enough’ traceability for your
project needs is essential to avoid traceability spiraling out of control, with
new approaches such as Linked Lifecycle Data
from the OSLC (Open Services for Lifecycle Collaboration) community
and tools that recognize implicit traceability, provide
new ways to visualize lifecycle traceability and perform effective impact
analysis, we can make traceability work for us to help engineering become more
agile, while staying within costs and schedule and produce innovative, higher
quality products and systems.
I'm writing from Innovate 2012 in Orlando, Florida where thousands are attending sessions and sharing thoughts about software development and systems engineering. One topic that keeps coming up is that of traceability. On Sunday at VoiCE (Voice of the Customer Event), we had some great discussions with clients in the industrial sector building complex and embedded systems such as planes, cars and medical devices about traceability scenarios they have. There was a lively discussion around how much traceability is enough. One client, who is working in aerospace, needs to comply with DO-178B, and requires traceability all the way from a high level customer requirement through to individual lines of code. Others asked 'do you really need that fine grained traceability?' and 'won't that be very difficult to manage?' Another described that they have 26 teams and 16 applications to manage, and in the past had many (I think I heard 50!) locations where requirements were stored, usually in spreadsheets, making traceability very difficult. Now with the 'right schema' in place and using IBM Rational Requirements Composer, they have a solution that makes traceability much easier, and an environment that is manageable for the long term as it scales. Having the right schema - the information model of artifacts and what relationships they have was stressed as a vital ingredient in any recipe for successful traceability.
In a breakout session yesterday, data was shared that on a deep space exploration mission project, there are over 80,000 items in the requirements database (IBM Rational DOORS) and over 40,000 links - mind blowing complexity of data and relationships, and that's on one of many projects they have running today.
The right culture, process and tools for your application/system/product/service, organization and industry are necessary to prevent traceability across not only requirements, but into designs, work items, tests and so on, spiraling into an uncontrollable, unusable spaghetti of artifacts and links.
So for you and your projects, how much traceability is enough, how are you managing it and what would you like to see in the future to make the creation, maintenance and most importantly utilization of traceability easier to do and more effective?
We have 16 sessions lined up in this track with focusing on software delivery that revolve around eliciting, defining, elaborating, understanding, organizing, reviewing, communicating and tracking business, user, and software requirements. We have multiple customer sessions; however I am sure you will find the below sessions interesting
- Case Study: Moving from Organized Chaos to Standard Process and Tooling – Disney’s Experience in deploying IBM Rational Tools
- DHL Aligning Business and IT with IBM Rational Requirements Composer
- Iterative Requirements Analysis: Implementing Lean and Agile Principles for Software Requirements Analysis
Like previous editions of Innovate, this year also we have keynotes where IBM shares its road map, strategies and vision for requirements definition and management tools. Also there will be immense number of opportunities to meet senior product management professionals and developers of IBM Rational's Requirements Management tools in sessions like 'Ask the Experts: IBM Rational Requirements Composer and IBM Rational RequisitePro', What's New with IBM® Rational® Requirements Composer? and other presentations.
Some of the other notable presentations focus on trending topics and best practices in the requirements management domain like conceptual frameworks for visual definition in requirements life cycle, Requirements Engineering Maturity Model (REMM) and many more. There are multiple workshops about defining and managing requirements with IBM Rational tools, IBM Collaborative Lifecycle Management, best practices in using Requirements Composer and Jazz primers. Don't forget to try out Open Labs and solutions peds at Innovate!
And finally we have a competition (Who Is the Best IBM Rational Composer User? ) in which Rational Requirements Composer experts put their skills to the test to compete in a variety of different tool challenges and prove who is the best requirements tool champion.In this special event, participants have a chance to compete with IBM experts and tool developers to prove their expertise by solving common and difficult requirements management problems!
Have you registered for Innovate 2012? Hurry Up!!! just 9 days left...http://www.ibm.com/innovate/
Don't miss this opportunity to meet 4000+ professionals, attend your preferred sessions from 27 tracks and 400+ presentations and try out next generation products.See you at Innovate!
At Innovate 2012 in Orlando, June 3-7 there
will be two requirements management (RM) tracks – one focused on RM for IT
application development, and product-wise primarily on RequisitePro and
Rational Requirements Composer; and another focused on RM for systems
engineering (SE), and product-wise on DOORS. This blog post is focused on the
RM for SE track but look out for another on the IT focused track.
I think you’ll find that the
RM for SE track has some really strong content this year. Out of 16 sessions,
10 will feature customer speakers, including:
- How IBM Rational DOORS Helps Jet Propulsion
Laboratory Get to Mars and Beyond: Best Practices in Metrics,
Verification, and Traceability
- Using IBM Rational DOORS to Support Systems
Engineering and Release Management across Multiple Programs at Trane, a
heating, ventilation & air conditioning systems manufacturer
- A CareFusion Case Study of Integrating IBM
Rational DOORS and HP Quality Center for Use in an FDA Environment
- Integrating IBM Rational DOORS with IBM Rational
Team Concert: Lessons Learned at
You’ll also be able to meet
product management and senior development staff and ask them questions in our ‘Ask
The Experts (for DOORS version 7.x, 8.x and 9.x users)’, and you’ll hear about
IBM’s strategy and roadmap in ‘What's Now and Next in Requirements Management
for Systems Engineering’, including the latest release and plans for the DOORS
If you’ve been following our
RM developments recently you’ll be aware of the DOORS Next Generation project
on Jazz.net and you’ll hear about that during the Now and Next session, and
if you want to dive deeper into what’s planned be sure to go to the session
‘Deep Dive Investigation and Feedback about IBM Rational DOORS Next-Generation
Beta’ and visit the DOORS Next Generation demo pedestal in the Innovation Lab
area of the Solution Center.
And if you’ve ever attended
before, you’ll know that a popular feature is the DOORS DXL Script Exchange
competition, where you can demonstrate your prowess in DXL and win a small
prize. For more details about this year’s competition (with a twist!) please
Scripts are due on or before May 25th.
On top of all this fantastic
content (and this is just for one track – there are over 400 sessions across
the whole conference!), Innovate is a great opportunity to network with other
systems engineers and software developers, share war stories, tips and tricks
and maybe a drink or two.
To find out more about
Innovate 2012 and to register go to ibm.com/innovate.
We hope to see you there!
We have been discussing about requirements management practices and solutions from IBM Rational for Requirements Definition and Management at Rational RDM Blog
. We decided to move to our new own home here in developerworks and will continue our discussions going forward here.
Make sure you change your bookmarks and follow this blog to to keep abreast of requirements management principles, advances in the domain and solutions from IBM Rational. We hope to continue having a fruitful discussion here and create a mutual learning platform for all of us! We will continue to discuss the contemporary world of requirements management from both software and systems perspectives.
Continue reading the blog for more details and articles...If you have any suggestions for topics, provide your comments here.