Business analysis is an important aspect of agile software development projects, but the agile approach is significantly different than the traditional, serial approach of yesteryear. Because the agile approach to business analysis is different the approach to requirements specification is also different, for many traditionalists this will prove to be a significant cultural shock to them at first. In this article I briefly overview how business analysis activities fit into an agile approach, question some of the dogma around documentation within the traditional community, summarize some of the evidence showing that agile approaches are more effective in practice than traditional approaches, and end with strategies for specifying requirements on an agile project.
Like any other religion, sorry architecture, SOA has its own language and meanings for the terms it uses. Unfortunately, some of these words can be very confusing, none more than the term "service". So here is a bluffer's guide to understanding and conversing in SOA-speak.
It's a sad topic, but it is reality. When a world wide pandemic, like the current swine flu hits, business suffers. Obvious economic issues come to mind, but what often slips the mind is what affects us even more. The interruption of normal business processes.
No matter what requirements gathering process you subscribe to-waterfall, unified, or another approach-your discovery will be markedly easier if you can identify the right subject matter experts from the beginning. Whether they exist inside or outside your organization, people who intimately know your project's product or service, its actors, and its building tools will help you create more inclusive requirements, identify your unknowns, and grow in your own knowledge of the industry.
Part 1 of this series examined the components a Business Analysis Community of Practice should optimally include. This article sets out the first four steps that must be taken in order to establish a successful BA CoP.
Getting your CBAP certification is a worthwhile and rewarding experience. True, it can be frustrating at times, but the IIBA has improved the process with their online application. Entering your information through the web site takes much of the drudgery out of the steps, but the requirements are still rigorous. If you plan to apply for the version 1.6 exam, plan to apply by June 1 to be certain of meeting their deadline. If there are any delays or questions in processing your application, you will have enough time to resolve them and schedule your exam before the deadline. Good luck in getting your CBAP!
IIBA, CBAP, and BABOK are registered trademarks of the International Institute of Business Analysis.
Wyeth CIO Jeffrey Keisling explains how working with the business on IT staffing helps promote IT-business alignment. He also outlines the two areas of hiring focus: business analysis and business process.
The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software. Software is everywhere. Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success.
It’s commonly agreed that it’s good to floss, eat plenty of fruit and have a Business Analysis Community of Practice. So why is there no common industry definition of what a BA CoP is, what it does, and how to protect it from “cost-saving” initiatives?
In this SOA article I would like to begin by defining what SOA is and what you need to know about it. In future articles, I will explore some of the challenges and benefits of SOA to the analyst community. Let’s start off with a definition of SOA. You can, of course, look at a number of definitions of SOA on the Web, but you will find them confusing and contradictory as there are a number of views on this ranging from SOA is everything, to SOA is just Web Services, neither of which is true.
Processes are the user interface to a solution – as such they are highly visible and a lot of project effort is focussed on process modelling. In fact, there is a perception in some quarters that Business Analysts just draw process models and this is all they do. However, process models (the drawings of processes) are only one facet of the specification of a process.
Have you ever thought the following thought while describing business processes? A decent percentage of the work business analysts (BAs) do is repetitive in nature. Business rules define the various subject matters, different businesses, or just differences in doing business. Just recently, I have again used a use case approach to a business process reengineering (BPR) problem. The aim was restructuring along natural business module borders, so that different applications (new and existing ones) can handle the business process more efficiently, more secure and within the right stakeholder's responsibilities. As almost always, documentation of the business processes had undergone aging as well.
Before starting, it is important to understand process mapping’s place in the larger context of business process improvement. Improving your process typically starts with documenting how it works today, what we call the “as-is” process.
In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly. In particular, I'll be mentioning storyboards, wireframes and prototypes. I'll also cover what level of quality and detail you should adopt when applying these techniques.
Not unlike gardening, Enterprise Analysis takes very careful stock and consideration of the current state of your environment. By IIBA® definition, Enterprise Analysis is:
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: