Joy Beatty, Seilevel’s VP of Research, will be participating in an Information Management panel discussion of requirements delivered live February 9, 2012. Learn more about the panel and register here: http://bit.ly/zCznao

The hour-long interview and discussion is hosted on DM Radio by Eric Kavanagh, CEO at The Bloor Group, and Jim Ericson, editorial director of Information Management Magazine. Other panel participants are Tami Frankenfield of Deloitte, Neil Raden of Constellation Research, and Phil Kemelor of Semphonic.

Once you register, you’ll be able to either listen to the broadcast live on Thursday, Feb. 9 at 2:00pm CT, or will be able to listen to the mp3 archive after. Registration is free; don’t miss this opportunity to hear what industry analysts and Joy have to say and share on requirements gathering.

Without user guides, users will not only be slow to adopt a new system or tool—they may be hostile to the change. If you want to quickly create user guides for newly developed software and increase adoption rates, this blog post will share a different way to use software requirements to do just that.

Because Process Flows are probably the most commonly created requirements model, using Process Flows to create user guides should be within reach of most organizations. A guide derived from Process Flows explains how to perform everyday tasks done by regular users of the system, without any functional ambiguity. Users still learn about all of the independent features, only now they are presented in a logical manner that promotes usage of those features. Furthermore, the detailed knowledge that is required to execute a process will often be in the functional requirements that map to each of the process steps. If each business process is covered in a section of the user guide, then each individual action in those sections will be defined by one or more functional requirements.

Another way of thinking about this is comparing two methods of learning a new language: taking a language class, or learning a language by reading a dictionary. It’s possible, albeit very difficult, to learn a new language by going through a dictionary and learning what different words mean. Of course, this method won’t help much with elements of language such as grammar and colloquialisms—how the words are “used.” This is in stark contrast to a language class where you will be introduced to the new language word by word, with grammar, sentence structure, colloquialisms, and conversational flow—nuances that are impossible to pick up by reading a dictionary. The “reading the dictionary” example is much like user guides that describe individual features but don’t link them together. The second example is similar to user guides that describe business processes that can be executed by using multiple features together, something that users can relate to and which offers a far greater value proposition.

The next time a project you are working on comes to the phase of building user guides for the end users, give this method a try. Don’t be surprised if folks express more confidence in new systems, as they will have the means to do their job handed to them on a silver platter. In addition, this is a way for product managers and business analysts to add even more value to an organization!

When helping Seilevel clients define software requirements, one of the many models we use is the Business Data Diagram (BDD). At a high level, the BDD is used to describe the relationships between business objects; in this way, it’s very similar to an Entity Relationship Diagram (ERD). In this post, I’ll share how I learned about the importance of context in BDDs.

When I first started working for Seilevel, the BDD was the hardest model for me to grasp, but after a lot of guidance from colleagues and practice with it, it is now one of my favorite models to create because it provides a very different – and interesting – way to think about the data that is used in everyday business processes. I recently worked on a project where, to show the client the ways in which visual models could be useful on their project, we drafted several example models. In this “gift package” of visual models, we included examples of BDDs.

Since the project made heavy use of business data, and there were several quirks in the relationships among business data, the BDD model was a great fit for communicating requirements clearly and completely. My first iteration in creating the example was a “classic” BDD, and looked something like this (note that all images have been altered a bit for client confidentiality):

This, to me, made complete and total sense. But I learned the “classic” BDD wasn’t enough. While reviewing this draft with a colleague, I was taught why and how to “overload” the BDD.

The idea is simple enough: the BDD is used to show relationships, but it lacked context. My colleague made sure I understood the importance of considering how models may be consumed, and then began to teach me the ways in which to overload the classic BDD model with everything that I could think of that would help the development and testing teams understand the model. After working through different revisions of the model, we produced something like the following:

Now you can see the difference between the “classic” and the “overloaded” model – how the classic BDD simply illustrates information, and how the overloaded BDD provides the same information plus more context.

In the original BDD, cardinalities are represented by numbering the relationship: 1 to 1, 0 to many to 1, etc. However, not every recipient will “get” the cardinalities in this presentation. In the second BDD, the cardinalities are illustrated in two ways: by number and by symbol. This can help bridge the gap if you are showing a model to groups of people who may have different ways of learning. (Personally, I am a more visual person, so my eyes would gravitate towards the symbols rather than the numbers, but I have met many people who would rather just see the numbers without a visual representation.)

Furthermore, the relationships between objects are additionally specified with the operating verbs. In the second diagram, we can see that a Loan belongs to a Product type. Without these “belongs,” someone may infer that a loan merely “has” a product type, which understates the importance of the relationship between loan and product type. While this is not incorrect, by overloading the BDD with “belongs to” context, the model communicates more clearly that the loan itself exists in a greater hierarchy of product types, which can lead to further elicitation of requirements around product types and loans.

As I’ve been learning from my colleagues at Seilevel, communication is one of the most important things to consider in business analysis. If you had elicited and built the most complete requirements definitions possible, but did not communicate it effectively to stakeholders and developers, it’s almost as if all your (and your team’s) efforts never happened. Requirements are pointless without ensuring they are understood. Overloading a visual model like the BDD with more context can help greatly in your communications, in the effectiveness of your efforts, and ultimately in the success of your projects.

This is the last post in a series on “why incorporate the test team into software requirements creation earlier” – for the first post, click here; for the second post, click here.

In the first part of this series on the role Testers can and should play in the requirements creation process, I stated that I had seen only one instance where the Test Team was treated as a constituent group on equal footing with Users and Developers. Coincidentally, this was also one of the most successful projects I have worked on to date. I’ll share the lessons learned here, and show you how implementing a similar process in your organization will result in better requirements and better project outcomes.

First off, we arrived at our final process only after we had suffered through the pain I described in Part 1 and Part 2 of this series. (And leaving the Test Team out of the Requirements process resulted in a lot of pain.) The client’s firm was very much a conventional organization, with conventional processes around requirements creation:

1. The Users defined the problem space, objectives, features and desired outcomes.
2. The Business Analysts facilitated this process and documented their needs.

The Analysts’ documentations were then fleshed out in greater detail, made into formal requirements, and were then handed off to the Development team. The only ones who saw the requirements documents and signed off on them were the Users and Developers. The Test Team were provided the requirements documents once we were well into development.

This was the cue for chaos to ensue during every single release, as requirements were questioned, clarified, modified, reworked, eliminated, added, split out, and generally massaged until the Test Team finally said the requirements made sense. This chaos was accompanied by the usual hand-wringing and stress that can be expected when that much rework and modification happens. 

After a couple of iterations of this, we decided we had enough and decided to do something about the process. The solution was obvious – incorporate the Test Team into the requirements creation process. The only question was when in the process would they be involved, and what specific contributions were expected of them.

After a bit of trial and error this is what the reworked process looked like:

1. Once the high level Feature planning for a Release had been completed (or a good solid first pass nailed down by way of Features and Functionality being targeted), we immediately shared it with the Test Team. They really did not have any input into specific features or requirements at this stage other than to raise concerns around testing resources, such as if test platforms needed to be upgraded or special software purchased to enable the new features to be tested properly. (While all of these are very valuable from a project planning perspective, they really do not impact the requirements per se.)
2. The targeted features were fleshed out in greater detail and a Business Requirements Document (BRD) was created, and the Test Team was included as a reviewer, but not as an approver, for this document. At this stage, the features were still defined at a higher level and not typically at a level of specificity sufficient for test case creation. The Test Team kept a sharp lookout for non-functional requirements in the areas of security, access rights and performance in these documents.  They alerted us to missing functionality up front, and also frequently gave us a sanity check on some of the performance type requests. I often consulted with them while defining these features, since the Test Team’s input was extremely knowledgeable and pragmatic.
3. Once the BRD was approved, we fleshed it out in greater detail and created a System Requirements Specification (SRS) document, containing the detailed requirements that would be handed off to Development; it was also the document that the Test Team used to create their test cases. The Test Team was given approval rights on all these documents. Simply put, if they did not sign off on the document, it could not be formally handed off to Development. The Test Team also had veto power. This simple change resulted in a dramatic improvement in the quality of the final requirements. From the very first release where the Test Team was given this authority, ambiguous or untestable requirements were practically eliminated; the quality of the non-functional requirements also showed significant improvement.

The first time we implemented this process, the requirements delivery slipped schedule by a couple of weeks: this was how long it took us to clean up the documentation. Once that was done, however, the rest of the process went smoothly. Further, subsequent releases saw much better documentation up-front, and a lot of sloppiness had been wrung out of the entire process.

Regardless which development methodology your organization favors, if you use Test Teams for software testing and QA, I am positive that including them as part of your requirements creation process will result in significant improvements in the quality of requirements documentation produced by your team, and ultimately in the quality of and reduced rework for the project as a whole.

This is the second post in a series on “why incorporate the test team into software requirements creation earlier” – for the first post, click here.

The downsides to not integrating the Test organization into the requirements creation process are rework, schedule slippage, scope changes and budget overruns. Bringing the Test team into the picture much later in the Development cycle almost always leads to the requirements being reworked. Why is this so?

I have found four main reasons for this:

1. Poorly written Requirements
2. Untestable Requirements
3. Missing or Improper Non-Functional Requirements
4. Testers look at Requirements from a different viewpoint than Users and Developers

Let us look at each of the above in a bit more detail.

Poorly written requirements are typically ambiguous or complex. For example, “System shall be scalable.” No one wants an application that cannot scale. So the Users demand it, the Analyst records it, and the Developers sign off on it because they believe that anything they build will scale infinitely. But the moment a Tester gets this requirement, they will likely start asking questions. ”What do you mean by scalable? How many users? How many transactions? What hours of the day?” 

These are all valid questions that should have been addressed during the requirements creation process, but unfortunately were overlooked. Time to go back to the drawing board…

Untestable requirements do not have enough clarity and specificity for a Tester to write valid test cases against. I have seen this manifested in a couple of ways. First are the ambiguous requirements described above and the problems they cause. Another manifestation of this are lazily written requirements that typically refer to other documents or sources of information which contain the actual requirements or business rules. For example, “System shall comply with Fed E regulations.” This innocuous statement will be accompanied by a pointer to a reference document in an Appendix that when opened will contain about 500 pages of dense legalese, some of which are the “Fed E” regulations near and dear to the User’s heart. It is all there somewhere. 

The User may know where it is and what it means. Neither the Analyst nor the User wanted to spend the time to extract the relevant pieces and document them, so, with a lazy wink and a nod, they sent it downstream. 

The Developer will likely take a swipe at it, and hopefully get it right – but if they don’t get it right, it’s time for painful rework. This wasteful laziness on the part of the User and Analyst would have been stopped by a Tester who has to write concrete test cases, who then would quickly come to the conclusion that it is impossible to do so with the information provided. 

In my opinion, writing good non-functional requirements is one of the most difficult skills for an Analyst to master. Testers quickly identify the holes and gaps in the requirements – gaps that everyone else overlooked – and Testers are especially useful in finding holes in non-functional requirements, such as security and performance. So incorporate your Test and QA Teams earlier, to avoid waste and rework!

Testers look at the requirements in a way that is fundamentally different from a User or a Developer. Users are really not trained to know a testable or unambiguous requirement, and do not care to know. They paint a picture for the Requirements Analyst and rely on the Analysts’ expertise to create good requirements documents. As long as they believe that the essence of what they are asking for is conveyed, they are happy. Developers are typically anxious to get started and write code. As long as they believe they have enough information to create a solution, they are happy. Although I might sound heretical, the fewer the details and constraints on a Developer, the happier they are.

In contrast, Testers look for details and specifics. They use the requirements to write test cases. If the requirements are vague, ambiguous, or are otherwise lacking in details and specifics, they simply cannot write test cases. Without test cases, they cannot tell us with any degree of confidence whether the delivered application complies with the requirements or not. 

And this is, of course, the primary job of QA and Testers. So Testers have no choice but to force the issue and demand clear requirements, without which they cannot function. Without Testers demanding clear requirements and sending Users and Analysts back to the drawing board, lots of Developer time and resources will have been wasted.

In the last post in this series, I will show you how to use the Test Team correctly, making them an integral part of the requirements creation process. Testers and QA will help you get good clean requirements that eliminate rework, reduce those nasty downside surprises with schedules/budgets, and keep Users and Analysts from going back to the drawing board.

A lot of the popular literature, training, documentation and processes related to the management of Software Requirements in an organization are typically focused on two constituencies – Users and Developers – and thus miss an important constituency, Testers.

User is the catch-all term for anyone who may use the software being created. They typically define what the software should be able to do – they are the source of the Requirements. The Developers are the lucky ones who get to build all the wonderful stuff that the Users have asked for. They consume the Requirements; convert the concepts, ideas, rules, models and countless Requirement statements into bits and bytes of code that taken together is hopefully the solution envisioned and defined by the Requirements Analyst at the start of the process.

Sitting smack dab in the middle of this creative stream of consciousness that stretches from the User to the Developer before ending again eventually with the User is the Tester. Before the software created by the Developers is handed off to the Users, the Testers have to give it a clean bill of health. They have to certify that the Development team is giving the Users what they asked for.

How exactly do the Testers know what the Users asked for? By looking at the Requirements documents that were created at the start of the process and comparing the delivered software against the requested features and specifications.

Despite the fact that the Testers are almost entirely dependent on Requirements documentation to perform their duties, I have seldom seen them incorporated into the Requirements Creation Process. Based on my observations of multiple projects in several large multinational corporations, I have come across only one instance where the Test team was treated as a constituent group on equal footing with Users and Developers during the Requirements Creation Process.

In general, what I have seen is that Test teams have no connection with or influence over the Requirements that are given to them for testing and validation while they are being created. They are typically handed the Requirements documents long after they have been finalized and development is well underway. They are then told to ensure that the software meets the documented Requirements.

What typically ensues thereafter is chaos. The Test team comes back with a ton of questions about the Requirements that no one is able to answer. Alternately they are given multiple answers to their questions which often contradict each other. (I have often wondered which is worse, but that is the subject of another blog post.) This craziness continues until someone finally realizes that the Requirements need to be tweaked and reworked.

If the people involved with the Project were lucky, the changes made to the Requirements did not impact Development because the Developers had guessed correctly or had not yet gotten started on it. If the people involved with the Project were not lucky, the tweaks to the Requirements resulted in meaningful changes to schedule and scope since rework was needed. If the people involved with the Project were really unlucky, significant changes to scope, schedule and budget had to be made.

There are two obvious questions here. Why do the Requirements get tweaked almost always after the Test team has gotten them? And, what can we do to keep this from happening again, and again, and again, and…

Stay tuned for Part 2 and Part 3 of this series, to learn more about what we can do to avoid this waste and chaos.

Like many of us, I’ve been known to mumble disparaging remarks about Microsoft under my breath while using their tools. But, I have to say there is at least one thing they did right – the format painter. I run into enough people who don’t know about this that I think it is worth mentioning.

Do you want one cell in Excel to look exactly like another, but don’t remember what font, color, etc. you chose? Do you want some text in Word to be formatted just like the text from 2 pages ago? Do you want a process step in Visio to have the same shading, line type, etc. as another process step? In all cases the format painter comes to the rescue.

The icon for the format painter is the paint brush: 

Using it is easy. All you have to do is select the item with the format you want to copy, click the format painter, and then select the item you want formatted like the original. Done. Oh, and if you want multiple items to have the same format, just double-click the format painter. You can use it on multiple items, until you press Escape.

I hope the person who thought of the format painter got a really big bonus. And I hope this business analyst tip helps you work more efficiently, so you can get a really big bonus, too.

Complexity science is a scientific discipline that studies the behavior of complex systems. So what does it have to do with software and product requirements? As you’ll learn, quite a bit.  

Almost everything we encounter in the world is part of a complex adaptive system (CAS). John Holland, a MacArthur Fellow and professor of computer science, engineering, and psychology (!) defines these systems like this: “Complex adaptive systems are systems that have a large numbers of components, often called agents, that interact and adapt or learn.”

Doesn’t that describe every project you’ve ever worked on in your life? This also describes every market your company participates in. Agents can be your fellow employees, your customers, or your strange aunt Susan; and any system with more than a few agents quickly becomes a complex system. That’s why complexity science can give us many insights into the way the real world behaves.

One of the primary lessons of complexity science is that CAS’s are unpredictable. This may be obvious when you think about all the strange customer requests you’ve heard, but not so obvious when your boss asks you to predict what the monthly sales of your new product will be over the next 3 years.

We like to think that we can make reasonable predictions about the future. We can’t. This is an incontrovertible lesson that complexity science teaches us: CAS’s are fundamentally unpredictable, and no amount of data will change that. Some of our predictions may be correct, but a stopped clock also tells the correct time twice a day.

Even the smartest experts in the world can’t make accurate predictions about their domain. Here are just a few classic examples (click here to launch a PDF of the source for these quotes), but I’m sure you hear examples every day in your workplace:

“What use could this company make of an electric toy?”
- Western Union, when it turned down rights to the telephone in 1878

“I think there is a world market for maybe five computers.”
- Thomas Watson, chairman of IBM, 1943

“There is no reason anyone would want a computer in their home.”
- Ken Olson, president, chairman and founder of DEC, 1977

“Man will not fly for 50 years.”
- Wilbur Wright, American aviation pioneer, after a disappointing flying experiment in 1901 (their first successful flight was in 1903)

How is this relevant to requirements? Because the reason most projects fail is rooted in bad predictions: poorly-formed business goals, leading to the wrong scope, the wrong budget, the wrong time frame, the wrong objectives.

I am sure that if you trace the reasons for almost any failure, a bad prediction will be at the root. And what Complexity Science tells us, counter-intuitively, is that the solution for bad predictions is not better predictions. The prediction game is a guaranteed loser. The solution is better adaptation and learning.

Once again, this may seem obvious, but most traditional management practices generally limit adaptation and learning due to an inherent belief in prediction.  

Want proof? The next time your project doubles the budget and doubles the timeline, tell your boss that the reason was the inherent unpredictability of complex adaptive systems. That will either get you laughed out the door or fired.

But it’s the truth. An unfortunate response by management to unpredictability is to search for who to blame and punish those people. A better response would be to look at the situation as a key opportunity to learn about their market or company, and praise those who lead the internal revolution in thinking about markets for the company based on this changeable, complex new reality. (But I’m sure that’s not the first thing that comes to mind when your projects don’t hit their projections.)

How does this alter our requirements process? For starters, I’ve written several blog posts on the topic of dealing with unpredictability:

But that’s just a start. Agile development does a great job in making your development process more adaptable, but the agile philosophy must extend to everything you and your organization do: agile project plans, agile sales projections, agile corporate strategy. In general, nothing will go as you originally planned, and that is not a bad thing, because it increases the probability of hitting the target with your customers.

The ideal state for any organization is total transparency, adaptability, and flexibility. Clearly, this ideal will never be achieved. However, it is our job as product managers and leaders to consistently drive our projects toward these ideals. We need to create a revolution by creating the tools and the structures to enable more adaptability. We need to greet the unexpected with anxious joy. Even though we will never reach perfect transparency, adaptability, and flexibility, we will at least tackle the real problems and make real progress, rather than clinging to the hopeless, disproved falsehoods of believing that our success is dependent on how well we can predict the unpredictable.

Next week is the yearly techie pilgrimage to Las Vegas to visit the nexus of tech that is CES.

This year, I’m excited that startups have been integrated along with the big names we’re used to, like Intel and Microsoft. (I wonder if the rumors are true that Microsoft will not be at CES next year?) I’m also looking forward to seeing lots of concept cars from Mercedes Benz, and to hear from Dieter Zetsche.

Can’t wait to check out all sorts of innovations in phones, computers, games, tablets, cameras, and TVs. CES includes almost any gadget you can think of; I’m curious to see what new household products we’ll see. Maybe an internet connected dishwasher that automatically orders more JetDry on Amazon? I wonder what will make it through the Last Gadget Standing competition?

What can a product manager learn from some of the more dubious gadgets at CES (not)?
Here’s a brief tongue-in-cheek list for your consideration:
1. If you build it, they will come…provided you have great give-aways at your booth.
2. More features are better…especially if they are shiny, or glow.
3. Who’s the audience for that feature? Does anyone really want to know? (Dubious gadget product design teams know the “U” in “UI” means “u designers,” and if u designers think it’s cool, that’s all that’s needed to go to market.)
4. Innovation exists in inverse relationship to battery life.
5. “M” is the magic letter…make it mobile, make it mini, make it micro-sized, even if it’s a kitchen appliance. (Hhhm, an internet connected dishwasher that’s GPS-enabled to source JetDry while on the road, that fits in your car and is ready for camping…)

Of course, if you want useful information for product management, you might do better here.

Happy New Year! Seilevel blog writers Betsy Stockdale and Balaji Vijayan have new articles published – Betsy on BA Times, Balaji on Modern Analyst – and yours truly, Seilevel’s blog editor, has a post on IT Toolbox.

For Betsy’s article on using business objectives to control scope, visit BA Times here: http://www.batimes.com/articles/using-business-objectives-to-control-scope.html

To see Balaji’s article on three good reasons to initiate a Business Analyst Center of Excellence, visit Modern Analyst here: http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/2110/Three-Good-Reasons-to-Initiate-a-BA-Center-of-Excellence.aspx

And for the IT Toolbox post on why a picture (visual model) is worth a thousand “system shall” statements, see the Software Requirements blog here: http://it.toolbox.com/blogs/software-requirements/visual-requirements-models-why-a-picture-is-worth-a-1000-system-shall-statements-49903