Unless I misunderstand what a Feature would be, Steve Palmer's book indicates that a Feature can only belong to one FeatureSet and yet we are finding that Features could be resused in several FeatureSets. An example would be in a FeatureSet of ing a we would reuse the Feature of the for the which would use the same objects that were used within the Management Major FeatureSet.
Feature--FeatureSet
User login
Random image
Syndicate
That is correct
A feature only belongs in one business activity. What you are seeing is correct, i.e. Features will be reused in several business activities. It is more accurate to say though that features will be reused by other features and those other features may be from a different business activity. You should be seeing a lot of features that are called (resused) by other features.
It's a judgement call then, when developing the features list (FBS), in which business activity to place a feature that is clearly reused. It's hard to help you more on this point as your message is missing your examples, so I am not sure as to which aspect of this has you confused.
Jeff
Restating the example without < and > symbols
Unless I misunderstand what a Feature would be, Steve Palmer's book indicates that a Feature can only belong to one FeatureSet and yet we are finding that Features could be reused in several FeatureSets. An example would be in a FeatureSet of (pay)ing a (claim) we would reuse the Feature of (select) the (employee) of the (employer) which would use the same objects that were used within the (employer) Management Major FeatureSet.
Hope this helps
A feature is in only one Business Activity
Thanks for resubmitting. My previous reply still applies. What you are seeing is correct. It is a judgement call as to which business activity (feature set) you will place the select the employee of the employer feature, and you know you've done this when you identify that feature as a step in some other business activity.
You do not list the feature twice.
The only thing I'm slightly confused/concerned about is your mention of the same objects that were used in a subject area (major feature set). The classes involved have no bearing whatsoever on the feature list construction. A class could easily have methods on it that are features from multiple different parts of the features list.
Jeff
Further explanation of our Subject Area
Here is a closer look into our real world scenario... A Subject Area would be defined to manage all Party objects [Person|Organization] and would include Employers and Employees. This Subject Area would be entitled <Customer> Management. Then a Business Process within that area would be <Adding> <Employees> to their Employer. The Employee class (and its associated methods) would/could be used in another set of features. Without specifically listing the Feature in the new Business Process, the Feature Team could not set the order of Features to be constructed (or reused) for completing the Business Process. I would probably have any reused Features marked as completed immediatetly if they were completed and available for reuse. If a Feature is still being constructed and a candidate for reuse in other Feature Sets, then I would delay the Feature Set from going into the coding phase until all reuse Features area ready.
The dependencies are known
Hi tadds,
a subject area for parties called Customer Management is a very common shape. You've got roles such as Employer and Employee in there and that sounds good. You have a Business Activity (you said business process but I think you mean Business Activity a.k.a. Feature Set) called Adding Employees to their Employer. Or, did you mean a feature called Add an Employee to their Employer? In any case, you've done some features in this area and they've created an Employee class and some methods on it.
This class, and its methods, will clearly be used (called) by other parts of the system. That is, by other features in other Business Activities. I'm guessing a little here but your first message talked about a claim and that made me think insurance right away and since employers and employees are key parties then we're probably talking about a domain such as WorkCover (in Australia that's the insurance for workers that companies must provide).
The dependency between a feature in one Business Activity and feature in another Business Activity is known to your CP s (and to the PM). It does not need to be (and should not be) made explicit in the features list. You certainly don't want to duplicate the feature as that will compromise your tracking and reporting (it's worse actually - the entire list would be compromised - it would be confusing and unclear) and you would have to synchronise the progress and completion of a feature in all the places it is duplicated in the features list.
The nature of the workflow is that features are assigned to CPs who then pick and choose from the features assigned to them which ones to put into a workpackage and thus schedule for design and build. A whole Business Activity is unlikely to stall because of one feature in another Business Activity (it is possible though) and a PM wouldn't necessarily defer assigning features 5-10 (for example) from a Business Activity just because features 1-4 in it are dependent on another feature in another BA that is not currently completed.
Here are a few links to some discussions on this site that overlap the area you are discussing. Have a read of them and then come back to me if you have any more questions. Note a few of these threads are long and start out on a seemingly unrelated topic.
Here and here and here and here.
Jeff
OK hopefully a final clarification
Jeff,
I had read through each thread and with the term Work Package, I am wondering if I no longer understand how to define a Feature in the context of a Business Activity. We have been asking the domain experts, "What activities do you perform to get the job done?" which we have been capturing as Business Activities within a Subject Area. We then ask them "Now what steps are taken to complete the activity?". They have been listing steps which were defined before and this is where my confusion is. My approach to gathering the Features list may be all wrong.
To illustrate, I offer the following Business Activity and associated Features for your review and comment.
The term Work Package
I've answered the work package part of your question where you asked it over here. Since the threads are now related, let's keep the discussion in this thread.
Jeff
Developing the Feature List
Hi tadds,
these are great questions and I hope that step-by-step this thread is clearing things up for you.
Let me reply generally first and assuming an FDD project.
It is the informational/analytical aspects of the Develop an Overall Model process plus the extensive knowledge transfer that takes place in that process that allows for an accurate Features List to be developed. Generally, it is not the domain experts that construct the features list, it is the CP s. They will interact with domain experts where necessaary, but generally, this is a CP activity. Thus, we're not asking the domain experts questions like "what activities do you perform to get the job done" and then asking them "now what steps are taken to complete the activity." What I mean is, we're not asking domain experts those questions in the Develop Features List process.
We get the knowledge to do this ourselves from the Develop an Overall Model process - where the domain experts are asked to break up the domain into a series of 20 minute or so topics and give us a domain walkthrough of that topic. It is in these walktrhoughs and the subsequent team modeling that we are asking questions such as "what steps do you do" and so on.
By the time we get to Develop Features List we have completely modeled the domain and in doing so, we have most or all the knowledge necessary to develop the features list.
Now, having said all that, let's look at the features you posted. Again, there's no context so I have to speculate a bit and ask some questions.
It isn't clear if these are PD features or UI features. I would speculate that they're a bit of both. That could easily happen if you constructed the features list as you described - by directly asking domain experts and listing the steps. Note also, that they can think in terms of interactions with a computer system (which is what this looks like). That is something to be wary of and look out for (as it is a poor abstraction of the domain).
List the diary entries for a claim is good. List methods are common in the PD for the use of the UI. List the task types for a diary entry is good for the same reason.
Since this sounds like a UI-system interaction sequence - how did they select the diary entry to list the task types for?
Anyway, now we have Select the task type for a diary entry. I presume there's some sort of dropdown list box or other sort of UI selection widget that is used to select a task type from the list of task types.
I'm going to focus on PD features. So, I would ask what (if any) impact on the PD selecting a task type from a list of task types in the UI would have? You have already correctly identified that to support this in the UI the PD must have a list feature - List the task types for a diary entry.
But is there anything else. i.e. to produce the list is there any other kind of computation that must be done? e.g. is the list of task types a flat list across the entire app or is it intelligently filtered based on the diary entry and claim? If so there might be other features to support this - or it is in the implementation of List for task types for a diary entry.
Then, what does the act of selection actually do? At the very least I presume you will set the task type for this diary entry but it might involve other behaviours. e.g. setting the task type hooks us up to a task type from a task catalog and that might then preselect some other behaviours or classes for us.
This would be the kind of breakdown I'd expect to see at the level of fine-grained features. You are identifying (primarily decomposing - but it is the end not the means that is important) all the steps that will be required for the system to support the requirements and the scope for the domain.
All of this is done in the context of the model from Develop an Overall Model. You are looking at the model and then using the knowledge from the domain walkthroughs to identify all the different behaviours and interactions that will be required in the model to support the requirements and the scope. But you're doing this from the point of view of the domain (within the constraints of the scope and the requirements) - which is to say that it is the breakdown of the domain into features that is driving our traversing and populating of the model with behaviours.
You're looking at the model and you're using your knowledge gained from the Develop an Overall Model process and you're thinking of the breakdown of the domain by the topics from the Develop an Overall Model process. And you are asking yourself questions like the ones you are asking your domain experts in your message. "What steps are done to complete this activity?" "Well, first they need to see all the diary entries for a claim. Ok, looking at the model - what do we need? Well, I can see that Claim has a link to DiaryEntry. So, I need a ListDiaryEntries method on Claim and since this is a direct association and there was nothing special about that in the domain that's all I need (i.e. the implementation of that one method will do it all)." You've identified a PD feature and also a method on a PD class.
And on it goes. I could ask questions like this of your remaining features. How do I get to select a Provider of a Claimants Event? Is there a list of Providers I select from and is there a list of Events or are these pre-filtered by selecting the task type previously or...? (all rhetorical). The answers will determine the features needed.
As you are doing this, Business Activity by Business Activity, you will see a place where a feature is needed that already exists in the list. (e.g.) "Ok, here we need to list the task types for a diary entry. We already have that feature over in Document the Claim Activity, so moving on then - what is the next step?"
Looking back at this though, you may certainly choose to move a block of features from one BA to another because it makes more sense to you that way either for reporting or the development sequence or both. That is fine and normal. As long as you don't duplicate them!
Jeff
Workshop Info Request
Jeff,
I think a workshop would be in order at this point for our team. I am having difficulty training others on FDD at the same time I am trying to train myself. I attended the lectures at SD East this past fall and that is what got be hooked. Now I am like moses coming down from mount Boston and the folks in the valley of Waterfall are hard of hearing.
Having said that, what would I need to know to approach management to fund a workshop. What is the cost, how long, and where would it be located?
Thanks for letting me bend your electronic ear.
Tadd
On-demand at your site
Hi Tadd,
nice to know you were in Boston. That was a fun event.
We run private workshops on-demand (subject to availability) at your location or a location of your choosing.
You can find out a bit more here (How to Design and Deliver Better Software is the one you want) but lets discuss offline. I don't want salesy stuff on this site. Contact us through the Nebulon pages or you can e-mail me as firstname.lastname@nebulon.com (no spaces in the name).
Jeff