Don’t fear the Use Case

Working with many organizations, I've discovered that there are always a few people who are afraid of use cases.  This is mostly because they have never had training on how to build one.  Below are some guidelines that I use to coach these folks in writing use cases.

First of all, what is a Use Case?  A use case describes a system's behavior as it responds to a request from a stakeholder under various conditions.  Your stakeholders will provide input, validation, and final approval of the use cases.  Use cases add value because the stakeholders get to see the exact behavior of the system.  More importantly, use cases contain goals that the system will support, hence clarify the scope of the system.  It becomes an efficient way to communicate the system under definition between the various stakeholders.  Another value that use cases add is coming up with of all the things that could go wrong and documenting how the system should behave to the failures.  Without these alternate flows, error conditions go undetected until it is time to program the system.  What usually happens is that the programmer will write whatever they think is logical (with the best of intentions), but will probably result in failure during the use of the system.   As the saying goes, the path to hell is paved with good intentions.

Not all use cases look alike.  Business process people write business use cases to describe the operation of their business, while the design teams write system use cases to break down the requirements to small subsystems.  A business use case is written to show what the processes do to achieve their business goals.  A system use case is written to specify the function or the service that the system provides to a stakeholder. Always remember that system use cases are black-box use cases that do not describe the guts of the system.  This forces you to focus on what the system must do versus how it is to be done.  Leave the "how" to the hardware and software development teams.

Use cases are requirements that describe the behavior of the system, but they do not all constitute of the requirements.  I would say a quarter of your requirements are use cases, and do not represent other requirements such as external interfaces, data, business rules, quality of service, glossary, implementation, technical, integration, performance, etc.  However, use cases should connect many of the other requirements through traceability.  Think of use cases as the framework that links information in different requirements.

If a quarter of my requirements are use cases, then how much time should one spend on them, considering you have other requirements to define.  I always follow the simple "accuracy to precision" model.  What do I mean by that?  Here is an example that I learned from one of my software engineering professors that shows how accuracy and precision are not the same.  If I tell you that π = 9.141593, then my number is precise, but not accurate.  But if I tell you that π is around 3, then I am accurate, but not very precise.  Using the above analogy for each of my use cases, I begin with 3 and then I delve into the .141xxx as time and project permits.  I start by stating the primary actor and then list all the secondary actors, and each of their goals the system will support.  I also write a short description of the use case describing the interaction with the primary actor.  Validate this with your stakeholders for accuracy and completeness.  It is surprising how many use cases are already wrong because they weren't accurate or how many were missed because not all of the stakeholder's goals were included.  After the initial validation, you can prioritize and assign these use cases to individuals and releases.  For the use cases that are selected to be written, they need to precisely describe the main success scenario/basic flow.  Review and validate these basic flows with your stakeholders to make sure that the system is behaving in the interests of the stakeholders and meeting their goals.  Once you know your basic flows meet your stakeholder's needs, then you can start listing all the failure conditions and alternate flows.  Verify this with your stakeholders to make sure your list is accurate and you haven't missed any important what-if scenarios.  This will also help you prioritize the failure conditions and alternate flows that you want to add detail.  This is very tedious work, but I often find missing requirements or goals that were not initially given to me by the stakeholders.  I know your time is limited, so working in the above flow will help you manage your accuracy and precision level.

There is no standard template for documenting use cases.  I find the below core parts of a use case to be utilized (more or less) by organizations:

Use case name 

Level:  Business or System

Goal:  You MUST have a goal.  The goal should be a description or a list of what the primary actor will achieve within this use case.

Scope:  You can describe the service or the part of the system that will be defined by the use case.

Summary/Overview: A short description of the use case interacting with the primary actor.

Actors:  An actor can be a person/role, organization, computer system, data, etc. - anything acting on the system.

• Stakeholders:  They are 100% interested in the behavior of the use case.  They may or may not interact in the use case, but the outcome of the use case affects them.
• Primary Actor - This is a stakeholder that acts on the system to achieve a goal.
• Secondary Actors - These are stakeholders that are acted upon by the system.  In other words, these actors provide a service to the system so that the primary actor can achieve its goal.

Triggers:  This describe the event(s) that causes the use case to get started

Preconditions: This describes all the conditions that are true before the use case starts.

Postconditions: This describes the change(s) in state of the system after the use case completes, positively and negatively.

Basic flow/ Main Success Scenario: This is the top down description of the typical set of actions in which the goal(s) is delivered.  Any one step can describe an interaction between the primary actor and the system, between system and secondary actors, or a validation step to protect a goal of the actor.  Each step should use simple grammar that clearly shows the Actor - Verb - direct object structure, and it should move the process forward in the use case.  Finally, I find Miller's Law (7 +/- 2) to be a good heuristic to use to determine how many steps should be in a use case.  Use cases with more than 10 steps in the basic flow can get cumbersome for review because some of these steps will have alternative/error flows that have to be validated in context of the basic flow.  I find the most common mistake in use case writing is leaving out the subject of the action step.  Here are a couple of examples of poorly written use cases using one of my favorite examples, the ATM.

Use Case mistake - not showing system action - This use case shows everything the actor does, but does not show the system's reaction.

1. Customer enters card and PIN
2. Customer selects "Withdrawal" and amount
3. Customer takes card, cash, and receipt
4. Customer leaves

The system should always respond to an actor's action. Ever present in a use case is the cause and effect relationship between the actor and system.

Use Case mistake - not showing the actor - This use case is written from the system's perspective and does not show the actor's behavior.

1. Reads ATM and PIN
2. Sets transaction type as "Withdrawal" and amount
3. Delivers card, cash, and receipt
4. Logs the transaction

Use Case fix - This use case names all the actors and their actions.

1. Customer enters card and PIN
2. System validates card and PIN against the main banking system and displays main screen
3. Customer selects "Withdrawal" and amount
4. System updates the account with the amount and logs the transaction as a "Withdrawal"

1. System delivers card, cash, receipt, and resets.

Alternative flows/Extensions/Exceptions/Errors: These are all the other flows.  It starts with a condition/trigger and a goal for the alternative flow.  It contains a sequence of action steps describing what happens for that condition/trigger.  It ends with the success or failure of the extension goal.  An alternate flow can end in several ways: a successful end; a total failure; ending goes back to a previous step in the basic flow (looping); or ending remerges somewhere in the next steps of the basic flow (fan-out/fan-in).

You can apply use cases on almost any project that requires you to define the behavior of a system.  The standard template to write the use case is selected according to each project's needs.  Projects that are short or quick will need less detail versus projects that are detailed, expensive, or distributed.  Finally, a central repository will allow you to define, validate and manage the use cases and all the other linked requirements in context of each other.

 

 

No Parking after 2'' Snowfall

 

Much to the astonishment of my warm-weather relatives in Texas, Alabama, and California, I live in an area of the country that receives about 4 feet of snow each year. As with most snow-blessed (or snow-cursed, depending on your point of view) regions, my municipality takes great pride in its ability to minimize the impact of our inevitable snow events. We scoff when our sunbelt brethren are, quite literally, frozen in their tracks by light, slushy glazes. Famously, a local mayoral election turned on this very issue in the late 1970's.

In the hours before flakes begin to fly, a fleet of snow removal vehicles take to the streets and begin the tedious work required to keep the roads freely flowing. To simplify their work, a complex patchwork of "Snow Routes" have been drawn up, and you know you're on one when you see one of these ubiquitous signs:

It seems like such a simple message, doesn't it? "When it snows 2 inches, don't park here." But in conversations with friends and neighbors, I am surprised to find there is no common consensus about what this actually means. Here are just a few of the interpretations and objections I have heard:

• How are we measuring two inches of snow? What if it snowed only one inch on my street, am I still in violation?
• What if it only snowed an inch, but the wind blew the snow around, does that still count?
• Every street has these signs. Where am I supposed to put my car? Am I supposed to drive around aimlessly until it stops snowing?
• Why 2 inches? Don't they mean two inches or more? Or am I safe once the snow gets to 3 inches and beyond?
• Do they mean 2 inches in an hour? A day? 2 inches since they last cleared the street?
• When can I park again? After they clear the street? Technically, that is still "after 2" snowfall"...

I admit, some of these are silly, and readily answered. But the point here is that, from a single, succinct message, there is so much ambiguity, so much room for interpretation. And the cost of not getting the interpretation correct is a parking ticket, and possibly a towed vehicle; an inconvenience and aggravation for sure, but hardly the end of the world.

Now take this a step further, and suppose that, instead, the sign read something like a typical business requirement. Something like, "The system shall allow the user to browse through a list of available services." The ambiguity, room for interpretation, and lack of clarity is magnified many times over, in comparison with our simple sign. One way to add clarity is to decompose the requirement into finer levels of detail, successively defining each piece of the requirement into atomic levels of text, whose meaning is clearly understood by everyone. Indeed, many companies do just this. They end up with giant spreadsheets of requirements with 10 or more hierarchical layers and thousands of rows. It takes time to thoroughly review these types of documents, and business stakeholders tend to lack the necessary bandwidth to do so. Likewise, downstream consumers like developers, QA personnel, consultants, and technical writers are often awed by such lists, but don't necessarily understand the requirement any better. This requires that they interpret the ambiguous requirement in their own way, which may or may not meet the original business need. If they miss the mark, the resulting rework will cost significantly more than a parking ticket.

Another approach would be to recognize, as our No Parking sign illustrates, that natural language is often an imprecise means for communicating even simple concepts. Most people process and retain greater information detail when it is communicated in multiple forms. Many of the objections I listed above could be assuaged by adding diagrams, and / or public service announcements showing which conditions warrant a parking ban, and what to do about it. Likewise, adding clarity to requirements requires that we not only add detail to the text, but we also provide additional clarity through other communication means. Perhaps a business process is required to add context; or a user interface may be deployed on a use case step to specifically define system behavior as it meets the requirement goal. Communicating multiple aspects of a requirement is not easy, but a lifelike simulation that incorporates all these aspects can ensure all facets of the requirement are understood.

The equivalent, from a snow removal standpoint, would be a perfect understanding of the factors that produce significant snow events, resulting in accurate forecasts months ahead of time. Wouldn't that be something? With a warm, sunny forecast known well in advance, I might even be able to convince my relatives to come visit us some January.

Announcing Blueprint Requirements Center 2010 FP 3

Blueprint announces the immediate availability of Blueprint Requirements Center 2010 Feature Pack 3. This release further extends the capabilities of the Requirements Center family of products, the industry's leading Requirements Workbench for distributed requirements definition and stakeholder collaboration.

What's New?

Requirements Center 2010 FP3 includes:

• Excel Export for Requirement and Test Models

• Support for customizing and saving views of the Requirements Spreadsheet

• Bulk editing of Textual Requirements

• An improved read-only experience for Blueprint Team Repository users

• Inclusion of manual traces in test models, and the propagation of this information to HP Quality Center

• Expanded tools for aligning objects in UI Mockups and Business Process Diagrams

• Filters for manual and implicit traces in the traceability view

• Support for Windows 7

Existing customers with an active support agreement will receive a release announcement with further details and upgrade instructions. If your agreement is not currently active and you would like to upgrade, please contact your Blueprint sales representative, or email sales@blueprintsys.com.

 

How to Be Awesome At Being A BA

 

Chances are, if your career has landed you in the role of a business analyst, it was probably by accident.

Even if it wasn't, I'm willing to make another guess: You've probably never received any sort of formal BA training, and you're wondering if there is even such a thing.

How did I do?

The roles of BAs vary, for the most part, based on the size of the company: Simply put, BAs seem to do more in smaller organizations. But in any sized company, I believe that I have observed some traits that are consistent across the most skillful and, dare I say, awesome BAs that I have had the pleasure of meeting.

So, instead of looking at any methodologies behind business analysis (there's plenty out there already), in this article I intend to examine those characteristics of the awesome business analyst, and point out some specific tools and resources that I guarantee that you can use to make yourself awesome (or awesomer, as the case may be).

In a nutshell, the role of the business analyst is to capture, organize, and communicate large volumes of information.

Let's start with the capturing part.

Capturing

To record information, you use a computer: You know, that thing you sit in front of all day? How good are you at using it, really?

Learn how to type faster.

I know this sounds like a no-brainer, but it astounds me how many people still hunt and peck for letters on a keyboard. At the very least, at this point you should know how to type without looking at the thing. If you're not there yet, take lessons, or just force yourself not to look at your keyboard; that's how I learned (and look how I turned out!).

Use technology to take shortcuts.

...after all, that's what technology is for, isn't it?

Start by spending less time with your mouse. What you don't realize is that you're constantly costing yourself time by using the mouse, especially when you don't have to. Your mouse has two buttons, and your keyboard has, what, a million? Those magical keys can do so much more than simply put letters on the screen!

Windows has a ton of built-in, time-saving keyboard shortcuts that you may already be using, that work in pretty much any application you use. Here are my favorites:

* First, there's the old standbys: Copy (Ctrl+C), Paste (Ctrl+V), and Undo (Ctrl+Z).
* Then there's some for getting around Windows faster: Switch Between Open Programs (Alt+Tab), Show Desktop (Windows+D), Run (Windows+R), Open Explorer (Windows+E).

Want more? Here's a rundown of keyboard shortcuts for Windows.

The tools you're using also have keyboard shortcuts of their own; by all means use them. You can typically find a list of time-saving key combinations in the User Guide.

If you have the ability to, there's also some tools you can install that will speed things along even further:

* Use a text expander. Texter is one such tool. What this little beauty of a utility does is run in the background as you use other applications, and when you type something like "tss" it expands it to "The System shall", or whatever you tell it to. The beauty of it is that it works in any application where you type, be it Word, your email, your web browser... or your favorite requirements workbench.

* Use email templates. Chances are you probably bang out a lot of emails that look similar to one another: "You'll find the answer here...", or "Talk to the following people about these areas...". You can use Texter, or Outlook Templates, or even just keep a text file handy (accessible via a shortcut) with a bunch of common responses, to do this. The trick is to not sound like a robot, so be sure to add at least a bit of personalization and warmth to it.

* Search first. Don't trust whatever filing system you came up with yesterday, as that may no longer apply today. While Outlook's email search capability has improved over the years, it's still not as lightning-fast as Xobni, or Lookout.

In general, what I'm recommending is to look at the repetitive tasks you do every day, and think about ways you may be able to automate them, or at least ways you can get faster at them. (So, basically, do for yourself what you already do for your business!)

Organizing

As you capture all that information, in all of its various forms, you also need to organize it, so you can later communicate it effectively. But, let's take care of something, first:

Organize yourself.

Your job requires you to talk to a lot of people in order to discover your business's needs, and then to communicate them. Unfortunately, this requires time-consuming activities such as those dreaded meetings, and frequent distractions such as constant stream of emails - the combination of which prevents you from actually getting your real job done.

Combat this!

* Manage your time. In particular, guard that time wasted by meetings. Block off your calendar for meetings with yourself. Ask why you end up in the meetings you get invited to. By the same token, don't waste other people's time: Provide an agenda, a clear reason as to why you needed certain people to attend (make it clearly optional for everybody else), and aim to end the meeting as soon as you can while still achieving its goal.

* Reduce distractions. This is probably my biggest pet peeve: It's time to turn off those vibrations, or blasted little pop-ups that let you know you have a new email every five minutes. There's no reason why you need to know about every email when you can't act on the majority of them right away; you've got your job to attend to, remember? Other tricks such as email filters, and BlackBerry Contact Alerts help to weed out the important people from the noise.

* Manage your tasks. Adopt a task management system. Once you learn a process, it will help not only your professional life, but also your personal one. I'll defer to an article I wrote on my blog about this. Once you've done this, read, and apply the principles of Getting Things Done.

* Manage your inbox. Adopt a dead-simple filing system, such as The Trusted Trio, and discipline yourself.

Get good at structuring your thoughts.

When considering what groceries to buy, you might work through a stream of consciousness, as follows:

"I need spinach, and a couple pounds of cheese. My Mother also really likes that frozen casserole we had the last time she was here. What was it called again? I'll probably recognize it when I see it. Hmmm. On second thought, I probably don't need so much cheese..."

Instead of writing it out that way, you take the time to list each item out in a nice, orderly list. Why? Because it's easy to read, and to check off (process) as you make your way around the aisles. Yet, a lot of communications we receive really is just a stream of consciousness.

How can you make this sort of structured thinking a habit? I believe that it can start with improving the communications you spend the majority of your day writing: Your email.

Here are some of my suggestions for composing better email messages:

* Include the thing you want me to make sure I see at the top of the message.
* If you have several questions to ask, list them out and number them, so I can respond to each one easier.
* Clearly list out the actions you want me to perform.

For more tips, buy a book on writing email, such as this one. (I haven't read it, but the reviews seem overwhelmingly positive! If you have any to suggest, feel free to mention them in the comments.)

Your good email habits are bound to carry over to the other part of your job: Actually writing requirements.

Communicating

Learn to write more betterer.

Outside of work, and your email client, consider spending time writing about something you're passionate about.

Start a blog about gardening. Write about your Lego collection. Tell everybody about that time that thing happened.

You only get better at expressing yourself by writing more.

Learn to network.

Your job is also about making connections and knowing the people in your organization.

Connect to other people in your company via LinkedIn. This is an innocent way of saying hello, without really saying hello.

For those of you who consider yourselves introverts, or are just shy about approaching strangers, I heartily recommend Leil Lowndes' How To Talk to Anyone.

Learn to think in flows.

I'm going to suggest something here that some of you may consider controversial. Are you ready?

Take a simple programming course.

This will, at the very least, get you to start thinking in terms of processes, and breaking down things into a step-by-step, logical series of events. This is a concept that a fair amount of BAs I have encountered have some trouble wrapping their heads around.

Remember that you're a translator, so knowing both the language of the business, and the "language" of your implementers is vital to bridging that gap effectively.

Learn to think like a designer.

In case business analysts don't do enough, they also frequently have to play the role of a designer.

In this area, I suggest reading books on user interface design, starting with The Design of Everyday Things.

Another way to look at design is that of "selling" information: Think through how to best present the data you have, and how to make it look good. To help here, pay attention to things like templates you like, to print advertisements in magazines and the layout of designs on bus shelters; examine the fonts chosen, and the structuring of the information it's aiming to convey.

How Are You Awesome?

I hope you find something in all of this somewhat useful. If you have any of your own tips to offer, please post them below!

Photo by SeeMidTN.com (aka Brent)

 

 

 

 

 

 

For unity's sake, clean up those requirements documents!!!

It's easy enough to tell a story, but what happens when the consumer's comprehension of the story determines how it will turn out. Imagine a book that automatically changes the ending based on the reader's understanding of what the author was attempting to say. Inevitably, no two readers would share the same ending. There would always be differences of opinions and the value of the story could be drastically reduced if the author wasn't extremely precise in what was written.

 The Business Analyst is an author and the ending to the story they write will vary based on how the story is understood. The Analyst sits between the Business Partner and the IT group, and authors a story based on what they understand the Business Partner to need. This story then gets handed to IT and their job is to go and write the ending. As we all know, in this type of story, the ending is rarely what the Business Partner or the Analyst expected.

Although there are many factors that contribute to an unhappy ending, I want to focus in on the topic of unity. As a parent I'm often looking at my kid's room and saying, "For goodness sake, they need to clean this room." When I look at most requirement documents I think, "For unity's sake, they need to clean up this document." Unity is what holds the story together and gives it a clear and precise context. Every story needs context in order for the reader to relate and connect. If the document feels like a scrambled jumble of parts and pieces, the reader will never connect with the story. If they don't connect, they can't provide the feedback that's so desperately needed before IT starts to write the ending.

To accomplish unity in a document you must do the following:

1) Always provide a consistent look, feel, and structure - a template
2) Leverage hyperlinks in the document so it's easy to navigate to related elements - easy navigation
3) Clearly identify how the different elements relate to each other - rich context

The reader needs to understand how a goal is accomplished (Use Cases), how each step used to accomplish the goal relates to the needs of the Business (Business Requirements) and the tasks of the users (User Requirements). How the system steps in the Use Case drive the System or Functional requirements. What UI Mockups should be used for a given step in the process, and so on. When all these different pieces are in unity throughout the document, then, and only then, can the Business Partner drive precision into the story, (via feedback) so that the IT Group can write the most accurate ending.

Although I agree with Chris Gurney's post, "The Big Freaking Document Must Die," until Analysts adopt better tools that help tell a more unified story, via visual simulation of requirements, or at least generate documents with unified content, we're stuck manually creating documents. But keep in mind, especially with manual documents, it's not just about having content, it's about unity of content. Content alone is useless, unified content is easily understood and opens the door to precision. And when the reader is writing the ending, precision is king.

So, for unity's sake, clean up those documents.

Requirements - What’s the big hurry if they are going to change or be wrong?

It always appears to be rush, rush, rush, never enough hours in the day to sit with the business folks, host a JAD session, document what they want, type it all up, print out the requirements document and send it to a sea of people to who approve something they probably just skimmed through and will ultimately change their minds on anyway.....after the code is written.

SLOW DOWN!!!

OK, if you are a pure Agile shop, don't spend too much time reading this, the sprint is finishing and that piece of functionality is still not working. At least in an Agile environment we embrace change and the customer is part of the team and we review and change all the time and the requirements are adequate being defined to the "just enough" level of detail, the minutia will be worked out by the team and the customer.

However, back in the rest of the world, we spend less and less time on requirements and are eager to throw it over the old wall to development that in turn may see an ambiguous or incomplete requirement and happily code what they think the BA intended. This is then sent down stream to QA who in turn also sees the gaps in the requirements but has a conversation with the developer to fill in those gaps....before you know it, 40% rework on your average project.

So what can we do about this......Ultimately, we need to actually spend MORE time in the requirements phase of a project. Not so that we can add pages and pages of more detail to the "Big Freaking Requirements Documents" but so that we can create more clear, concise, unambiguous requirements and iterate through the process and work with the business to validate these requirements BEFORE we hand off to development. I sell a requirements tool for a living and I often get the impression that people think that a Requirements Definition and Management (RDM) tool will make the requirements process faster when in fact it should make the process a little longer (Shock horror I hear, how could he say such a thing). Well it is true. Tools really focus us on completing a detailed set of requirements; they add traceability that can be used to show completeness. Use Cases (UC) can be used for detailed walk through and simulation of the requirements, showing Wireframe and UI Mockups of applications that we have not started to build as yet.

Believe me, stepping through a UC or a simulation in a room full of people or via a web session will produce you far more feedback than any 300 page requirements document that you stuck on Sharepoint and emailed the approval group and told them they have 1 week to review. So take the time to approach requirements slightly differently, let's get them right before we pass them on and propagate any misunderstanding downstream to Development, QA and the Customer.

What’ll it be - Chaos Management or Requirements Definition?

I met with a prospective customer last week. Our introductory presentation identified the requirements-related challenges they had been trying to solve. We mapped those challenges to the strengths and value they could derive from our solution. The demo was smooth and very well received. Then, from the back of the room, came an unexpected question: "How is what you do any different from the Requirements Management we've been doing for years?" The question took me by surprise, but it shouldn't have. I get it a lot, actually.

Of course many of the companies we talk to are displeased with their current requirements processes. But sometimes, a vague understanding of a generalized, undifferentiated "Requirements Problem" is understood simply to be a difficulty with managing requirements, rather than authoring, visualizing, and validating them. My customer's question could be reworded: "We have a Requirements Management solution... why isn't it the answer to our problems?"

The answer is actually a bit more nuanced than you'd expect. It requires some understanding of the climate in which many of today's Requirements Management (RM) solutions were developed, and the problem they were intended to address. Let's turn the clock back 10 or 15 years, and look at the genesis of modern RM solutions.

It was an exciting time. IT budgets were booming. "Irrational Exuberance" inflated our 401k values. Everybody's Uncle formed his own .com, with the intent of selling it in six months and retiring to Barbados. Karl Wiegers had recently written The Book on Requirements, identifying many of the issues IT teams would face as they embarked upon the ambitious projects that would form the technical infrastructure of our new economy. CIO's, QA Directors, Development Managers, Enterprise Architects, and managers and practitioners of an emerging discipline called Business Analysis discovered, either through personal experience or through the work of Wiegers, Olly Gotel, Anthony Finkelstein and other requirements visionaries, that managing requirements is difficult. Stacks of documents, spreadsheets, textual descriptions of screens, use cases, diagrams... managing all this disparate content was difficult and time consuming. The result was that requirements themselves and the processes for developing and managing them (if, indeed, such processes existed) were a mess. In short, the requirements picture 10 to 15 years ago was Chaos.

RM solutions were crafted to address this specific problem. RM solutions specifically targeted the chaotic nature of developing this array of disconnected requirements artifacts. They offered hope for aggrieved IT personnel who found it impossible to manage the disconnected, poorly governed, and inconsistent information that defined requirements for the massive IT projects undertaken at that time. And these solutions helped. They provided a centralized repository for their Chaos, along with some nifty reporting and versioning capabilities. At any moment, IT managers could track which version of Chaos they were working on, the specific stage in their SDLC they had migrated their Chaos to, and some project timeline estimates as to when they'd be done developing their Chaos. These people were greatly relieved by the arrival of these solutions. "Now I can define traceability! Now I can version and baseline my requirements! Won't this be wonderful!"

But the discipline of Requirements Management primarily defined a means for organizing and applying change management practices to requirements. Change Management of Chaos results in... Managed Chaos, from which you can produce fancy reports.
The root of the problem remained; the content that fed these systems was still ambiguous, redundant, incomplete, and non-verifiable. Managing disconnected and unrelated requirements created the illusion that things were ok, when in fact, it merely masked the Chaos and passed it downstream to Enterprise Architects, Developers, Quality Analysts, Technical Writers, consultants, and other critical consumers of this information. Believing the requirements were good (after all, the project was using a fancy new Requirements Management solution), our ancestors rushed forward building their own work products, based on Chaos.

Life was hard for these people, in much the same way that life is hard for all early pioneers. We marvel in retrospect at the hardships they endured.

Fortunately, with the advent of tools specifically targeted to business analysts and other requirements authors, we have a means for developing high-quality content which can then be propagated to RM solutions. Rather than managing Chaos, we can now use these tools how they should have been used in the first place: to apply change management processes on information needed to build, test, and document systems that bring business value.

The choice for companies who have used RM solutions for many years is clear:
1. You can continue to use these systems to manage Chaos.
2. You can populate RM tools with high-quality, relevant, validated requirements.

 

A Requirements Definition workbench allows you to author requirements that accurately reflect the needs of the business, validate those, and then clearly communicate them to downstream consumers. You can then manage this information in the RM solution you have come to know and love* over the years, with the assurance that the information you're managing is a correct and validated representation of what your business stakeholders need. Now your versioning and change management processes provide real value. And the promise of RM is finally fulfilled. If only we could get back some of that Irrational Exuberance...

* - Or not, as the case may be. But that's a topic for another time.

Tools for the Business Analyst? Better Late than Never

In the 90's the Standish Group with their "CHAOS Report" quantified the alarming rate of project failure in the software development industry and the associated costs businesses incurred as a result. It also identified poor requirements as a primary contributing factor. Over the last twenty plus years, the CHAOS Report has consistently told us that the project failure rate has not dramatically improved and poor requirements continue to play a leading role.
RM or Requirements Management was a term coined to cover the entire problem set at the time and a push was underway to convince development organizations to stop relying on office automation tools (Word, Excel, PowerPoint, Email) to document and communicate their project's requirements throughout the SDLC. Solutions such as DOORs, RequisitePro, and CaliberRM were introduced to the market as RM repositories. Textual requirements were typed directly into these tools instead of a Word document and they could be used to track each requirement's priority, status, due date, risk factors, etc. Edit histories were automatically recorded and trace relationships could be established and maintained between requirements for more meaningful analysis of both requirements coverage and the impact of proposed change. The focus moved from the document to the individual requirements themselves.
However, this early RM approach assumed the correct requirements were entered into the repository to begin with and that was a false assumption. As the old adage goes "garbage in, garbage out". It doesn't matter how well you version, baseline, trace requirements to each other. If the starting requirements are incorrect, incomplete or missing altogether then the team will surely encounter some unpleasant and very costly surprises further down the line.
RD or Requirements Definition was born of the acknowledgement that requirements had to be discovered and defined properly before they could be managed forward through the SDLC. As you might expect, solutions appeared in the marketplace to help facilitate the accurate definition of requirements: DefineIT, SteelTrace, and Profesy (later renamed "Requirements Center").
Additionally, there was focus placed on the visualization, prototyping, simulation of requirements to enable true validation that requirements are correct, complete, and aesthetic concerns, important to the business users, were not left to developers to figure out. Again, solutions like Apptero, Simunication, and others appeared on the scene.
Today the industry knows this collective space as RDM: Requirements Definition & Management and it includes visualization/simulation. However, the desired goal is not a collection of standalone products each addressing their own specialty but rather, a single integrated solution that addresses all of the challenges analysts face day to day, effectively becoming their workbench.
Developers have had their IDEs and integrated source code repositories for decades. Likewise, QA has had their test management and execution platforms for years. Finally, emphasis has been placed on the intrinsic importance of requirements and getting them right and the BA community will get the attention they deserve in the way of holistic solutions catering to their needs as a defined profession. It seems we're the last in line but better late than never.