RFC - context
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
Call it RFEC - Request for External Company :-)
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
I think this is what an RFC is (Request for Comments). A Structured RFC Process[^] I would look more at SDD - software design document or SRD - software requirements document for external companies, perhaps. You don't need a request document anymore since you already have a working agreement (I am guessing). Edit: SRSD - software requirements specification document may also be of help: Software Requirements Specification (SRS Document) | Perforce[^]
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
It (and always was?) an RFP: Request For Proposal; in effect, asking someone for a "bid", recommendation, solution, something. "The purpose of this RFP is to solicit ... etc." I wrote an "external RFP" on behalf of a subdivision (due to politics), then due to politics, the project was brought in-house, and my RFP became an "internal" "Response to (my own) RFP". The RTRFP?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
It (and always was?) an RFP: Request For Proposal; in effect, asking someone for a "bid", recommendation, solution, something. "The purpose of this RFP is to solicit ... etc." I wrote an "external RFP" on behalf of a subdivision (due to politics), then due to politics, the project was brought in-house, and my RFP became an "internal" "Response to (my own) RFP". The RTRFP?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
I think they are past the RFP process and now need to provide the external 3rd party with requested software design requirements. That is not contained in the RFP/RFP process, if I am not mistaken.
-
I think they are past the RFP process and now need to provide the external 3rd party with requested software design requirements. That is not contained in the RFP/RFP process, if I am not mistaken.
Then it's just a "User Requirements" document and no need to agonize over a "Request for Something". Just a friendly cover letter. Then they say: "This is not acceptable." Then you go: "Propose something"; i.e. an RFP
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
It probably depends on what stage you are at - and the level of detail you are planning. You could go with: BRD - Business Requirements Document - which would be a fairly high level description of what the business needs/expects. TOR - Terms of Reference - would probably flesh out a bit more, such as scope, risks/contingencies, critical success factors, etc. Specification - which would describe the nuts and bolts of the API content and how it will interact. I guess in these 'Agile' days, the above are all frowned upon. You just need to put: "I want x,y,z" on a post-it note and stick it on a white board! ;)
-
It probably depends on what stage you are at - and the level of detail you are planning. You could go with: BRD - Business Requirements Document - which would be a fairly high level description of what the business needs/expects. TOR - Terms of Reference - would probably flesh out a bit more, such as scope, risks/contingencies, critical success factors, etc. Specification - which would describe the nuts and bolts of the API content and how it will interact. I guess in these 'Agile' days, the above are all frowned upon. You just need to put: "I want x,y,z" on a post-it note and stick it on a white board! ;)
5teveH wrote:
You just need to put: "I want x,y,z" on a post-it note and stick it on a white board!
That is how I am used to it being done now days. :laugh: I used to have to work on SDDs in the past, though. Ugh, not fun.
-
5teveH wrote:
You just need to put: "I want x,y,z" on a post-it note and stick it on a white board!
That is how I am used to it being done now days. :laugh: I used to have to work on SDDs in the past, though. Ugh, not fun.
-
It probably depends on what stage you are at - and the level of detail you are planning. You could go with: BRD - Business Requirements Document - which would be a fairly high level description of what the business needs/expects. TOR - Terms of Reference - would probably flesh out a bit more, such as scope, risks/contingencies, critical success factors, etc. Specification - which would describe the nuts and bolts of the API content and how it will interact. I guess in these 'Agile' days, the above are all frowned upon. You just need to put: "I want x,y,z" on a post-it note and stick it on a white board! ;)
Great. Thanks for the reply, @SteveH.:thumbsup: Quite useful.
5teveH wrote:
I guess in these 'Agile' days, the above are all frowned upon. You just need to put: "I want x,y,z" on a post-it note and stick it on a white board
Precisely, What I did not want to follow. :)
-
It (and always was?) an RFP: Request For Proposal; in effect, asking someone for a "bid", recommendation, solution, something. "The purpose of this RFP is to solicit ... etc." I wrote an "external RFP" on behalf of a subdivision (due to politics), then due to politics, the project was brought in-house, and my RFP became an "internal" "Response to (my own) RFP". The RTRFP?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
It (and always was?) an RFP: Request For Proposal; in effect, asking someone for a "bid", recommendation, solution, something. "The purpose of this RFP is to solicit ... etc." I wrote an "external RFP" on behalf of a subdivision (due to politics), then due to politics, the project was brought in-house, and my RFP became an "internal" "Response to (my own) RFP". The RTRFP?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
Request for solution - Wikipedia[^] Just got the leads. I think this term could be used. Also good to refer: Request for proposal - Wikipedia[^]
-
I think this is what an RFC is (Request for Comments). A Structured RFC Process[^] I would look more at SDD - software design document or SRD - software requirements document for external companies, perhaps. You don't need a request document anymore since you already have a working agreement (I am guessing). Edit: SRSD - software requirements specification document may also be of help: Software Requirements Specification (SRS Document) | Perforce[^]
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
-
Request for solution - Wikipedia[^] Just got the leads. I think this term could be used. Also good to refer: Request for proposal - Wikipedia[^]
At some point, you need to make contact with your "counter-part" in the other organization. What you think "management" wants and what the people that do the actual work need can be 2 different things. There's always some politics / turf disputes; depending on who you cultivate, the road is easy or rocky. I usually start with: "Hi, I've been assigned to ... and I was told that ... and would like your thoughts, etc." Casual-like. Start as a serf; then become the master.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
We are in discussion with a external company for an integration request. The external company's services are built as a closed-ended product with no intention for 3rd party integrations. But now they've agreed to open up the services through APIs. We have reached the understanding at the management level and now I'm supposed to write the requirements. Can I call this as an RFC? I'm just wondering it make sense to call this as an "RFC" when the product is external, belonging to some other company. :~ Don't want them to feel like :omg: Please suggest.
What ever you go for, please be aware to use the long form the very first time you use the acronyms to specify. Or at least don't forget to write down: "if you don't know what RFC is... RTFM" :rolleyes: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.