Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

An enterprise exists for a purpose, stated in its high-level goals and business model. It also has everyday operations which may or may not serve this purpose. We need a link between the two and this is what Enterprise Architecture is about – the establishment of a link between an organization’s ultimate goals and its day-to-day operations.

An activity diagram is a type of flowchart that is part of the UML (Unified Modeling Language) standard. Its purpose is to enable analysts to present a concrete, easy-to-follow visual of the workflow of a business use case.

We can probably all agree that Knowledge Management is generally A Good Thing and that we should do more of it. But what does “doing Knowledge Management” actually involve, and how as BAs can we ensure we effectively reuse our knowledge?

“Requirements are rules. They arise from business models, but they are different from those business models.”  Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they?  No!  Read this article to find out why.

In that article we presented our case that the typical approach to business requirements management was fundamentally flawed, with key issues being development of business requirements within a project context, and capture of those requirements using unstructured artifacts, particularly narrative.

This month’s column explores the biological basis of human decision-making based on Lehrer’s book. However, it also suggests that lessons from the human brain can sharpen our decision models2 and enhance the process by which we create and manage them.
 

In an increasingly competitive marketplace, the practice of resume writing is not what it used to be. Resumes must be more clean, concise, and convincing than they were in recent years. Today’s business analysts need every edge they can get.

The ownership of business processes is often a bone of contention – with various parties feeling that they should be considered the owner of certain processes and not of other processes. Inability to agree on ownership can lead to turf-wars when there are perceived overlaps, as well as impactful inaction when no clear owner has been identified.

This article analyses the source of ownership conflict, and makes suggestions regarding resolutions to the problem. It considers the issue of ownership, as well as the issue of custodianship.

Mobile application development is hot. Smart phones and tablets sales are exploding, and technical teams are exploring ideas for new applications. With new development work, sometimes roles like Business Analysis get left behind as programmers rush to code a new mobile app. Even when we’re in a rapidly changing industry, taking a bit of time to work on design is still important. In fact, it can be the difference between an application that is used and one that is discarded and left behind.

Ladies and Gentleman of the class of 2011, adopt SOA. If I could offer you only one tip for the future, SOA would be it. The long term benefits of SOA may not yet have been proven and my advice has no basis more reliable than my own meandering experience. I will dispense this advice now.

In this article, I explain a project completed in the financial services industry. A client asked me to lead a project to redesign a failed sub-process that had resulted in billions of dollars of backed up financial transactions. This particular financial process had a history of failed and abandoned process improvement projects. The pressure was on and, I must confess, I was not entirely sure that The Decision Model would be a good fit.

While my co-workers know me as a manager of Business and Systems Analysis, others know me as a Triathlete (A triathlon is multi-sport event involving the completion of three continuous and sequential endurance events; most commonly swimming, bicycling, and running).  It was while reading a recent article about Triathlon that I began to draw a strong parallel between achieving career goals as a business analyst and achieving goals as a triathlete. 

Once while teaching a business analysis elicitation course, a student in the class asked me, “Have you ever had a wasted interview with a stakeholder?” The question took me back, a surprise; a question I had not been asked before.

In an ideal world, all software projects would have an interaction designer or user experience (UX) specialist working with the team to ensure that the product is designed in a way that truly satisfies the needs of end-users. In a software project with separate business analyst and interaction designer roles, the work of these professional is complementary