- Hi All, Thanks a lot for the input. I guess I got the point. Right now its a integration project, hence getting use cases differently-though requirements areMessage 1 of 5 , Sep 24, 2012View SourceHi All,
Thanks a lot for the input. I guess I got the point.
Right now its a integration project, hence getting use cases differently-though requirements are earlier discussed.
I think, the best way to create stories out of this.
Thanks and Regards,
RudraOn Mon, Sep 24, 2012 at 3:25 PM, Steve <steve@...> wrote:
Lets's leave aside the Scrum aspects for now and analyse some basics.
A Use Case (UC) is a UML statement of a requirement. Therefore by having a UC document and a Requeirements Spec, you have 2 statements of requirements; this is probably 'fraught with danger'.
How were these documents created? As far as I can see, there are 3 possibi;ities:
1. Independantly - One team of people created the Requirements Spec to address a problem and another team created the UC doc for the same problem. This could be a way to look at a problem from 2 'angles' to make sure that no requirements are missed; the idea would be to compare the 2 documents and then merge them into one document of a chosen format.
2. Requirements doc first - The UC document was derived from the Requirements doc as the first step to 'traditional' requirements spec to a UML design. Differences in the UC doc should then be put back into the requirements doc so that it is the 'master' requirements doc.
3. UC document first - similar to above which, although it could be done, does not really make any sense!
In general terms, you should only have one 'master' document however you get to it.
Now lets have a look at the Scrum (or any Agile) approach. The Scrum Guide lifecycle starts with a Product Backlog (PB). The suggested functional requirements in the PB are User Stories but they can be the names of Elementary Business Processes or Use Cases.
There is no advice in most of the Agile Frameworks as to how to find these PB Items (PBI). You can use Business Process Modelling, Value Stream Mapping or just Brainstorming; nobody in the Agile community would ever advise the creation of a 'traditional' requirements document as a start.
Are you part of a 'software house' that is building something for a client using Scrum where your client has produced the requirements document? If you are, the fact that your 2 docs do not match is going to be the least of your problems! If, as I suspect, your 'contract' does not include clauses to involve the relevant client personnel on a regular basis, then you are going to have a lot of problems further into the development.
Bottom line :- Have one statement of requirements (UC doc as a PB is suggested) and get someone to look closely at the development process you wish to follow to see if it is actually appropriate for your situation.
Hope that helps