Business Analysis Articles

Mar 07, 2021
231 Views
0 Comments
This article discusses extensions to commercially-available requirements management (RM) and application lifecycle management (ALM) tools. These extensions are intended to support the concepts presented in the Requirements In Context (RIC) series of articles. End-to-end requirement examples based on...
This article discusses extensions to commercially-available requirements management (RM) and application lifecycle management (ALM) tools. These extensions are intended to support ...
Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren’t there? Or our vocabulary shrank like ‘Honey I ...
Someone recently asked me “What does a typical day for a Business Analyst look like?” and my response was that if you do find someone who can articulately answer that q...

Latest Articles

8159 Views
3 Likes
0 Comments

Why has it been necessary to write so many different, book-length treatises about requirements management on software projects? Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts?

At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project. In the appendix, I include a detailed example illustrating the key ideas.

Author: Theodore F. Rivera, Software Group Strategist, IBM

7148 Views
1 Likes
0 Comments

The problem of business-IT alignment is of widespread economic concern.

As one way of addressing the problem, this paper describes an online system that functions as a kind of Wiki -- one that supports the collaborative writing and running of business and scientific applications, as rules in open vocabulary, executable English, using a browser.

Since the rules are in English, they are indexed by Google and other search engines. This is useful when looking for rules for a task that one has in mind.
The design of the system integrates the semantics of data, with a semantics of an inference method, and also with the meanings of English sentences. As such, the system has functionality that may be useful for the Rules, Logic, Proof and Trust requirements of the Semantic Web.

The system accepts rules, and small numbers of facts, typed or copy-pasted directly into a browser. One can then run the rules, again using a browser. For larger amounts of data, the system uses information in the rules to automatically generate and run SQL over networked databases. From a few highly declarative rules, the system typically generates SQL that would be too complicated to write reliably by hand. However, the system can explain its results in step-by-step hypertexted English, at the business or scientific level.

As befits a Wiki, shared use of the system is free.

Author: Adrian Walker

10756 Views
2 Likes
0 Comments

Good business solutions begin with good business analysis. But what's needed to excel as a business analyst and to get projects started on a good footing?

Much has been (and will continue to be) said about the set of skills that go to making a good business analyst. Forrester Research, for example, has published a spreadsheet (called the Business Analyst Assessment Workbook -- Note: subscription required) that lists more than 150 attributes of a good business analyst, grouped into categories such as Core Capabilities, Business Knowledge, Job-Specific Skills, Technical Knowledge etc. (I was particularly pleased to see this last category: It is important but not quite obvious that business analysts should also have a rudimentary general understanding of technology environments and architectures… mostly built up through seeing past analysis engagements fructify into delivered solutions).

Although the workbook is obviously intended as an assessment tool, I also found in it good for use as a training tool — for example, to bone up on technology approaches to business needs and to study sample projects, correlating the original business requirement with the type of solution delivered.

Here are 10 items from the Forrester list that I found particularly interesting and beyond the obvious (in no particular order)...

15294 Views
4 Likes
2 Comments

It has been just over a year since I published my book, and that makes it easier for me to measure what has happened since then.

I have spent this year visiting many companies and discussing their business analysis function. In some cases, I have performed an assessment on the business analysts as well as the business analysis function within many large Corporates.

It has now got to the point where I could document the findings before I start the investigation. The reason for this is that the problems are the same. From articles and discussions from other countries it appears the problems are similar the world over. These are the problems I encounter most often:

19199 Views
17 Likes
3 Comments
Why is it so challenging to get users involved in User Acceptance Testing (UAT)? Isn’t it called UAT because the users are the main participants? My experience has shown that involving users in all phases of the project, especially UAT, is the best way to ensure project success. This article will present a proven approach to increasing user involvement by addressing the problems with traditional approaches to UAT.
 
I recently worked on a project in which a major defect was found after the software application moved to production. This defect caused the users to perform three days of manual processes. Users on the IT project team worked countless overtime hours. The defect also resulted in a frustrated user group and business sponsor. The project team’s morale was low and the business users lost a great deal of confidence in the project team’s ability to deliver quality software solutions. To reduce the risk of making this crucial mistake in the future the project team improved the UAT approach by getting users more involved.
11816 Views
9 Likes
0 Comments

Here we are, the end of another year, and the question I ask always is, what have we learned?

If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?

Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store.

A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting.

The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.

13626 Views
6 Likes
2 Comments

Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available?

Each organisation seems to have its own ideas about the role, skills, responsibilities and expectations of the Business Analyst. Given the importance of the job, a common definition would assist both practitioners and employers. We explore some of the issues here.

Written by Derrick Brown, IRM's Director and instructional designer, it shares first hand observations and experience gained from training thousands of Business Analysts since 1980, first in the UK and since 1984 in Australia.

Author: Derrick Brown

8214 Views
7 Likes
0 Comments

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

25676 Views
30 Likes
2 Comments

“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

24250 Views
17 Likes
1 Comments

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.

8645 Views
7 Likes
0 Comments

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!

69931 Views
31 Likes
9 Comments

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).

14415 Views
4 Likes
0 Comments

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.

6010 Views
2 Likes
0 Comments

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

4914 Views
1 Likes
0 Comments

Information is ever more critical to the success of organisations and information professionals should be hot property. But as information discovery begins to be perceived as automated, the power base is shifting to those who can analyse information that is ever more devoid of structure.

The business analyst, once an IT/business hybrid role, is evolving to fill this gap and this role looks set to overlap and overtake the traditional information professional role.

Richard Beveridge, director of library services at Tribal Group, says: “In my opinion a business analyst is not a seeker and discoverer of information, it is a person that actually does something with it. Information professionals would go off for information on someone’s behalf, but now organisations need people who are able to seek information and do something with it. If information professionals don’t evolve they will be under threat from business analysts.”

He adds: “Now you have to be able to make a contribution to the bottom line and that has to be measurable. I am stunned by the number of people in the library service who say, ‘I didn’t join to sell things.’”

Author: Tracey Caldwell

Page 58 of 67First   Previous   53  54  55  56  57  [58]  59  60  61  62  Next   Last   








Copyright 2006-2021 by Modern Analyst Media LLC