A look back at the best from this week in the past.

Foundation Series: Functional Testing of Software

Functional Testing, also referred to as System Testing of software is the practice of testing the completed software to confirm that it meets the requirements defined for the software. A functional test is typically a test of user interactions, but can also involve communication with external systems. We contrast functional testing with unit testing. We also show how functional testing provides different benefits than unit testing.

Requirements Documents – One Man’s Trash…

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

One-Page Marketing Template

Kelly Odell posted a single-sheet marketing plan template, after being frustrated with the massive templates that others have promoted in the past. John Sviokla recently wrote about how the 4-P’s of marketing are changing to the 5-P’s of marketing. Marcus Ting-A-Kee found John’s essay and wrote about it yesterday. Guy Kawasaki suggested that Kelly adapt his template to John’s new approach. Kelly chose to mix the best of both worlds. We add our own spin at the end.

A look back at the best from this week in the past.

Foundation Series: Continuous Integration

Continuous Integration

Continuous Integration is the software development and quality process where all team members merge their code and verify it frequently – at least daily. This verification project includes both an automated build process and automated testing. The main benefits of continuous integration come from risk-reduction and cost-reduction.

Ten Essential Practices of Continuous Integration

Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:

The Agile Dragon

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.

A look back at the best from this week in the past.

Where Did You Get That Estimate?

How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.

Challenging Requirements

The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.

Joel Spolsky Speaks Specs

(Joel Spolsky)

It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.

Another for the wish I had said that list. Joel Spolsky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software

A look back at the best from this week in the past.

Persona Grata

Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.

Is Agile Bad For Software Development

Last week, Ivan Chalif, a product manager / blogger, tapped into a thread criticising product managers for not adopting and espousing agile, or at least rapid-release techniques. In this article we look at Ivan’s comments and one of the articles that he referenced. We also share our own perspective and an alternative analysis of what may have happened.

Foundation Series: Basic PERT Estimate Tutorial

PERT = Program Evaluation Review Technique

PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of how good the estimate is. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.

A look back at the best from this week in the past.

How To Use Timeboxes for Scheduling Software Delivery

Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.

The Difference Between Test Cases and Use Cases

People who are new to software, requirements, or testing often ask “What’s the difference between a use case and a test case?” This article answers that question, by building on earlier articles about use cases and use case scenarios. At the soundbite level, each use case has one or more scenarios, and each use case scenario would lead to the creation of one or more test cases.

What Are Use Case Scenarios?

It is easy to mix up the definitions of use case and use case scenario. A use case represents the actions that are required to enable or abandon a goal. A use case has multiple “paths” that can be taken by any user at any one time. A use case scenario is a single path through the use case. This article provides an example use case and some diagrams to help visualize the concept.

A look back at the best from this week in the past.

Targeted Communication – Three Tips

Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.

This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development – communication from the team, to stakeholders and sponsors.

Agile Development of Use Cases

We proposed a strategy for developing use cases as part of an agile development methodology last week. In this article, we will look in more detail at that proposal, and also look at a specific way to apply agile techniques to the development of the use cases. What we propose is essentially incremental development of use cases, and starting what comes next as soon as you can.

Competent Users and Software Requirements

We were all student drivers at one point. But no one stays a beginner indefinitely.

Almost no one becomes an expert driver either.

Most of us are competent drivers. Driving skill probably even follows a bell curve distribution, with most drivers being OK, some “bad”, some “good”, and very few experts or beginners. We’ll show in this post how to apply this pattern to software requirements and design.

A look back at the best from this week in the past.

How to Start the Use Case Development Process For Agile Software Development

One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. [Note: feel free to substitute “user story” or “user scenario” here, if it is more germaine to your process - the idea still applies.] To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?

Writing Incomplete Requirements

Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?

Foundation Series: Feature Driven Development (FDD) Explained

Feature driven development (FDD) is one of several agile methodologies for developing software iteratively. Iterative development is the opposite of waterfall development.

A look back at the best from this week in the past.

UML State Charts and Documenting Business Rules

In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rules and RUP. In this article we move the conversation slightly forward – recognizing that we’re slowly entering the ocean of business process management.

Use Case Vs. UML State Chart – Business Rules

What is the better requirements management model for capturing business rules? The use case, or the UML statechart? In this article, we explore how customer orders are submitted and processed, and contrast how use cases and statecharts expose and document business requirements and business rules.

Use Case Vs. Process Flow – Failure Handling

Should you use use cases or process flow diagrams to document business requirements? At some level, they both document the same thing, they just document it differently. The best requirements will come from doing both – but what if you are forced to choose one? What are the tradeoffs between use cases and process flows? In this article we look at the documentation of failure handling.

A look back at the best from this week in the past.

Ten Supercharged Active Listening Skills To Make You More Successfull

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Here are ten active listening skills that will help you, your customers and your team.

Writing Use Cases for Estimation

You write use cases to define the scope of your project. Use cases describe what people are using your product to accomplish. Use cases provide a framework for defining the details of the product. You can estimate your project effort with use cases. But you have to write the use cases at the right level of detail.

Software Usability and Learning Curves

Learning curves have been studied for decades when evaluating manufacturing systems and proposing cost reductions. The Boston Consulting Group did an oft-cited analysis in the 1960’s that describes how people get faster at tasks through repetition. Peter Abilla looked at the application of learning curves to writing software. We look at how they apply to using software.

A look back at the best from this week in the past.

Foundation Series: User Experience Disciplines

UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product – in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. In some circles it is known as human-factors engineering, applied to software design. There are several disciplines within this field, we’ll introduce each of them.

Top Ten Tips for Preventing Innovation

At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer – nothing.

What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.

How To Write Use Case Triggers and Preconditions

Use case writing is key to effective requirements management. Each use case represents a single idea or logically grouped behaviors. When you define a use case, there are several mistakes you can make. Preventing those mistakes is the first order of business. The second order of business is making sure that the use cases in the system work together. This requires an understanding of the context in which the use case happens. To fully understand a use case you have to know what is promised to be true before the use case happens, as well as what causes the use case to happen. These are subtly different.

Project Scheduling – 80% Done, 80% Remaining

Johanna warns us that there is “no such thing as percent complete” when it comes to tracking status on a project. Your managers and customers want to know percent complete – and there is a way to report it. Project planning and scheduling involves walking this fine line.

A look back at the best from this week in the past.

Prioritizing Software Requirements – Kano Take Two

In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post. Thanks very much for the feedback!

Product Life Cycle and the ROI of Agile Development

The product life cycle is a description of the presence or behavior of a product in the marketplace over time. The framework for description is a function of the sales volume of the product versus time. Over time, products are created and introduced, and sales grow, peak and decline. The product life cycle uses phases to describe these different periods in the life of a product. Understanding the product life cycle is also key to calculating the ROI of agile development.

Agile Development and Software Maintenance Costs

Over 90% of the cost of software development is software maintenance (cite). This alarming trend was predicted as early as 1972. McKinsey suggests that CIOs should spend no more than 40-60% on maintenance. Gartner’s IT Spending and Demand Survey (2002) reports that CIOs are spending 80% of their budgets on maintenance (p12 of presentation). Agile development can help reverse this trend.

A look back at the best from this week in the past.

User Centered Design and Bridging the Canyon of Pain

There is such a thing as too much choice. For new users, too much choice (or control) is too much. For experienced users, too little choice is a problem. Ease of use usually comes from reduced control – but users don’t stay “new” for long. There’s a “canyon of pain” to quote Kathy Sierra in that transition from “new” to “experienced.” We call them “competent” users and we have to help them cross the canyon of pain.

Project Dashboard Icons

We create project dashboards all the time to show status, or to give upper management an update. Dashboards and scorecards are great for giving us a “quick view” into the health of a project – they give us a way to drill down. Many of us use the colors red / yellow / green, with a stoplight metaphor. The problem is that some of us are colorblind. Johanna Rothman gives us a GREAT tip. We give you a set of icons / images.

Measuring the Cost of Quality

Should we test our software? Should we test it more?

The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”

We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?

A look back at the best from this week in the past.

Software Requirements: Processes and Roles

Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.

Writing Requirements Unambiguously

stuff

Writing requirements without ambiguity

This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause

Writing Functional Requirements to Support Use Cases

Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.

A look back at the best from this week in the past.

Using ROI For Requirements is a Risky Business

We must allow for risk when calculating ROI

We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.

If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.

The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.

Foundation Series: Intro to Utility Curves

Utility is an abstract concept usually relegated to economics. What is it? How does it work?

Prioritization With ROI and Utility

Prioritization with ROI is generally thought of as a quantitative analysis. For hard and soft ROI, that is true. But benefits can not always be quantified. Economists get around this with the notion of utility. You have to make a prediction of the utility of the requirement or feature. How do you do that?

Five Return on Investment Calculation Tips

Return on investment calculation is critical to using ROI for prioritizing requirements. We’ve discussed how to forecast return on investment by estimating costs and predicting benefits. Here are five tips to help you when calculating return on investment.

A look back at the best from this week in the past.

Describing the Software Development Process

Describing the software development process

Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.

• How do we separate these very different processes so that we can talk about them?
• How do we staff a team to accomplish them?

We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentence defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative life-cycles, or any of many good analogies.

Five Measures of Product Manager Performance

Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a lot of experienced people with strong opinions and steamer trunks full of anecdotal data – and they don’t all agree. You get to see the coin from all three sides* with this group – it’s awesome.

Top Five Ways To Be A Better Listener

Effective listening skills yield great requirements

The better you are at listening, the more people will want to tell you.

If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is reflective listening. A marriage counselor will tell you that step one in solving your problems is to listen. Consulting 101 will reiterate the importance of active listening. Presentation trainers stress good listening skills. Dale Carnegie – listening yet again. Sonar technician. There’s a pattern.

A look back at the best from this week in the past.

CMMI Levels and Requirements Management Maturity Introduction

[Note: This is the first in a series of 6 articles]
CMMI (Capability Maturity Model Integration) is a description of the level of enlightenment of a process. It is essentially a measure of the quality and capability of a process. There are five categories, into one of which every process will fall. IBM took a similar approach to defining the requirements management process. In this series of posts, we will marry the two frameworks.

Differentiate Your Product – Circumvent Comparisons

ook Ma! Me Too! The temptation to compete against a checklist can be overwhelming. When we have a competitor who provides 100 of this or 200 of that, it might seem smart to offer 200 of this and 300 of that. We’ll be better off if we focus instead on creating the other thing. The best way to compete is to valuably differentiate our product, not outdo our competition.

How to Write Good Use Case Names – 7 Tips

The first step in writing the use cases for a project is to define the scope of the project. One way to do that is to list the use case names that define all of the user goals that are in scope. To do that, you need to know how to write good use case names. Good use case names also serve as a great reference and provide context and understanding throughout the life of the project.

A look back at the best from this week in the past.

Marketing Truths – Don’t Tell the Developers

Marketing is as foreign to most software developers as flying is to fish. We’ve found a list of ten truths of marketing, and we’re secretly sharing them with the developers who hang out here. Shhh. Don’t tell anyone in marketing.

Brainstorming – Making Something Out of Everything

Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps).

Seven to ten people is a good number to pull together in a brainstorming session. With creative and vocal people, a smaller number can work.

Top Five Six Requirements Gathering Tips

Interviewing, Brainstorming, Documenting Use Cases, Prototyping, Analyzing Documents, and Business Process Modeling

How to Interview When Gathering Requirements

We previously stressed the importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.

Understanding why is still our goal – but we have to be smart about our interviews to get this information. In our previous post, we identify interviewing as a key technique for eliciting requirements. Interviewing is the cornerstone of our elicitation techniques – even if we gather the bulk of our information in group meetings, we have to follow-up, clarify and validate with individuals. There’s truth behind the old saw that nothing good is designed by committee.

A look back at the best from this week in the past.

Foundation Series: Black Box and White Box Software Testing

These terms get thrown about quite a bit. In a previous post, we referenced Marc Clifton’s advanced unit testing series. If you were already familiar with the domain, his article could immediately build on that background knowledge and extend it.Software testing can be most simply described as “for a given set of inputs into a software application, evaluate a set of outputs.”
Software testing is a cause-and-effect analysis.

Why Requirements Approval Matters and How to Make it Easier

Getting requirements documents approved can be a pain in the butt. Why do we need to do it in the first place? The approval process is more than just reaching concensus or creating a contract. Done correctly, it presents an opportunity to get more inputs from stakeholders.

Usability Sells Software: Word of Mouth Marketing

There are three main models for selling software. You can hire a direct sales force. You can spend a lot on marketing and advertising. You can let your users sell the software for you, a technique commonly known as viral marketing. There’s a catch with viral marketing – users have to like your software.

Code Debt: Neither a Borrower…

Code Debt is the debt we incur when we write sloppy code. We might do this to rush something out the door, with the plan to refactor later. Agile methodologies focus on delivering functionality quickly. They also invoke a mantra of refactoring – “make it better next release.” This can create pressure to “get it done” that overwhelms the objective of “get it done right.” Taking on code debt like this is about as smart as using one credit card to pay off another one.

This week we look at timeless mistakes: usability mistakes, agile mistakes, and project management mistakes.

Crossing the Desert with Bad Project Planning

Johanna Rothman recently wrote an article with a poignant introduction: “A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome.” Fixing it isn’t enough – how do we prevent it from happening?

Ten Common Mistakes of Going Agile

This concludes and summarizes our winter-holiday series on the 10 common mistakes of going agile. The ten mistakes that Levent Gurses identified in the Dec 2006 edition of Dr. Dobb’s journal. Here are links to the ten previous articles, and a summary of the mistakes:

Top Five Usability Blunders (And Fixes)

Five easy steps to alienating your users with bad usability

1. Fail to simplify a comprehensive interface so that new users can quickly climb past the suck threshold.
2. Build an inconsistent UI layout or interaction design that varies throughout the application, creating a sense of dissonance for the users.
3. Interrupt the user’s workflow with pop-ups and other modal interruptions.
4. Limit expert users to following “new user” workflow, one tedius, repetitive step at a time when shortcuts would work.
5. Don’t suggest solutions when an error message is displayed.

Top Five Use Case Blunders

We all make mistakes. When we mess up use cases, it is most likely one of these five things.

Managing Requirements Conversations

In Documents vs. Conversations, on the Pyre blog, Greg Wilson does that thing that we so rarely do – he takes a step back, and thinks from an entirely different perspective about managing requirements. He proposes the idea of managing requirements as conversations, instead of as documents.

Why We Should Invest in Requirements Management

Need to convince someone in your management chain why they should invest in managing requirements? There are some great arguments in this post by sudhakar -

Agile RUP for Product Development : Best Practices of Requirements Collection .

There is a lot more in the post, but the key high level “Why should we invest in managing our software projects?” answers are summarized from several research reports: