I have scoured the OpenSource-type repositories and have found requirements management software to be completely lacking. Yet I believe that this, in coordination with work-breakdown structures, are what will simplify managing large scale source code developement for things like The GIMP, Linux Kernel, or anything else that has hundreds of people clammering for new features.
I have some ideas which might make this project a reality if you would like to hear them...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To solve this chicken and egg problem, I propose the following (so far) requirements for this project:
1. Requirements Management (RM) will be divided into two parts: stated and derived requirements. State requirements are those explicitly asked for by end users or mandated by project leaders. Derived requirements are not-specifically requested, but deemed necessary as a clarification of the stated requirements.
2. This RM package will have a web-style interface so that geographically separated users can contribute, reject, or discuss the project planning stage.
3. This RM package shall provide a communication module for connection with other packages which may do work breakdowns (for connection back to the requirements).
4. This RM package shall have approved, proposed, and rejected requirements.
5. A discussion on each requirement will be allowed. The discussion groups will allow project managers to have a "whiteboard" conversation about project features.
6. A single project under RM may have multiple versions of its requirements, depending on the version of the project to which they are targetted. Thus, the RM package should keep track of the targetted major release of the project.
7. Reports should be creatable for tasks such as unresolved requirements, dependent requirements, activity reports, etc.
8. Have a light training guide which distinguishes requirements which MUST be met, and SHOULD be met. Guide should also distinguish between requirements decisions vs. design decisions.
#3 was a little vague so let me give examples:
o A workbreakdown structure program to help assign tasking to people who have the skills. Also identifies the skills necessary to make the project come off.
o A source code peruser which looks for references to satisfied requirements (so that developers can tell us exactly where a particular requirement is met, with the resolution being no finer that which file met the requirement). Additionally, if one requirement changes, the project manager can get a list of all files which will need examining for resolving the change.
If you think I'm totally off my rocker or am too anal for this project, let me know. ctodd at lycosmail dot com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is a great idea, too. At my job, we've been looking around for something of this nature. I have some thoughts I'd like to contribute.
In regards to stated and derived requirements, we have defined them by creating two "metarequirements", that is, requirements that requirements must meet.
1. A requirement must have a direct benefit to (or be requested by) the user, or be derived from such a requirement.
2. A requirement must be quantifiable and testable, or have a set of derived requirements that are equivalent and are quantifiable and testable.
So in other words, there may be multiple levels of derivations under each requirement, until you've got enough detail to make it testable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think to have the tie-ins you suggest, you'll need to track both requirements and features.
Features will connect to requirements that they satisfy, and to source code where they are implemented. Features are what get assigned to developers.
Requirements may be dependent on other requirements, and features may be dependent on requirements or other features.
AT&T has a free "graphviz" package, which includes a library called "dot" that does a great job of drawing dependencies as a graph. It automatically does the layout, etc. The package is available at http://www.research.att.com/sw/tools/graphviz/ and I would suggest making use of it to allow users to browse the dependencies between requirements and features. The software has features to make a web-ready imagemap out of the graph.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have scoured the OpenSource-type repositories and have found requirements management software to be completely lacking. Yet I believe that this, in coordination with work-breakdown structures, are what will simplify managing large scale source code developement for things like The GIMP, Linux Kernel, or anything else that has hundreds of people clammering for new features.
I have some ideas which might make this project a reality if you would like to hear them...
To solve this chicken and egg problem, I propose the following (so far) requirements for this project:
1. Requirements Management (RM) will be divided into two parts: stated and derived requirements. State requirements are those explicitly asked for by end users or mandated by project leaders. Derived requirements are not-specifically requested, but deemed necessary as a clarification of the stated requirements.
2. This RM package will have a web-style interface so that geographically separated users can contribute, reject, or discuss the project planning stage.
3. This RM package shall provide a communication module for connection with other packages which may do work breakdowns (for connection back to the requirements).
4. This RM package shall have approved, proposed, and rejected requirements.
5. A discussion on each requirement will be allowed. The discussion groups will allow project managers to have a "whiteboard" conversation about project features.
6. A single project under RM may have multiple versions of its requirements, depending on the version of the project to which they are targetted. Thus, the RM package should keep track of the targetted major release of the project.
7. Reports should be creatable for tasks such as unresolved requirements, dependent requirements, activity reports, etc.
8. Have a light training guide which distinguishes requirements which MUST be met, and SHOULD be met. Guide should also distinguish between requirements decisions vs. design decisions.
#3 was a little vague so let me give examples:
o A workbreakdown structure program to help assign tasking to people who have the skills. Also identifies the skills necessary to make the project come off.
o A source code peruser which looks for references to satisfied requirements (so that developers can tell us exactly where a particular requirement is met, with the resolution being no finer that which file met the requirement). Additionally, if one requirement changes, the project manager can get a list of all files which will need examining for resolving the change.
If you think I'm totally off my rocker or am too anal for this project, let me know. ctodd at lycosmail dot com
I think this is a great idea, too. At my job, we've been looking around for something of this nature. I have some thoughts I'd like to contribute.
In regards to stated and derived requirements, we have defined them by creating two "metarequirements", that is, requirements that requirements must meet.
1. A requirement must have a direct benefit to (or be requested by) the user, or be derived from such a requirement.
2. A requirement must be quantifiable and testable, or have a set of derived requirements that are equivalent and are quantifiable and testable.
So in other words, there may be multiple levels of derivations under each requirement, until you've got enough detail to make it testable.
I think to have the tie-ins you suggest, you'll need to track both requirements and features.
Features will connect to requirements that they satisfy, and to source code where they are implemented. Features are what get assigned to developers.
Requirements may be dependent on other requirements, and features may be dependent on requirements or other features.
AT&T has a free "graphviz" package, which includes a library called "dot" that does a great job of drawing dependencies as a graph. It automatically does the layout, etc. The package is available at http://www.research.att.com/sw/tools/graphviz/ and I would suggest making use of it to allow users to browse the dependencies between requirements and features. The software has features to make a web-ready imagemap out of the graph.
BTW, there is a TCL based interface for the graphviz package, so I might also suggest TCL as an implementation language...