“Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system.

In this article we’ll take a brief look at which of the 13 diagrams are of most relevance for us and how they fit together...

Author: Jan Kusiak

Across North America, businesses in all sectors are adopting standard development methodologies to turn out a higher quality of goods and services. The tried and true approaches that have yielded such great results for competitors are heralded as best practices. But here is the sad news: no one methodology fits all. In fact, different methodologies are appropriate in fitting diverse projects. Some projects are so unique, future-thinking Business Analysts (BAs) are finding that the adoption of new hybrid concepts is the only smart way to go in problem solving tomorrow’s projects.

The word ‘fresh’ describes that feeling of turning over a new leaf when January 1 rolls around each year – and the sentiment we as individuals strive to maintain all year long when we set New Year’s resolutions. Much in the same vein as these annual goals, BAs seeking an innovative means by which they can see their requirements come to fruition are increasingly interested in the study of the existing methods that are in place within the industry, as well as fresh methods established through modeling and fusion.

It’s Monday morning and, as you arrive at your desk, you know that it is going to be a busy day. The new portal project is going to be promoted into production in a couple of weeks and there are still a few items to clear up.

As you fire up your e-mail client and take the first sip of coffee, your shoulders start to tense up. The subject line of one of your e-mails reads “Threat Risk Assessment Finding Report” and it is marked important.

This not the way you wanted to start the week, but you remember the report was due on Friday, the day you decided to “call in sick”.

As you open the message, realizing you can no longer avoid it, you cross your fingers hoping it won’t be too bad.

Then you remember why you hate these reports so much, they are confusing and seem overly alarming in their findings.

Critical, Severe, High, Medium and Important findings all over the place, red, orange and yellow screaming in your face, reams and reams of technical output, patches missing, vulnerabilities exposed, buffer overflows, exploitations amok, privilege escalations, and on and on. Oh your head hurts now.

Where do you begin? What’s important, and how much is this going to push the timeline back? You know the launch is in two weeks and there are functional issues that need to be addressed, there is no time to deal with all this!

Here’s a question that often gets asked: What are the benefits of Business Analysis? The depressing but true answer is that the benefits are usually invisible: good Business Analysis ensures that the project implements the right solution, and because it is the right solution no-one ever sees all the cost, time and effort that has been avoided (a project that does not do sufficient Business Analysis has to re-work all the bugs that slipped through the ‘analysis’ stage because the analysis was never done).

The ubiquity of software project failures – with failure defined as projects that fundamentally failed to meet business-sponsor expectations, missed scheduled completion dates, or exceeded budget – is a pronounced theme in any number of independent research reports on custom software development. The Standish Group, for example, cited that only 31% of projects delivered 100 percent of the expected value, were on-time, and on-budget and a report from the Aberdeen Group found 90 percent of projects came in late, of which 30 percent were simply cancelled before delivery.

Analysts and users alike cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group’s annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. Requirement miscommunications is also the primary factor behind the prevalence of rework, which according to industry statistics, can add up to 40 percent of the total development effort within a given software project. A 2005 survey conducted by iRise and Decipher found that almost three-quarters (73%) of organizations budget for rework, thus, in effect, planning for failure. Moreover, almost one-third set aside more than 25% in their budgets for these change orders, money that could be funneled directly into innovation rather than re-doing work that should have been com¬pleted the first time.

Ultimately, rework costs companies the ability to get to market quickly and saps competitive advantage; while companies are busy fixing applications, their competitors are busy capturing market share.

The solution to these costly, frustrating problems is the creation of accurate requirements before development even begins. By allowing the business analyst to col¬laborate with stakeholders, users, architects, user expe¬rience designers and developers early on in the development process, all parties are involved in the definition of the product and all parties know what will be built long before a single line of code is written.

The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community.

The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements.

Author: Scott Ambler

Study after study has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints.

Nonfunctional requirements (NFRs), also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints.

Author: Scott Ambler

Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.

Author: Jan Kusiak

Many of us are familiar with the process of business analysis – start by gathering requirements from stakeholders then turn them into a specification which developers can understand. These days however, we need to do more than just document the requirements.

We need to work with stakeholders and business users to understand their systems and analyse their problems – why do you do it this way, why not that way? This is the real value add that the analyst brings to the table. It means challenging the status quo, pushing the boundaries, looking for alternative or creative solutions.

To develop a solution - unless we’re very lucky - we first need to understand the problem that drives the need. In this paper we'll look at how to understand and define business problems – part 2 will look at how to generate solution ideas and part 3 will cover how to choose the best ones.

Author: Jan Kusiak

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.

This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.

Every career has a set of skills that one needs to do their job, and a set of tools to carry out the various tasks required to display their skills. Same is the case for the analyst involved in security assessment... I have chosen the all mighty checklist as my tool of choice for this article.

Every area of practice in IT has a set of specific “tools” that supports the standard work of technology professionals. Data Analysis is the capture of data requirements, development of models that reflect those requirements and creation of design to store the data. You can accomplish this with a pencil, paper, and the right skill-set. But it can be done much more quickly and consistently if the process is automated.

There are hundreds of individual software tools and tool-suites that support different facets of data analysis.

Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?

Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.

Change seems to be a popular word in this pivotal election year. When I think about change, I recognize that it impacts each of us in many forms. One of the biggest changes I’ve experienced as a Business Analyst was the transition from working requirements in a traditional project lifecycle to an Agile methodology. The change was introduced to my project team as a management directive with management support.

Our project was an enterprise initiative funded as a multi-year program. The program was comprised of three parallel workstreams with shared releases. Our workstream’s objective was to build out data and data services for the other workstreams and the enterprise to use. The team was made up of experienced Information Technology (IT) professionals and a brand new business unit. We were halfway through the program’s duration when our workstream was called upon to employ Agile methods. The other two workstreams we serviced stayed with traditional waterfall software development, which presented challenges interfacing with each other. The entire program had already completed a Business Architecture phase that outlined the program’s objectives, future state vision, and capability implementation plan.