Archive for the ‘Documentation’ Category

Context Counts: Adapt Your Requirements Practices to Fit

Friday, February 21st, 2014

ShuHaRi Whether you are agile or more traditional, your challenge is the same: In order to remain relevant in today’s market, you have to discover and deliver the right thing at the right time. To do this successfully, you need to elicit customer needs and quickly choose from among many competing voices and options to determine what is truly essential and what can wait for a future release. That means selecting the requirements development and management activities that are most effective for your particular situation–whether those practices are in your current toolbox or not.

To understand this mindset shift, it might help to think of requirements activities in terms of the ShuHaRi progression, with a learning stage (shu), a breaking away stage (ha), and a transcendent stage (ri). 

Rope Your Scope: Reining in Scope Creep (Part II)

Wednesday, June 19th, 2013

Slide1Last time, I told the story of a team that experienced a breakthrough after clarifying the scope of a stalled project. Noting that scope creep—the unrestrained expansion of requirements as the project proceeds—is cited as one of the top project risks, I promised to describe some of the good practices that help product partners manage product scope in a disciplined way. With clients, I always stress the importance of developing a product vision, identifying goals and objectives for the product, and clarifying the product partners’ value considerations very early in the project before development proceeds. Let’s look at ways to do that. Continue reading | 1 Comment

Rope Your Scope: Reining in Scope Creep (Part I)

Thursday, May 9th, 2013

scope creep image 2- contextRecently I worked with a project team developing a software product under grant from four entities, with a government agency as their ultimate customer. They called me in because, three months into a four-month project, they were desperately behind. Why? They’d been spinning in circles, trying to satisfy diverse stakeholders who had overlapping as well as conflicting requirements. The funding was split among several competitors, each with its own competencies, and there was a sense that the government agency was playing favorites based on its own preferences in the domain. Continue reading

Software That Matters: A Review of Gojko Adzic’s Impact Mapping

Wednesday, February 6th, 2013

Impact Mapping: Making a Big Impact with Software Products and Projects, by Gojko Adzic, explains how to use an efficient visual modeling technique to ensure that project partners build the right products—or, as the author says, products that have impact. Impact mapping, the subject of this lithe, approachable book, is an adaptation of visual mapping techniques (effect mapping). Continue reading

Using “Given-When-Then” to Discover and Validate Requirements

Sunday, December 9th, 2012

By Mary Gorman and Ellen Gottesdiener

In our book Discover to Deliver: Agile Product Planning and Analysis we discuss the usefulness of the “Given-When-Then” technique to explore (discover) and confirm (validate) product options. Here we summarize the technique*, brainchild of Dan North.

What it Is 

Given-When-Then (GWT) is a structured format for expressing scenarios with example data, including pre- and post-conditions.

Usefulness

GWT helps project stakeholders (business, customer and technology partners) communicate using business domain language. You can use GWT to explore product options and confirm selected options and confirm selected options, in a concrete, tangible way. Often called “specification by example,” GWT provides living documentation for your delivered product. It simultaneously specifies requirements while identifying acceptance tests, thereby streamlining discovery and delivery. Continue reading | 11 Comments

Tips on Software Security Requirements

Tuesday, December 13th, 2011

Security requirements are a difficult quality attribute to elicit and specify. (Quality attributes are one the three types of nonfunctional requirements—along with interfaces, and design & implementation constraints*). Distinguishing can help. So too, it helps to

Sue Burk distinguishes between security requirements and security controls, shares four categories of security requirements, provides suggestions for eliciting security requirements, and explains why making them testable is important in her expert response. Continue reading

Requirements Tips for Data Centric Projects

Tuesday, June 21st, 2011

Are you working on data-centric software products? For example, ones that involves building a data warehouse, using extract-transform-load (ETL) and getting the gold—delivering business intelligence and analytic reports and queries for business decision makers?

Sue Burk shares the value of scenarios to define acceptance tests, and other practical techniques to improve your success with these data-centric projects in her expert response. Continue reading

This Week’s Business Analysis and Requirements Workshop: 2 Days of Learning in Las Vegas

Tuesday, June 7th, 2011

I was recently interviewed by SearchSoftwareQuality editor Yvette Francino about this week’s Business Analysis and Requirements Workshop at the Better Conference/Development Conference this week in Las Vegas, Nevada (6-7 June, 2011).

Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair, Continue reading | 1 Comment

Are Your Software Development Practices Jumping the Shark?

Thursday, April 7th, 2011

By Ellen Gottesdiener and Mary Gorman

In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the expression “Jumping the Shark” was born. When a TV show, or anything else, jumps the shark, you know it’s on its way out.

Our question this month: have any of your software development practices jumped the shark?

For example, are there boundaries around people’s roles? Some organizations tend to confine people to roles such as developer, architect… Continue reading

Ways to Understanding Product Functionality in the Absence of Documentation

Tuesday, March 15th, 2011

Have you been in a situation where there’s no documentation, yet you’re expected to understand functionality?

Trial transactions and observing behavior is one answer. But understanding context is also important.

Sue Burk suggests creative solutions in her expert response.