Greetings Tankfish,
First, May I suggest that you get one of the free community BPMN versions or download Bizagi (www.bizagi.com). They also have a few tutorials that would help.
Check with Vinnie, he used another piece of software to draw his diagrams. This will save you time drawing these diagrams.
Your diagram appears to be an implementation of sorts.
I've created an abstract process for the logger bit only. I've elaborated slighltly on the 2- minute timeout and retry. I'm providing this purely so that you get an idea of the BPMN objects. Secondly, the diagram captures the end-to-end process (the experience) of the logger(human or otherwise) . Normally I would not worry too much about the timeout and signon detail activities in this kind of diagram.
The message flows provide the interfaces in the abstract diagram. You can implement them in many ways.
Als van die beste!
K
Downloading BizAgi as we speak. What a awesome website as well.
Thanks a lot for the info.Really helpful as well.
Dankie Mnr,
I use Altova UModel Enterprise, which cost us 249USD. Altova has many other products that we use as well, so we just stuck with them.
Ok, so I see this diagram as maybe being the middle tier then. Based on the diagram we would have something like this.
Business Requiremenst (1st)
We need a web based system that our customers can logon to and view/download the data transmitted by their loggers in the field. Each customer must only be able to see their site and its data.
System Requirement (2nd)
See diagram.
Functional Requirements (3rd)
Is that correct? Will the BRD almost always be shorter than the FRD?
I have some comments:
a) I encourage stakeholders to provide separate business requirements to distinguish one from another. It helps me organize things better, personally. For example:
b) It appears that perhaps a tech influenced the business requirements documentation more than the stakeholders. There are solutions mixed in with requirements. For instance, it's not necessary up-front to require that the system be Web-based --even if that's the popular route these days. Who knows, perhaps a developer would devise a more advantageous stand-alone solution (not likely, I know, but just consider the point that I'm trying to make)? I also removed the requirement for "downloading" the data; perhaps another transmission solution would be proposed by a member of another team other than the stakeholder's. Perhaps even an automated process would be devised? The bottom line is that customers need to view and receive transmission information pertinent to them. That simple, and that could even have been the complete business requirement.
c) Functional requirements 1 and 6 include system solutions. Bullets 3 through 6 of functional requirement 2 do not seem to pertain to dates. Point 1 is purely a system solution; security is a measure that must always be expected and the technical staff must determine the solution. In point 6, who decided that the file "must" be available in .pdf format (seems more like a tech solution)?
Regards,
vinny
Hi Vinny,
Thanks a lot for the input. I see that I made a typo in point 2. It is meant to be Data and not Dates. I think I see what you are saying, but I am still a little confused about the key difference between a functional requirement and a system requirement. Would functional req be “This is what the system must do” and a system req is “This is how it should do it” For example;
Functional Requirement: Application must allow the user to login using a username and password.
System Requirement: 1. Each users username must be unique. 2. The Password must be min 6 characters and alpha numeric.
My next question would be as BA’s, is it then our responsibility to define the System Requirements as well? Or is that for the Solution Architect?
Thanks once again,
Regards Justin
brought to you by enabling practitioners & organizations to achieve their goals using: