[IGSTK-Developers] FW: Requirements

Kevin Cleary cleary at georgetown.edu
Sat Jun 11 06:41:06 EDT 2005


Hi everyone:

There was some discussion about requirements between David, Kevin Gary, and
Brian. I am sure this will be discussed on the tcon next week but I wanted
to send it to the mailing list so everyone can see the discussion thread
below. I don't know if Will is on the mailing list so I added him here. As
Will mentioned during the six month review, requirements are absolutely
critical and I am happy to see us getting back to the discussion.

So please stay tuned and feel free to send any comments on the process below
to the mailing list. Have a good weekend everyone!

Kevin C.

  
------------------------------------------------------------------
Kevin Cleary, Ph.D.                        Work phone: 202-687-8253
Associate Professor                        Work fax: 202-784-3479
Deputy Director  
                            
Imaging Science and Information Systems (ISIS) Center
Department of Radiology                    Pager: 202-901-2033
Georgetown University Medical Center       Cell phone: 202-294-3409
2115 Wisconsin Avenue, Suite 603           Home phone: 301-299-0788
Washington, DC, 20007                      Home fax: 301-299-0789
 
ISIS center: www.isis.georgetown.edu
Research group: www.caimr.georgetown.edu
WashCAS: www.washcas.org
Email: cleary at georgetown.edu
-------------------------------------------------------------------

-----Original Message-----
From: M. Brian Blake [mailto:mb7 at georgetown.edu] 
Sent: Saturday, June 11, 2005 2:45 AM
To: Kevin Gary
Cc: David Gobbi; Kevin Cleary; Brian Blake; 'Luis Ibanez'
Subject: Re: Requirements

Kevin is absolutely right.  Prior to 2005 we made concerted efforts to try
"top-down" requirements generation with requirements that look and read like
requirements.  Early in 2005, perhaps prior to you joining David, we started
looking into requirements with more "application" details (i.e. scenarios of
real interventions).  

In the latest iteratons, credit to the team, we have moved back to "real"
requirements.  It is at this point, that, at times, it is difficult to know
exactly which of the requirements were satisfied in code. So this is where
the disconnect is between the WIKI and the bug tracker. I think your
suggestions make sense with regards to keeping us (i.e. me) diligent in
keeping the requirement satisfaction discussion open and the requirements
maintenance process active.

By thursday, I will put some time into evaluating all our requirements
mechanisms and suggest a proposal to refactor and re-sync everything.

Thanks for the comments David!

-Brian

M. Brian Blake, Ph.D
Assistant Professor
Georgetown University
Washington, DC 20057
mb7 at georgetown.edu
http://www.cs.georgetown.edu/~blakeb/

----- Original Message -----
From: Kevin Gary <kgary at asu.edu>
Date: Saturday, June 11, 2005 2:24 am
Subject: Re: Requirements

> David,
> 
> These make sense to me. I will try to remember to add them to the 
> agenda for
> next week's tcon. I put some short comments inline below.
> 
> Thanks,
> K2
> 
> 
> David Gobbi wrote:
> 
> > Hi Everyone,
> >
> > I took a good look at the requirements listed in the bugtracker, 
> and 
> > tried to reconcile
> > them with the Iteration 4 requirements listed on the wiki:
> > http://public.kitware.com/IGSTKWIKI/index.php/R2_I4_REQ
> >
> > None of those Iteration 4 requirements are listed in the bug 
> tracker.  
> > In fact, no
> > requirements were added to the bug tracker after November 2004, 
> > excepting the one
> > recent "PrintSelf" requirement.
> >
> > The Iteration 3 requirements look alot better.  When I read 
> through 
> > them, I can see
> > correspondence with the bug tracker requirements, though the 
> > correspondence is
> > still not as explicit as it could be.
> >
> > We need a way to link the bug tracker requirements to the ones 
> on the 
> > wiki, and vice
> > versa.  So I propose that from now on:
> > 1) When a requirement is added to the bug tracker, an iteration 
> number 
> > should be
> >    listed in its description so that we know during what 
> iteration we 
> > decided on the requirement.
> >    Right now Brian lists the date, but the iteration number is 
> more 
> > informative (the date can stay too).
> 
> 
> My only fear here is that often we create requirements for an 
> iteration 
> only to find that someone
> can't get to it in time and we defer it to the next iteration. 
> However, 
> since the requirement
> should only be going into the bug tracker when we are 
> transitioning from 
> the Wiki to the
> stable set of requirements, then perhaps this will work.
> 
> >
> > 2) At the same time that the requirement is added to the bug 
> tracker, 
> > the requirement number
> >    from the bug tracker should be inserted onto the wiki  page 
> next to 
> > the appropriate requirement.
> >    That way, we will know which requirements have made it into 
> the bug 
> > tracker and which
> >    haven't just by glancing at the wiki page.
> 
> 
> Actually the way we discussed this originally we really should be 
> doing 
> it already.
> 
> > 3) When a requirement is satisfied, the person who satisfies the 
> > requirement should add a comment
> >    on the bug tracker (a cut and paste from their cvs commit 
> comment) 
> > and mark the requirement
> >    as "closed".  Right now, there is no record saying which 
> > requirements are satisfied and which
> >    arent't.  Also, on the wiki page the developer should add a 
> (done) 
> > in parentheses next to the
> >    requirement.
> 
> 
> Again, you are correct and we should be doing this already with 
> each 
> iteration.
> 
> >
> > All of this isn't much extra work, and I think that it will help 
> the 
> > process move forward much
> > more smoothly.
> >
> > - David
> >
> 
> I think we have a process in place that is pretty agreeable to 
> what you 
> are suggesting.
> You are maybe starting to realize, between the requirements, code 
> coverage, and
> cvs processes that we have not been nearly as diligent as we 
> should be 
> in adhering to
> the lightweight processes we have.  I am hopeful with the new 
> participation from you,
> Rick, Hee Su, and Kevin's upcoming hire, that this is an 
> opportunity to 
> remedy this
> situation.
> 
> We can discuss with everyone Thursday.
> 
> Thanks,
> K2
> 
> 
> -- 
> ===
> Kevin A. Gary, Ph.D.
> Assistant Professor
> DCST, ASU East       
> (480)727-1373
> http://kgary2.east.asu.edu
> kgary at asu.edu
> 
> 







More information about the IGSTK-Developers mailing list