Return to Answer

I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worse documented.

Alright, perhaps from a more philosophical point of view, software have requirements from the moment the idea of them is conceived is the mind. But you are not getting to see those. For a practical stand point, there will be projects.

There are people who test and use the software, and submit bug reports (issues). Fixing them becomes the requirement for the project of, well, fixing them. Some time a change is done to address multiple bugs, in essence collecting those issues are requirements for a single project.

Ah, but let us talk about adding features…

It is common that a lead programmer will have a road-map of features to add. Which could be public for everybody, could be shared only among maintainers/core developers, or could be entirety private. The core developers will work towards the what is laid out in road-map.

The issues, in the issue tracker. Be them bug reports or proposals for new features. Those are requests for change. They bring new requirements (or remind of old ones in the case of regressions). To implement those changes, we do projects (with design, and testings, programming, etc). To reiterate, each one of those projects has requirements.

Ah, by the way, some tools can pull TO-DO items from source code comments. Keep an eye for those.

Contributes may come from outsiders. As third parties can fork the repository, modify the source, and then have those modifications incorporated into the official repository (with approval of its maintainers). This process is formalized as pull requests. How did they manage the requirements for those changes? Each developer does it their own way.

And I'll remind you that not every developer is a software engineer. Not everybody needs and is trained for formality in methodology.

I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worst documented.

Alright, perhaps from a more philosophical point of view, software have requirements from the moment the idea of them is conceived in the mind. But you are not getting to see those requirements. For a practical stand point, there will be projects.

There are people who test and use the software, and submit bug reports (issues). Fixing them becomes the requirement for the project of, well, fixing them. Sometimes a change is done to address multiple bugs, in essence collecting those issues as requirements for a single project.

Ah, but let us talk about adding features…

It is common that a lead programmer will have a road-map of features to add. Which could be public for everybody, could be shared only among maintainers/core developers, or could be entirety private. The core developers will work towards the what is laid out in road-map. Thus, the road-map are requirements.

The issues, in the issue tracker - be them bug reports or proposals for new features - are requests for change. They bring new requirements (or remind of old ones in the case of regressions). To implement those changes, we do projects (with design, and testings, programming, etc). To reiterate, each one of those projects has requirements.

Ah, by the way, some tools can pull TO-DO items from source code comments. Keep an eye for those.

Contributions may come from outsiders. As third parties can fork the repository, modify the source, and then have those modifications incorporated into the official repository (with approval of its maintainers). This process is formalized as pull requests. How did they manage the requirements for those changes? Each developer does it their own way.

And I'll remind you that not every developer is a software engineer. Not everybody needs - and is trained for - formality in methodology.

Free and Open Source software has multiple ways to advance. The software is the software (across all its versions and editions), but each change is a project. Each one of those projects has requirements.

Alright, perhaps from a more philosophical point of view, software have requirements from the moment the idea of them is conceived is the mind. But you are not getting to see those. For a practical stand point, there will be projects.

Free and Open Source software has multiple ways to advance. The software is the software (across all its versions and editions), but each change is a project. Each one of those projects has requirements.

Free and Open Source software has multiple ways to advance. The software is the software (across all its versions and editions), but each change is a project.

You will also find the issue system co-opted for feature requests. In fact, the practice of writing proposals for change as issues is becoming widespread. These proposals are usually more detailed than a road-map. You can consider them RFC documents.

I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worse documented.

Free and Open Source software has multiple ways to advance. The software is the software (across all its versions and editions), but each change is a project. Each one of those projects has requirements.

You will also find the issue system co-opted for feature requests. In fact, the practice of writing proposals for change as issues is becoming widespread. These proposals are usually more detailed than a road-map. You can consider them RFC documents.

The issues, in the issue tracker. Be them bug reports or proposals for new features. Those are requests for change. They bring new requirements (or remind of old ones in the case of regressions). To implement those changes, we do projects (with design, and testings, programming, etc). To reiterate, each one of those projects has requirements.