Re: [Ldsoss] Scout Tracking - getting back on the trail
I've been reading this thread with some interest to see where it's going. Right now, it appears that the discussion is being dragged down a series of familiar self-inflicted rat holes. What would be most helpful to getting something productive, Tom, and others from HQ, is to offer, at a minimum, a rough design spec and/or set of sys req, to set the stage. If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. ...Paul Bryan Murdock wrote: On 6/7/06, Tom Welch [EMAIL PROTECTED] wrote: OK, so that would have to be a requirement of this software as well. Opt-out of being listed. Opt-out of having what listed for whom? We are still a long way off of even answering those questions. Others have given great responses to these premature security concerns, so I'll just say, amen, to them and leave it at that. Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
We're in violent agreement! I do several iterations on a Use-Case, adding detail and information as I drill down. What you are calling a Business Process, I'd capture on the second iteration of use-cases as a business level use-case. See Writing Effective Use Cases by Alistar Cockburn. He recommends 5 abstraction levels for use-cases. The steps of a high level use-case become full-blown use-cases themselves, but at a lower level of abstraction. The alternative paths through a use-case constitute use-case scenarios. In a simple domain like this, I'd keep the business rules in the use-case just to reduce the number of documents to manage. Then, you define wire-frames or page mockup to capture the essence of the user-interaction. Based on the business-level use-cases you create a Screen-Flow showing the navigation path between the diagrams. Now you instantiate the use-case scenarios with specific data values and you end up with test-cases that you can validate before you even touch design. Make sure that you have a test-case that validates every business rule. The combination of these test-cases constitute an acceptance test. Before you even consider technology, you have defined the success criteria and there are no surprises to either the customer or the developer. Paul Penrod wrote: Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
