How to design Work Items Effectively

Topics: CAB & Smart Client Software Factory
Mar 24, 2006 at 2:46 AM
originally posted by: Debugger_11

Hii All,

I reqire some tips to design Work Items. I am buiding a having 5-6 users and having lots of Use cases. if i build workitems acc to the use cases which i feel is not good designcoz i am making to design modular which might require lots of managment. So what is the best practices for designing the Work Item?

Mar 24, 2006 at 10:05 AM
originally posted by: ChrisHolmes

OK, these are just my opinions and observations, but take them for what they're worth:

I start by trying to conceptualize what the Use Case is really doing and determining the Boundaries for the Use Case.

I think determining the Boundaries of the Use Case might actually be one of the most important things you do. By Boundaries I mean - what is this Use Case doing that is *only its job*, and not the job of something else? If I think about a behavior that the Use Case is engaging in, but that behavior is something another Use Case also engages in, then that is something that is probably not part of my WorkItem for this use case, but instead a Service or other WorkItem I depend on.

So, first thing I do is try and establish exactly what it is that this Use Case is doing, and isolate it as much as possible. Now, obviously WorkItems can interact with other WorkItems via Events and Commands, and they may even depend on each other to an extent. But I try and think of a WorkItem the same way I think of a class - it should do one thing and one thing well.

An example: I have an EmployeeWorkItem. It is in charge of the Use Case where someone needs to interact with an Employee's data. This can involve editing their e-mail or personal information, looking up work history, changing what Departments they fall under, etc. That's the Use Case - interacting with the data unique to a single employee. Thus the WorkItem is in charge of creating the Views necessary to fulfill that Use Case. This may entail several views, a Tabbed WorkSpace, several presenters, a Service to connect to a backend Database, and several Events to talk to Shell UI Items as well. But when I conceptualize what this WorkItem is doing it's dealing with Employee Data and nothing more.

To me a good WorkItem is something that has a very defined purpose - a Use Case - that is clear and concise. A general rule of thumb for me on a WorkItem is, if I can't describe it to a colleage in one sentence then it's probably doing too much work and needs to be trimmed down.
Mar 24, 2006 at 10:40 AM
originally posted by: Debugger_11

That was really very good and helpful, what i have done is done in my cases i have created hierarchies of WorkItem and isolated them.
Thanks Chris