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.

 

BA World Toronto 2010 – Great Success!

One of the largest Business Analysts events, BA World Toronto was a great success. With over 1000 attendees attending symposium track sessions and workshops, Blueprint held the silver sponsorship with a prime booth located right across the track session conference rooms. Exhibitors were there from May 17th to the 18th, and during that time, Terry and Toby successfully engaged potential customers, leading them to view demos and ask questions about Requirements Center 2010.

Blueprint also had a speaking slot on the first day of the event and Terry did a great job talking about agile requirements for application modernization projects.

For more photos, check out the Blueprint Facebook fan page!

Great job team!

Blueprint Deepens Integration with HP Quality Center !

Blueprint today announces the release of Requirements Center 2010 Feature Pack Two, further extending what is already the industry's leading integration with HP Quality Center. With this release the integration is now bi-directional meaning information flows in both directions between the two products allowing the rich definition features of Blueprint Requirements Center and the extensive management features of HP Quality Center to be leveraged iteratively, and at every point in the development lifecycle. The enhanced integration enables HP Quality Center users to communicate issues for further definition using Requirements Center, and then for HP Quality Center to receive the resulting requirement updates. Other enhancements include an expansion of information types that are populated into HP Quality Center including glossaries and business processes, and a new auto-save feature. Take a moment to see an overview of the Blueprint-HP solution followed by an on-demand demonstration.
If you have any further questions, as always just send an email to info@blueprintsys.com.

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.

 

BA World Ottawa - Off to a Great Start

When most trade events are hurting affair in these challenging times, BA World Ottawa is doing incredible for a first-time affair. I don't have official numbers but a rough estimate looking around the main hall during the opening keynote was approximately 120. Kathleen Barrett of the IIBA delivered the opening keynote "Evolution of a Profession" which helped provide a foundation for the subject matter of the event and gave insights to current trends in the Business Analysis space. The organizers cleverly had the Ottawa-Outaouais IIBA chapter meeting coincide with the Monday evening conference reception and opened it for all, so we expect another 60 or so people to attend. Will provide more updates before the show is over.

Requirements & Tests - The Perfect Marriage

Many consider tests to be artifacts distinct and different from the application requirements. When you think about it however, tests are really just very detailed requirements. Both requirements and tests describe what the application is "required" to do with the tests simply expressing this using a lot more detail. Since they both are describing the same application, naturally they must be in total alignment, which traceability helps to ensure. This is one reason why test-driven development or test-first programming concepts make total sense.

So it's only natural that modern tools like Blueprint Requirements Center have evolved to automatically generate tests from the requirements. When you add sophisticated test filtering (generate tests based on various filtering criteria) this becomes a very powerful capability indeed.

There's a very good book on the theory behind this model-based approach to test design and lots of tips and best practices. The book is by Shel Prince and is called "Software Test Design through Behavioral Modeling". In spite of the heavy title it's very readable and concise. The modeling approaches and techniques that Shel talks about and shows in the book can all be automated using Blueprint Requirements Center. Highly recommended.  You can get Shel's book here:   Software Test Design

Blueprint launches "EZ Eval" program

Blueprint takes the effort, time, and frustration out of tool evaluations with its new EZ-Eval program. The goal of tool evaluations is to get answers - will this tool support our process? can our people easily learn the tool? will this tool scale as our business grows? The Blueprint EZ-Eval program gets you the answers you need, fast.   Watch a short video describing the program, download the brochure, then take the next step by filling out the form and a Blueprint representative will contact you to answer any remaining questions and move forward.

Start Here