tagged by: requirements analysis

tags

API design · academia · agile · agile adoption · agile history · analysis patterns · application architecture · application integration · bad things · big data · build scripting · certification · clean code · collaboration · conference panels · conferences · continuous integration · data analytics · database · delivery · design · dictionary · distributed computing magazine · diversions · diversity · documentation · domain driven design · domain specific language · domestic · encapsulation · enterprise architecture · estimation · evolutionary design · expositional architectures · extreme programming · gadgets · ieeeSoftware · infodecks · internet culture · interviews · language feature · languageWorkbench · lean · legacy rehab · legal · metrics · microsoft · mobile · model-view-controller · noSQL · object collaboration design · parser generators · photography · podcast · popular · presentations · process theory · productivity · programming platforms · project planning · projects · recruiting · refactoring · refactoring boundary · requirements analysis · retrospective · ruby · scrum · software craftsmanship · talk videos · team environment · team organization · technical debt · technical leadership · testing · thoughtworks · tools · travel · uml · version control · web development · web services · website · writing

2014 · 2013 · 2012 · 2011 · 2010 · 2009 · 2008 · 2007 · 2006 · 2005 · 2004 · 2003 · 2002 · 2001 · 2000 · 1999 · 1998 · 1997 · 1996

All Content

BoundedContext

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

15 January 2014

bliki


CustomerAffinity

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

28 July 2006

bliki


FeatureDevotion

A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.

2 November 2006

bliki


HistoryIsNotBunk

History is more or less bunk

-- Henry Ford

I recently got an unhappy email from a reader of UML Distilled. It's never a good start to my day when an irate reader regrets buying, let alone reading, my words of occasional wisdom. But there was something particularly interesting about this reader's beef. His concrete complaint was about my 'unnecessary history'.

15 July 2003

bliki


OnsiteCustomer

On-site customer is one of the practices of extreme programming, one of the twelve mentioned in the White Book. It says that a customer should sit with the developers in their open work area to be available to answer questions and interact with the development team. Indeed they are part of the development team, and recognize that the success of the team depends as much on them as it does on the developers. They don't have to give up their reqular job to do this, but they must be physically present.

bliki


ScopeLimbering

One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like ThoughtWorks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?

27 October 2004

bliki


StandardStoryPoints

I've heard a couple of questions recently about coming up with a standard story point mechanism for multiple teams using extreme programming's planning approach. The hope is have several teams all using equivalent story points, so that three story points of effort on one team is the same as on another.

I think trying to come up with this at best of limited value, and at worst dangerous.

6 September 2004

bliki


UseCase

Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's.

bliki


UserStory

User Stories are chunks of desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes. You also hear the same concept referred to as a feature, but the term "story" or "user story" has become prevalent in agile circles these days.

22 April 2013

bliki

ConversationalStories

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

4 February 2010

bliki


DecreedStories

An approach where stories are written by product owners or analysts and passed to developers to build. I see this as a profound misunderstanding of agile thinking and thus greatly prefer ConversationalStories.

bliki


FixedScopeMirage

Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.

30 September 2004

bliki


ObservedRequirement

Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.

-- Suzanne and James Robertson

Agile methods violate this underlying assumption by intending to discover the 'requirements' during construction and after delivery. But even this cavalier disregard of the above sage advice is nothing compared to what many leading web sites do these days. These sites explore requirements by observing what the users do on their sites and using that information to generate ideas for new features along the following lines:

17 September 2008

bliki


RollerSkateImplementation

A key property of agile development is figuring out how to make a system go live with a small subset of features. We build software for the business value it offers, the quicker we go live, the faster we get at least some of that business value.

9 September 2007

bliki


SpecificationByExample

I was attending a workshop at XP/Agile Universe in 2002 when the phrase 'Specification By Example' struck me as a way to describe one of roles of testing in XP.

18 March 2004

bliki


TransMediaApplication

Mobile applications have been a hot item in software development over the past couple of years. Like many software delivery companies, ThoughtWorks get a lot of requests from clients asking us to build a mobile application for them. However most of the time a company asks us (or anyone) to build a mobile application they are starting off on the wrong foot. I'd argue that for most situations, even though you want users to interact with a mobile device, you should never think of building a mobile application. Instead you need to think about building a single application that presents across multiple devices: mobile, desktop, tablet - or whatever device your users might use.

1 November 2012

bliki


UseCasesAndStories

This is a common question, and not one that has a generally agreed on answer. Many people in the XP community consider stories to be a simplified form of use cases, but although I used to hold this view I see things differently now.

18 August 2003

bliki