Software product success.
How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?
Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”
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.
More great stuff from Kathy Sierra at Creating Passionate Users. Kathy contrasts the traditional budget-busting marketing promotion approach (one of the classic 4Ps) with a nickel-and-dime approach to inspiring and educating users and customers. We’ve talked about the importance of persuasion in the new Ps. Kathy’s stuff is right on the money for this one.
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.
…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.
IT Conversations has an interview (mp3 41min) with Alistair Cockburn (pronounced koh-bern) that makes for a great listen. Doug Kaye hosts a great conversation with Alistair, discussing several topics, including the four principles of Agile development. Alistair explains that the wording is precise and intentional, and represents four sets of preferences, not four absolutes.
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:
Continuous Integration is the software development and quality process where all team members merge their code and verifies 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.
Marcus is building a great reference on non-functional requirements at From Start to End. He’s created a series of articles, and keeps adding more. Each post focuses on a single type of non-functional requirement. He just put up an index page for all of his posts, and he’ll be keeping that page updated as he adds more content.