Business Analysis Articles

Jun 23, 2019
499 Views
0 Comments
Many years ago, I was a little league baseball coach. If you have ever had this experience, you quickly discover that the learning opportunity goes both ways between player and coach. For example, it was the first game of the season and we were the visiting team. At the top of the second inning, the...
Many years ago, I was a little league baseball coach. If you have ever had this experience, you quickly discover that the learning opportunity goes both ways between player and coa...
A business analysis consultant might perform three types of roles when working with clients: expert, pair-of-hands, and collaborator. Each of these represents a different kind of i...
The ability to build and exude self-confidence can contribute to success in many areas of our lives from personal to professional. Unfortunately, many business analysts who are beg...

Latest Articles

8751 Views
0 Likes
0 Comments

Having been involved with the systems methodologies field for over 30 years I have been occasionally asked what percentage of time in a project should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study, Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a means for estimating the remainder of the project. For example, if I were to say Phase 1 represents 10% of the overall project, they would simply multiply the amount of time spent in Phase 1 by ten. This is an unreliable approach for estimating which is why I usually balk at giving out such figures.

Author: Tim Bryce

189709 Views
4 Likes
3 Comments
Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall projec...
6181 Views
1 Likes
0 Comments
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead agilists will do just enough initial requirements envisioning to identify their projec...
7594 Views
1 Likes
1 Comments
To be honest, I'm not very enamored with the term "best practice". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:...
8140 Views
4 Likes
0 Comments
Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the r...
5717 Views
1 Likes
0 Comments
Test organizations can realize significant gains in test quality by harnessing the power of use cases. For years, developers and business analysts have employed use case models to capture requirements. Test organizations can greatly benefit by using these same use case techniques. Well-constructed use cases provide value to testing efforts in terms...
3845 Views
0 Likes
0 Comments
This article, actually a compilation of three articles, provides proven advice for applying agile strategies on IBM® Rational® Unified Process®, or RUP®, teams. The articles are written by Mark Lines, Joshua Barnes, and Julian Holmes respectively, co-founders of Unified Process Mentors (www.upmentors.com). These three have mentored literally thousa...
4983 Views
1 Likes
0 Comments
There are three basic reasons why you might need to model a business: to re-engineer a business, to improve a business process and to automate a business process. Nevertheless, another reason may be very useful for analyst of software systems and their customers – to understand and automatically generate functional requirements to the system. ...
5980 Views
3 Likes
0 Comments
First, I'm a project focused software developer, team lead, designer, architect, jack of all trades, who has been on projects that have used various methodologies over the years, including of late some agile projects. I'm not a big blog reader, or a big blogger, but like most people I have an opinion on things, and for some reason that opinio...
2790 Views
1 Likes
0 Comments
Agile software developers, just like traditional software developers, perform analysis activities. Unlike traditional developers, agilists approach analysis in a highly collaborative manner and do so on a just-in-time (JIT) basis. Analysis is so important to us we do it every single day. In this article, I discuss: What is analysis? Ret...
3313 Views
1 Likes
0 Comments
In this issue of the IIBA Newsletter: IIBA Blog Spotlight As the IIBA is a virtual organization, the Blog is an integral way for the Senior Leadership Team (SLT) to communicate with members worldwide. The topics range widely: from technical pieces such as BABOK® updates to more informal pieces like “A day in the life…” 2008 CBAP Exam Dates Date...
5565 Views
0 Likes
0 Comments

My friends and colleagues often ask me how I am able to produce so much in so little time.  Although I am flattered by such compliments, it's really not much of a secret which I attribute to the following areas (in no particular order):...

Author: Tim Bryce

5215 Views
0 Likes
0 Comments
A project manager's first task after being appointed to an IT development is to seek out a business analyst to gather requirements. After that, it's on to the development and then the implementation. It's the way it's done. It's the way it's always been done. But business analysts are not used optimally if they are only used to "gather" require...
7776 Views
1 Likes
1 Comments

Have you noticed the examples of requirements elicitation on my blog? In one case, I had a bit of a contest, using a game to elicit information. You can see this technique by looking in the category Online Game on the blog. Then I had a survey to elicit information. You can see that survey by looking in the category Survey on the blog. Today I am going to use the information from the survey to show you another technique you might use when developing requirements. That technique is writing Personas (or Personae for you Latin fans).

You write a Persona when you want to understand your customers better. This Persona is a story you will tell about a typical (but not real) customer. The Persona is a composite story about your typical customers, made very lifelike. 

Author: Geri Schneider Winters

3965 Views
0 Likes
0 Comments
Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increas...
Page 58 of 67First   Previous   53  54  55  56  57  [58]  59  60  61  62  Next   Last   





Copyright 2006-2019 by Modern Analyst Media LLC