Can you use a use case instead of a process flow diagram(PFD)? This question is come up because my newest client does not have a standard PFD, instead they keep referring me to a set of Use Cases. I am laying out thier Quality Center processes and generally like to start with a PFD. What is a QA to do? Start with thier UCases and try to develope a PFD or just base my QC processes on the UCases?
They have use cases for their internal processes? As it's a client, I'd suggest starting there and developed the PFD. It will make the QC process setup go more quickly. It's also easier to get buy-in with a "picture" [img]/images/graemlins/smile.gif[/img].
Wierd? Yes. They have use cases for almost every process they follow, or for any application they present to thier customer base. Instead of documenting the 'process' itself they have lots of documents on what the user or customer experiences as he/she acts in or on the system. If the "actor" does some operation some effect is able to be percieved by either the actor or the application and life goes on. All of thier docs use standard use-case icons to identify the parts and they seem to be thorough so I will follow my gut and your advice. Thanks. [img]/images/graemlins/smile.gif[/img]
Is this a small company with limited process? I have seen this before in that sort of situation. The PFD is set aside and the UCs are used to define it.
Why are they using use cases for their internal processes. Are they over processing or covering all their bases to go for ISO or CMM or something?
In those cases I was able to use the UCs to create the PFD.
Do you have the decision making ability to move away from that current process of a process and either suggest movement to a more formal process or at the very least organize what they have?
The company is large, but they are trying to cover their bases in order to go for a CMMI. Sadly no I can't change the process from my level but I can give advise on what to do. I will be recommending that having a UC, while it is functional is not the cure for not having a written defined process. Plus they are doing quite a bit of over-kill in some cases with these UCs.
Just a warning: replacing UCses with PFD could significantly reduce work, but may also cause loosing information/ making documentation inaccurate or even wrong. If your client is used to consider a lot of standalone use-cases, they may fail to correctly translate this into diagrams: there is a risk to have over-simplified process designed.
We have both UC and PFD and there are still a lot of late realized requirements...
?:the art of a constructive conflict perceived as a destructive diagnose.
[ QUOTE ]
I will be recommending that having a UC, while it is functional is not the cure for not having a written defined process. Plus they are doing quite a bit of over-kill in some cases with these UCs.
[/ QUOTE ]
It all depends on the details of the use case. If it is just an UML diagram ... that's bad. A proper use case is a composition of such a diagram and at least a textual description containing the following details:
<ul type="square">[*] Use case name[*] Actors involved (With a glossary describing the actors)[*] Use case entry conditions[*] Flow of events[*] Termination conditions[*] Additional requirements and constraints[/list]
If these details are filled, the use case contains a superset of information a process flow diagram could tell you (agreed, it isn't graphical).
"Instead of documenting the 'process' itself they have lots of documents on what the user or customer experiences as he/she acts in or on the system."
It sounds like they have a lot of user stories rather than what I would generally term a use case. A good place to start on this task would be to get them to prioritize the user stories to primary pathways, alternate flows, and boundary conditions.
In the past I've proceeded from this strategy developing a reference guide calling out the user stories in order of flow (importance) rather than trying to reinvent the wheel. If you can get buy-off from the customer on the reference guide, you're 75% of the way there for a documented PFD should one become necessary later on.