I'm wondering if anybody has an example of our knows where I can find an example of a document that serves to bridge the gap between the requirements and the tech specs.
What I mean is, the requirements doc outlines all of the business requirements for a particular system. For whatever reason, you may only be able to meet 3 of 4 requirements. This document would outline the 3 requirements that are being delivered and is what would be provided to the development team to build their tech spec.
I've heard it referred to before as the requirements specification document, but all searches I have done on the internet point me towards business requirement docs.
We would like to implement such a document into our framework to help manage the expectations of the BPOs - we have found that it is assumed that whatever is in the requirements document is being delivered, but that may not always be the case.
In some instances a phased approach may be required, or b/c of current technological limitations a requirement cannot be implements, or because of lack of funding. You don't want to lose those requirements, because afterall they are business requirements and are still wanted by the users and perhaps at some point in the fure can be implemented. You wouldn't need to redo the business requirements doc because that hasn't changed...all that would need to be done is to create a new 'X' doc for the remaining requirements and have the developers go from there.
Any help would be greatly appreciated...thanks!
Hi,
I've encountered the same problem but did not want to maintain different document sets. Instead, I recorded the requirements in an Excel spreadsheet and then used different tabs according to what was being delivered. To begin with, all the requirements were documented in one tab. Then, once we had agreed what was being delivered in phase one I moved those particular requirements to a new tab. I reviewed this tab with my stakeholders and it meant that the business were absolutely clear which requirements were being delivered in phase 1 (and which weren't) and the technical team had a defined list to work from. Also, nothing was lost or deleted. Once funding was secured for phase 2 I worked with the stakeholders to review the original tab with the remaining requirements and prioritised the next set and put them in a tab of their own (titled 'Phase 2'). My motivation at the time was not to lose requirements after a series of successful workshops. I was under a lot of pressure from the technical lead to delete all the requirements that weren't being delivered in phase 1! Thankfully I didn't follow his lead and when funding was secured for phase 2 we had requirements ready to go and didn't have re-do requirements gathering.
I think it's really worthwhile keeping everything in one place as it cuts down your maintenance/admin time and means that people aren't confused as to which document to consult. As an aside, I also like Excel as you can add columns for traceability and further help bridge the gap between business and IT. But more on that another time if anyone's interested.
Good luck and best wishes.
The Software Requirement Specification (SRS) is meant to delineate the features of to-be-delivered System so as to serve as a guide to the developers on one hand and a software validation document for customer side on the other. that means it should be done before starting Software Development Stage and after putting the project scope to clarify the scope. SRS consists of a list of Use-Cases clarified by user interface prototype. Finally I think it is not designed to cover the gap between what is done and what should be. after completing the development and during QA the system will be compared to SRS and the output should be a table of defirences
i think the thing you guys are looking for is a traceability matrix. Excel will do, and there are even better tools if you pick up a software requirements tool. But again, excel will usually be sufficient. You are basically creating a map from business goals, through requirements, to features and then benefits.
brought to you by enabling practitioners & organizations to achieve their goals using: