How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.
Before an organization releases a new piece of software or web feature to all of its customers or the general public, it will generally offer a limited audience a chance to test drive the feature and offer their feedback. This is generally known as a Beta launch...
This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.
We BA's are occasionally asked, "What do you do?" I try to make a joke out of this innocent question by replying, "Well, what would YOU do with English and writing degrees? I'm a Business Analyst of course." People don’t laugh.
Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.
For most businesses and organisations, if IT stops, the business stops. Whenever a company turns on a new production line, opens a new retail store, launches a new product or provides a new service, there is invariably a new or modified IT system behind it. Going live is the culmination of time, effort, resources and finance. A problem-free IT system is the “acid test” of significant, often crucial investment.
Whilst the technical testing of IT systems is a highly professional and exhaustive process, testing of business functionality is an entirely different proposition. Does the system deliver the business functions that are required – does it follow the company’s business rules – does it support a government department’s obligations - does it cope with exceptions?
The people who have to make these decisions – to accept or reject the new system – are the business users. It is therefore critical to get the business user involved in testing and not rely only on the technicians. In this paper we explore the rationale behind User Acceptance Testing (UAT), why it is so important, and how best to go about it.
Author: Jan Kusiak
Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.
In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.
Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?
Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.
Author: Glenn R. Brûlé
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us