A look back at the best from this week in the past.
Agile / Business Analysis / Prioritization / Product Management / Project Management / Requirements / Requirements gathering / Requirements Models / Software development / Use Cases
Posted on:
How To Start The Use Case 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. 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?
Agile / Process Improvement / Requirements gathering / Software development
Posted on:
Agile Argument
Another challenge to a premise of agile comes in a well assembled argument from Tony at Seilevel, in his article, Agile…again.
Communication / Product Management / Requirements / Requirements Models / Software requirements specification / Use Cases
Posted on:
Communicating Intent With Implementers
Giving a functional spec to developers and testers is not sufficient for creating great software. To a developer, a spec is only the what and not the why. And for a tester, the software requirements specification is neither. Use cases provide the why that explains the intent of the system for the implementation team.
Agile / Foundation series / Process Improvement / Software development / Test Automation / Testing
Posted on:
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.
Process Improvement / Software development / Test Automation / Testing
Posted on:
Learn to Fly with Software Process Automation
We can reach the next step in our software process evolution by automating much of our process. Flying squirrels evolved a technique* to quickly move from one tree to another without all the tedious climbing and dangerous running. Software teams that automate their processes achieve similar benefits. Automation allows us to increase efficiency while improving quality. And we spend less time on tedious and mundane tasks.
Consulting / Outsourcing / Product Management / Software development
Posted on:
Four Application Development Outsourcing Models
On March 30th CIO magazine published an article titled Do’s and Don’ts of Outsourcing Benchmarks. The article spurred us to write about outsourcing models for product development – it is otherwise unrelated, but interesting. [2015 Edit: The CIO article has been removed, check out these lessons from successes and failures […]
Communication / Process Improvement / Requirements / Software development / Software requirements specification / Testing
Posted on:
Passing the Wrong Whitebox Tests
We’ve talked about the value of using whitebox testing in our Software testing series post on whitebox testing. What we haven’t explored is how to make sure we are creating the right tests. We have to validate our tests against the requirements. This post shows where the flaw is in the typical whitebox testing process, and how to fix it.
A reader emailed us with the comment, “It’s been my experience that developers can’t test their own code.” Their problem was that they were missing a link in the software development chain (missing a step in the process).
Agile / Design / Interaction design / Outsourcing / Requirements / Software development / UX
Posted on:
Software design and specification and making movies
Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design, but it holds true for requirements as well.