ICONIX Process

Activity diagrams are a dynamic UML diagram that can be used to better describe use cases, business flow, software flow or any other type of behavior. Activity diagrams are general purpose in their application.

• Activities can have multiple arrows in but only 1 out (except object flows).
• Activities must have 1 arrow out (never 0).
• Decisions – diamonds – can have multiple arrows in but only 2 out (no more, no less).
• Forks (start of parallelism) can have multiple arrows in and multiple out.
• Join (end of parallelism) can have multiple arrows in and only 1 arrow out.
• Anything that forks must also join at the end.
• It’s OK to have multiple finals on an activity diagram, but you can have (and must have) only 1 start.

In my last blog I talked about rules for domain models. Here are a few rules for requirements:

Requirements are rules to which the system or business must adhere. They are usually updated as the software development progresses and are usually written as text (although diagrams can be used to augment the requirements).

• Complete: Requirements should be as complete- no open endedness.
• Testable: Must be able to create a test for all requirements
• Consistent: Requirements must be consistent with each other; no conflicts
• Feasible: Possible to do
• Design Free: Software requirements should be specified at the requirements level and not at the design level. Keep out of the system
• Unambiguous: Use “Shall” and Related Words. Don’t be wishywashy