tagged by: requirements analysis

Bounded Context

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.

Conversational Stories

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.

Customer Affinity

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.

by Martin Fowler

28 Jul 2006

Read more…

bliki

agile team organization requirements analysis

Decreed Stories

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.

by Martin Fowler

Read more…

bliki

requirements analysis

Feature Devotion

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.

Fixed Scope Mirage

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.

History Is Not Bunk

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

by Martin Fowler

15 Jul 2003

Read more…

bliki

requirements analysis legacy rehab

Observed Requirement

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:

by Martin Fowler

16 Sep 2008

Read more…

bliki

requirements analysis

Onsite Customer

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.

Roller Skate Implementation

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.

Scope Limbering

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?

Specification By Example

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.

by Martin Fowler

18 Mar 2004

Read more…

bliki

testing requirements analysis

Standard Story Points

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.

Trans Media Application

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.

Use Case

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.

by Martin Fowler

Read more…

bliki

requirements analysis uml

Use Cases And Stories

What is the difference between a UseCase and XP's UserStory?

by Martin Fowler

18 Aug 2003

Read more…

bliki

requirements analysis uml

User Story

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.

by Martin Fowler

22 Apr 2013

Read more…

bliki

agile requirements analysis


All tags

API design · agile · agile adoption · analysis patterns · application architecture · application integration · bad things · big data · board games · build scripting · certification · collaboration · computer history · conference panels · conferences · continuous delivery · database · design · dictionary · distributed computing magazine · diversions · diversity · documentation · domain driven design · domain specific language · domestic · encapsulation · enterprise architecture · estimation · event architectures · evolutionary design · experience reports · expositional architectures · extreme programming · front-end · gadgets · ieeeSoftware · infodecks · internet culture · interviews · language feature · language workbench · lean · legacy rehab · legal · metrics · microservices · mobile · noSQL · object collaboration design · parser generators · photography · podcast · popular · presentation technique · privacy · process theory · productivity · programming platforms · programming style · project planning · recruiting · refactoring · refactoring boundary · requirements analysis · ruby · security · talk videos · team environment · team organization · technical debt · technical leadership · test categories · testing · thoughtworks · tools · travel · uml · version control · web development · web services · website · writing

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

All Content