You should also define what software is not
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
— Antoine de Saint-Exupéry
A software project usually starts as a wishlist of things the final product should be able to do. Once released, users (in many cases the user and the developer are one and the same) may suggest additional features that greatly improve upon the software, or simply fit someone’s very specific use case.
Things can spiral out of control, and eventually software will suffer of power creep, piling up features over time.
So, I think it’s good to also define from the start what your software should not do. There are many advantages to this:
- Less work to do, obviously
- Sets expectations for the software’s future users and developers
- Adding non-features is way easier than adding features. I do have to admit that sometimes not adding something is harder than adding it. (See YAGNI)