Methodology to develop SDD requirements

[Thomas Studwell <studwell@us.ibm.com>]

Thomas,
besides getting agreement on the SDD face to face location and date, there were two things I wanted to accomplish in the last SDD TC telecon. First and foremost, I wanted to get input and general agreement on the methodology to arrive at the formal requirements for SDD specifications, additionally, I wanted to get agreement to use the spreadsheet that Debra had prepared since this was a very complete collection of the discussions to date. I had this last item on the agenda before the discussion re methodology because I thought this would be an easy item to get out of the way and we would be able to spend the rest of the discussion on methodology.

Unfortunately, I got off the track in our discussion WRT requirements vs use cases and, as a result, we didn't have a very organized discussion WRT methodology. For this, I apologize to the TC.

For the record, let me say that I, and I think all of the TC, want to expeditiously reach a set of formal requirements so that the process of creating the SDD specification(s) may begin. Let me also say that I recognize that there are going to be a variety of means by which we will arrive at the individual requirements and I do NOT want to discourage any of these means if they help us reach our goal.

Given that, I want to repeat my invitation to you and others that if you have a set of requirements (however derived) that apply to the SDD we more than welcome their contribution to the TC. We can do this informally by sending the set to the TC email distribution or we can do this more formally if you want to request time on the agenda to make one or more presentations to the TC.

Re Methodology: The conversation in the last mtg made me realize something that Randy had mentioned a while ago and it relates to the orthogonal nature of requirements and use cases and might have been your main point of concern on Wednesday night's call. I think one way to address this is to expand the existing spreadsheet, adding at least one more sheet that organizes potential SDD requirements. Whether these are derived from use cases or any other means, having the spreadsheet to organize these will be useful as we compare the requirements to the use cases and the charter. In practice, we can have the SDD requirements column in the use case sheet and simply reference the requirements items from the requirements sheet for each use case. In other words, each use case will have one or more requirements referenced in that column and use cases without requirements referenced will either be out of scope of the SDD or we don't have a complete set ot requirements and we'll iterate to closure. I don't know exactly how we tie the Charter and the requirements together but, as in all of these cases, I'm open to suggestions and improvements.

We need to agree on methodology so we can begin - it doesn't have to be perfect, we can fine tune as we proceed but we need to begin the process of defining requirements so that our face to face meeting is productive and successful. If anyone has a suggestion for this process, please speak up.

Thomas W. Studwell
Senior Technical Staff Member, Autonomic Computing Architecture
IBM Software Group
B140/Bldg 500
4205 S Miami Blvd, Durham, NC 27703
(919) 254-7574 Fax: (919) 254-7628 Mobile: (919) 619-1038
studwell@us.ibm.com

"Things should be made as simple as possible, but not any simpler."
Albert Einstein (1879-1955)