I will add assigning a level of risk and the ability to at least point to a soft copy document with requirements info with the possiblity that this feature could expand as links to version control tools are also thought to be important at some point.
The linking to a project management tool I also believe is very important but I doubt that will make a first version cut.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is probably a V2 feature, but the ability to link, relate to, or mange change requests within the RM environment would be a really useful additon for products that undergo regular maintenance and feature enhancements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had been thinking of the issues tracking addressing change request tracking. I have usually viewed this as almost another form of 'bug report' that is really and enhancement / change request. I really see three possible outcomes from an issue:
1. If the issue is big enough it would likely spawn new requirements that need to be traced back to the issue.
2. If it is really just a problem or a clarification / refinement to an existing requirement it would simply be tracked and would not be very likely to spawn new requirments.
3. The issues could be dismissed as something that is not going to be done in which case it would just be closed but a record of what was requested and why it was closed would remain.
Thought?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(1) is usually a case of incomplete requirements. Say a request comes in, "let's do keyboard shortcuts". That would be linked to a high level usability requirement, but create a bunch of mid- and low-level requirements.
(1) could also be a case of reversing an earlier decision: "We're not going to do a Linux version of this, we'll just make it run on Windows". Presumably the request relates to some high level requirements, such as business positioning, etc.
(2) seems like a case of ambiguous or unclear requirements.
(3) This really could be two outcomes: temporary or permanent deferral of the request. Permanent says "this conflicts with other requirements and will not be done." Temporary says, "this is a good idea, but we'll address it later."
What do you think?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cann't disagree with you on the root causes you mentioned. I think that the whole area of change management will need some further exploration for a V2 version of the tool. Especially in the area of analyzing what is really driving the change requests -- 'fixes' to the original requirements (misse requirments, clarification, etc) or are they truly new requirements that are adding value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that a bug report / enhancement / change request could generate one or more new requirements, as well as result in clarification to existing requirements. I have seen situations where the original requirements were so thin that the interpretation of the requirement resulted in new requirements and clarifications to existing requirements. Therefore I think that the software should cater for this situation.
I agree that if a request is knocked back for some reason, a record should be kept along with the reason it was rejected. If the software ever gets to the point of being able to generate documents from the requirements repository, it may be useful to have the ability to create a document that only contains requirements that have been rejected and the reasons for the rejection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that a bug report / enhancement / change request could generate one or more new requirements, as well as result in clarification to existing requirements. I have seen situations where the original requirements were so thin that the interpretation of the requirement resulted in new requirements and clarifications to existing requirements. Therefore I think that the software should cater for this situation.
I agree that if a request is knocked back for some reason, a record should be kept along with the reason it was rejected. If the software ever gets to the point of being able to generate documents from the requirements repository, it may be useful to have the ability to create a document that only contains requirements that have been rejected and the reasons for the rejection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This thread is to capture any discussion on a 'version 1' for Requirements Manager.
1.Ability to define a project / application / system.
2.Ability to input requirements one at a time.
3.Ability to link related requirements.
4.Ability to enter use cases.
5.Ability to link requirements to use cases.
6.Ability to group use cases into deliverables.
7.Ability to track issues from requirements through development (PVCS tracker like?).
8.Ability to enter test cases.
9.Ability to link test cases to requirements / use cases.
10.Prioritization / voting module (possibly 'on the bubble' for v1).
11.Simple project planning capabilities (possibly 'on the bubble' for v1).
12.Links to VCS packages like PVCS, VSS, and CVS (unlikely for v1).
13.Security to who has access to a given project.
14.Ability to maintain users if using the default requirements manager security manager.
15.On-line discussion group capabilities for any object (requirement, use case, test case, object model, etc) in the database.
16.Ability to create user configurable fields for any object in the database.
17.Full text search capabilities.
18.Ability to create and use a 'shared library' of use cases / requirements (possibly 'on the bubble' for v1).
1.Ability to run over a web browser
2.Ability to run as a standard desktop application (possibly Java Web Start enabled).
3.Ability to enter formatted text
4.Ability to render reports in HTML, PDF, or RTF.
5.End user ability to define report layouts (maybe using XSLT?)
1.Written in Java.
2.Optional support of EJBs (ie. An EJB container will not be required but if available can be used for deployment).
3.Ability to support multiple projects within a single instance (database / web server / EJB container?) of the application.
4.Ability to run in a 'stand alone' mode. In other words, without a server using a simple desktop database for storage.
5.Support any JDBC compliant database (including the JDBC / ODBC bridge to use MS Access as a datastore).
6.Pluggable security architecture. Support simple custom security or LDAP based security. Possibly using JAAS architecture.
Can't argue with what you've got so far, however I think the following should be included as well.
1. The ability to assign the level of risk to a requirement
2. The ability to link to project manaement tools
3. The ability to highlight requirements in a soft copy document
These items may not need to be in the first release but I think that they are important
I will add assigning a level of risk and the ability to at least point to a soft copy document with requirements info with the possiblity that this feature could expand as links to version control tools are also thought to be important at some point.
The linking to a project management tool I also believe is very important but I doubt that will make a first version cut.
This is probably a V2 feature, but the ability to link, relate to, or mange change requests within the RM environment would be a really useful additon for products that undergo regular maintenance and feature enhancements.
I had been thinking of the issues tracking addressing change request tracking. I have usually viewed this as almost another form of 'bug report' that is really and enhancement / change request. I really see three possible outcomes from an issue:
1. If the issue is big enough it would likely spawn new requirements that need to be traced back to the issue.
2. If it is really just a problem or a clarification / refinement to an existing requirement it would simply be tracked and would not be very likely to spawn new requirments.
3. The issues could be dismissed as something that is not going to be done in which case it would just be closed but a record of what was requested and why it was closed would remain.
Thought?
Looking at the *causes* of the change requests:
(1) is usually a case of incomplete requirements. Say a request comes in, "let's do keyboard shortcuts". That would be linked to a high level usability requirement, but create a bunch of mid- and low-level requirements.
(1) could also be a case of reversing an earlier decision: "We're not going to do a Linux version of this, we'll just make it run on Windows". Presumably the request relates to some high level requirements, such as business positioning, etc.
(2) seems like a case of ambiguous or unclear requirements.
(3) This really could be two outcomes: temporary or permanent deferral of the request. Permanent says "this conflicts with other requirements and will not be done." Temporary says, "this is a good idea, but we'll address it later."
What do you think?
I cann't disagree with you on the root causes you mentioned. I think that the whole area of change management will need some further exploration for a V2 version of the tool. Especially in the area of analyzing what is really driving the change requests -- 'fixes' to the original requirements (misse requirments, clarification, etc) or are they truly new requirements that are adding value.
I think that a bug report / enhancement / change request could generate one or more new requirements, as well as result in clarification to existing requirements. I have seen situations where the original requirements were so thin that the interpretation of the requirement resulted in new requirements and clarifications to existing requirements. Therefore I think that the software should cater for this situation.
I agree that if a request is knocked back for some reason, a record should be kept along with the reason it was rejected. If the software ever gets to the point of being able to generate documents from the requirements repository, it may be useful to have the ability to create a document that only contains requirements that have been rejected and the reasons for the rejection.
I think that a bug report / enhancement / change request could generate one or more new requirements, as well as result in clarification to existing requirements. I have seen situations where the original requirements were so thin that the interpretation of the requirement resulted in new requirements and clarifications to existing requirements. Therefore I think that the software should cater for this situation.
I agree that if a request is knocked back for some reason, a record should be kept along with the reason it was rejected. If the software ever gets to the point of being able to generate documents from the requirements repository, it may be useful to have the ability to create a document that only contains requirements that have been rejected and the reasons for the rejection.