6231 Views
0 Likes
0 Comments
Defining business requirements accurately is one of the most important success factors for technology projects.  Rather than focus on solutions that satisfy a list of requirements, we need to focus on solutions that satisfy desired business outcomes. The best way to achieve this is by performing business process modeling.  Employing a vi...
12036 Views
1 Likes
0 Comments

The difference between an art and a science is subtle but significant. An art form is based on the intuitiveness of the person performing the work, something that is difficult, if not impossible, to pass on to another human being. For example, apprentices serving under an artist may try for years to emulate the master, but may never attain his level of skill and creativity. In contrast, a science is based on a governing body of concepts and principles and, as such, can be easily taught to others.

13143 Views
7 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.

221799 Views
5 Likes
2 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 project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation.

7529 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...
8522 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:...
9810 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...
4239 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...
7880 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. ...
7268 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...
3200 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...
3567 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...
7160 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

5732 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...
10791 Views
2 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.

Page 68 of 77First   Previous   63  64  65  66  67  [68]  69  70  71  72  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC