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.

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

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

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

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

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

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

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

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

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

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

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.

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

IAG Consulting’s new Business Analysis Benchmark makes one thing clear: almost 70 percent of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. That failure came at a significant cost: the average $3 million project cost companies using poor requirements practices an aver...

UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. Class diagrams are typically used, although not all at once, to: Explore domain concepts in the form of a domain model Analyze requirements in the form of a conceptual/analysis model Depict the detailed de...