Articles

We all strive to write the perfect requirements. Many of us are familiar with the somewhat vague, ubiquitous and poorly conceived scribbling that are jotted down in the brief few minutes that we get to spend with the stakeholders and subject matter experts (SME).The stakeholders and SME’s tell us about a new, brilliant, wonderful and life changing system that will be implemented later this year….(hopefully); and we struggle to use our scribbling to write the requirements to bring this system to life.

Studies show that somewhere between 25-50% of software project budgets are consumed by re-work. That means work that needs to be done again because, for some reason, the results were not correct. Significantly, 70-85% of this rework is directly related to poor requirements. Of course, we all know that there are many reasons requirements fall short and that there are many things that can be done to remedy this. But if the wasted budget wasn't enough to think about, there's more!

As a requirements solution vendor we talk with people every day about their requirements issues, assist them to understand the root causes, and help them articulate a business case for investing in a solution. For most companies, the biggest single inefficiency in their software development efforts is the amount of rework that's done due to inadequate requirements.

After reading the blog, some of my customers inquired "just how long does it take to do proper requirements development?" Honestly, there is no set time to this question. However, I can categorize some environmental factors that can extend the time required for proper requirements development.

I've worked primarily for vendors in the SDLC tools and process space with a direct focus on Requirements Definition & Management (RDM). In this capacity I've worked with hundreds of organizations analyzing their RDM processes, tools, and deliverables in an effort to help them gain improvements. All during that time our own industry analysts have reported a very discouraging failure rate for IT projects and consistently listed deficiencies in the requirements arena as the major contributor.

Many organizations that I work with understand that better requirements engineering practices would alleviate many pains in their current software development lifecycle (SDLC). But some of these organizations don't know how to improve their practices because, I believe, they don't fully appreciate the world of requirements engineering.

In recent years, I have discovered that more and more organizations are writing use cases to clearly understand the behaviours of their systems. Working with these organizations, I usually get the question “What Use Case standard should we utilize?” The answer depends on the project situation. I have utilized two simple use case formats that will help you document use cases in some of the following common situations:

A use case describes a system's behavior as it positively or negatively responds to a request from a stakeholder under various conditions. Thus, use cases provide a convenient user/functional test description for the system under definition. As organizations mature into a Quality Center of Excellence, it decreases a tester's ability to know the systems under test in any detail because they are tasked out to test just about everything in that organization.

Blueprint announced a new series of webinars, featuring analyst firm voke, that focus on changing the economics of software development. Running through November, these webinars help companies business and IT executives and managers of software enterprises responsible for driving new efficiencies and economies in their approach to application software delivery.

Writing requirements is like writing a story in that our goal is to convey information in such a way that everyone who reads the story can clearly understand and visualize the unfolding events, overall plot, and ultimate ending. From a requirements standpoint, there are three distinct aspects to writing the story and these make up the 1-2-3 of Business Analysis.

Many IT systems continue to rely on legacy mainframe back-ends that absorb intense amounts of financial and human resources. New technologies and initiatives (such as service oriented architectures (SoA), virtualization and server consolidation) are pressuring IT to re-think application deployments in terms how they impact the bottom line.

Blueprint Software Systems Inc. has demonstrated a commitment to innovation and quality that is reflected in their selection as a finalist for the CODiE Awards.

Kathleen McGoey, Director of Development Support Services at LexisNexis, was honored with the award for her ongoing work in leading significant improvements in her organization's software requirements practice.

If you were somehow able to hold a requirement in your hand and ask, "Why do I need this? What is its purpose?" I would offer that you're holding an agreement. A requirement is how two (or more) people have chosen to express their agreement regarding what is needed from a software application. The assumption is that all parties have the same understanding or interpretation of these written words. Quite often this assumption proves to be false - different stakeholders in fact have different ideas in their minds regarding these same words, and confidently think that others share their vision as they warmly smile and shake hands over the agreement.

Why Adopt the Requirements Center of Excellence Model? The Centers of Excellence (CoE) trend has gained traction recently within the IT departments of large organizations. In fact, the META Group refers to the model as "the next step in IT's evolution"

The phrase "the world runs on software" is almost cliché now. Everyone's life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you "get it right" the benefits of implementing business in software can be tremendous. If you don't "get it right" you can find yourself out of business.

Use cases have been around for some time now, bursting onto the public spotlight at the 1987 OOPSLA conference in Orlando. Since that time they've been used in countless projects. In some situations use cases have excelled, producing remarkable results while in many others they've failed miserably.

What if software requirements review sessions could actually be fun? If people actually requested to be on the invite list? If attendees could feel confident about what they are signing their name to? As the world of business analysis matures rapidly, so does the requirements walkthrough.

The Blueprint Resource Center is a seamless, cloud-based collaboration solution that can be leveraged by the industry business analyst community to accelerate and align global project teams. The new Resource Center leverages syndication technology to draw content from multiple sources throughout the Internet as well as customer intranet resources.

The report highlights the need for improved use of solutions to help the business analyst closely align requirements with the business needs. 91% of the study's participants say the solutions they use to define requirements are static and do not meet the dynamic nature needed for today's business analyst. The report also identifies a lack of integration between existing requirements definition solutions and the creation of test cases. A total of 76% of survey participants manually create test cases from their requirements.

The key challenge with maintaining legacy systems is developing new functionality and enhancements, often without a clear understanding of how the system works. The good news is that products and approaches are emerging to help solve these problems.

Agile development methods focus on defining "just enough" requirements detail for the next sprint. In other words, don't produce any requirements specifications that are not absolutely critical to getting the point across to the rest of the team. So how do you decide what is "just enough," and who makes this decision? What happens when the team is co-located or distributed? How do you deal with changes to these requirements details and their priorities? Let's take a look at the answers to those questions and others.

The new release offers: Blueprint Definition Server, a central repository allowing users to access files in one location, with version control, configuration management, and baseline publishing supported; Blueprint Change Management, enabling teams of users to consolidate work threads into a single baseline; enhanced integration with other ALM products' including HP Quality Center 9.2 for requirements management and test-case generation, and Microsoft Visio for modeling; and an improved user experience supported by the ability to open multiple requirements models simultaneously, a new graphical editor, and a set of utilities to help explore projects stored in the Definition Server.