In Software Requirements by Karl Wiegers:
Project teams that build products incrementally by following an agile development process also need to understand the requirements that go into each increment.
What does “increment” and “incrementally” mean here?
1
In this context, “increment” or “iteration” refer to making relatively small changes to a program before rebuilding or redeploying it. One of the core ideas of agile is that you want to aim for frequent, rapid iterations.
In agile you typically want the program to be buildable and shippable at all times. It may not be terribly useful or feature-complete for a while, but you always want it to be a thing you can actually build and ship right away so that people can start testing it and giving feedback (as opposed to the “waterfall” approach where no one can really try it out until the whole thing is finished). Then you add features to it one at a time, though each one may take anywhere from a day to a couple of weeks or maybe even months.
In many places each increment/iteration is the release made at the end of a “sprint”, i.e. a period of 1-2 weeks associated with a short list of tasks the team aims to get done in that time.
3
An “increment” in this context is a small piece of functionality. To build “incrementally” means completing (and potentially releasing) your work in small bits at a time, as opposed to one large release. “Iteration” refers to the (small) cycles of work that you go through to be able to release incrementally. They are related, but not interchangeable, terms.
I have not read this title, but usually when someone says build software incrementally they’re referring to delivering more and more functionality in iterations. There are different approaches to this, but a lot of them mean starting by developing a minimum set of features/functionality, delivering this to the customer, and responding to feedback/refining the deliverable/adding more functionality. Repeat until project competition.
The idea with this type of approach is that you’re doing small bursts of work and then reevaluating to make sure you’re still moving in the best direction. This allows development teams to respond to changes better.
1
Here’s discussion on SO.
I like the idea of incrementally building something (adding parts), in an iterative way (building each part in a feedback loop).