Hello GoDiagram users and developers.
I have a pretty general question about the techniques, styles and methods about specifying the requirements (also constrains and/or scenarios) how your diagram (not necessary the implementation) should act. Perhaps I don't express myself clear enough. So I will describe the specific situation in which our project is. I'm sure that some of you have been there and overcome it one or other way.
I currently work on a project that must produce a tool that transforms a custom domain specific graphical modeling notation (called ProcGraph) into some programming language. Because of the complexity we decide to develop prototype, which only allows diagram modeling. For that matter we want to use GoDiagram (which shouldn't be important on the level of requirements specification). Because all diagramming frameworks are very customizable and meant for a broad use, we must adopt it for our needs. Personally I've never developed such a product and we have major problems in our team (which consists mainly of electrical engineers) to specify how our diagram elements should act, interact, behave, which constrains they have... I will name those demands diagramming requirements. (The notation is also under development and some changes must definitely be made, the specification is just a scientific article long a couple of sites, which in I think isn't enough, but still they want have it implemented). I my opinion it is very important to specify all these things in some way so that we can later verify the prototype and validate the requirements with our users. Because these requirements are very different form the normal requirements of a software project, I'm not sure which technique to use for capturing them. I've spend the last month reading books on requirements and found nothing useful. I would be very thankful if someone could share how he has overcome this huge issue.
Since now I have captured these requirements or scenarios of possible situations with USE CASES, but the more I thing about it, the more inappropriate seems this technique. Here is the example:
Overview of the system:
The insides of modifying an existing relation:
Then I described each use case, like this:
1.
Model an entity;
<table =“MsoTableGrid” style=“border: medium none ; border-collapse: collapse;” border=“1” cellpadding=“0” cellspacing=“0”>
Name:
Create new Element
Id:
001
Implemented:
Half
Prerequisite(s):
/
Condition(s):
· The bounds of the created element do not intersect with bounds of any other object (except relations)
Action(s):
· Create new element
· Place its center on the mouse click point
· Adjust it to the grid
Interactive behavior:
/
<table =“MsoTableGrid” style=“border: medium none ; border-collapse: collapse;” border=“1” cellpadding=“0” cellspacing=“0”>
Name:
Deny creation of new Element
Id:
002
Implemented:
Half
Prerequisite(s):
/
Condition(s):
· The bounds of the created element intersect with bounds of another object
Action(s):
· Ignore the mouse click
Interactive behavior:
· Change mouse cursor to No symbol, when we are in the intersection area
But such a specification seems very akward too overwhelming. It also seems unnatural because use cases aren't meant for such modeling (it's weird to model each button and menu item in the GUI as an use case)
Any comments on that perhaps?
I would really be very thankful for anykind of comment or help.
Toma¾ L. @ E2 @ "Jo¾ef Stefan" Institute