4
« on: April 05, 2007, 07:09:50 am »
> So, how do people enumerate the:
> a. actors involved (not just the primary one)
the actors involved are documented with a use case diagram. if there are multiple actors involved in a use case, the association between the initating actor and the use case is named "initiator". do not follow the method of tagging actors as primary or secondary as sometimes actors, in the overall system, can be primary and sometimes they can be secondary. then there are actors that are essentially equals where no one is primary or secondary.
when you write your "system" use case description, it should follow the sequence of "actor action; system reaction, actor action; system reaction, actor action; system reaction, ...". the very first "actor action" identifies the initiating actor. any other actors involved in the use case are identified in the text either as an actor with associated action or an actor the system asychronously interacts with (ie. system transmits bill to billing system {actor}).
there is no need to "enumerate" your actors in some special section. it will likely be a waste of effort and something that goes out of date as people focus on updating the use case description.
> So, how do people enumerate the:
> b. level of the UC (e.g. Alistair's sea-level, sky-level, etc)
i am not familar with alistair's approach, but from a distance it looks pretty silly. i am a student of jacobson, the creator of the use case approach. in the unified process you will find two types of use cases: system and business. you will also discover the concept of "business goals".
a "system" use case model defines the functional requirements of a software system. it does not define system "goals" (sky level) as goals can be written quite wishy-washy (non-testable). this sky level approach sounds closer to the business goal approach found in the unified process' business modeling extension.
alistair's work sounds like its trying to throw the whole universe into one use case model. that wont work. it will be so big that you wont be able to understand it. your "system" use case model should just capture the functional software requirements of the system. you will likely need an associated requirements trace matrix to capture such non-functional requirements such as software architecture requirements and performance requirements. you will likely need a business goal model to capture business goals such as reduce operator workload and improve battlespace visualization.
the unified process is not just one model, but a series of models with tracability throughout.
> Do people just put the whole text into the NOTES (on the first tab)?
yes, use a use case template.
> Or do people still put preconditions and postconditions into the Constraints (3rd tab), putting nothing into the Scenarios (5th tab)?
no. thats too much interaction with the tool.
> As an aside, what do people use Files (last tab) for?
attaching documents that support or provide background information regarding the use case. for example, an interface design document.
> Does anyone actually link to Word Documents with formatted Use Case specifications?
i dont. that too much spawning of processes. one should be able to quickly traverse the use case model just by clicking on use cases and seeing the associated notes.
>>>>
tagged values are used as part of a UML profile. you shouldnt need a profile to do basic system use case modeling.
Show Posts
