![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Seeking advice: Collaborating on DOORs with Limited Access Topic Summary: Created On: 22-May-2008 16:58 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: As you mentioned a web interface there's always DOORSNET, of course at an added cost. You could alternatively set up either a Citrix server or Terminal server as well to allow the remote user to connect to the DOORS database. The client can be used remotely as well if your on the same WAN. We use all three of these methods. Do the remote members currently use DOORS? If not it just sounds like they me be stubborn and not want to learn a new tool. I guess I would have to ask, "What are their reasons for not wanting to use DOORS?". Remind them what DOORS is for, why your company purchased the product (it ain't cheap you know), and do a cost analysis of doing it both ways. Managers like it when you show them how to save money and manpower, it sounds to me like they want to take a one step process and turn it into a two step process that could ultimately cost the organization more money and time. As far as the review goes, you can add attributes and views specific for the review as well as restrict access to certain attributes. I would agree with you that you should not be the single source of entry for all your DOORS data. | |
![]() |
|
I work on a team that is distributed among 3 remote sites. My requirements are loaded into DOORS 8.1. All requirements have links to their source. We're ready for our first requirements review.
In my opinion the DOORS can be used by all to facilitate the review process. Remote team members disagree. They don't want to use DOORS in any way, shape, or form. They want me to be the single-source-entry for all DOORS related data. Just export to Excel, we'll make changes there, then you can fix them in DOORS they say. If I export to Excel, and allow others to make changes, I will have version control problems, not to mention lots of lost efficiency. I'm highly wary of becoming the 'Keyboard Monkey' rather than Requirements Manager. What's the best way to collectively share review and approve requirements given this situation? Is there a web interface I could be using? Veteran Advise Please! Also, is there a best practice to conduct a requirements review using DOORS? |
|
![]() |
|
![]() |
|
As you mentioned a web interface there's always DOORSNET, of course at an added cost.
You could alternatively set up either a Citrix server or Terminal server as well to allow the remote user to connect to the DOORS database. The client can be used remotely as well if your on the same WAN. We use all three of these methods. Do the remote members currently use DOORS? If not it just sounds like they me be stubborn and not want to learn a new tool. I guess I would have to ask, "What are their reasons for not wanting to use DOORS?". Remind them what DOORS is for, why your company purchased the product (it ain't cheap you know), and do a cost analysis of doing it both ways. Managers like it when you show them how to save money and manpower, it sounds to me like they want to take a one step process and turn it into a two step process that could ultimately cost the organization more money and time. As far as the review goes, you can add attributes and views specific for the review as well as restrict access to certain attributes. I would agree with you that you should not be the single source of entry for all your DOORS data. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|
![]() |
|
![]() |
|
I would like to second everything that Scott has said.
Stick your heels in Tracy and don't let them make you into a DOORS keyboard monkey. ------------------------- Tony Goodman Smart DXL limited www.smartdxl.com |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.