1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Draft Use Cases

Discussion in 'Scenery Design Suite X' started by scruffyduck, 1/10/06.

  1. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    The following is my first stab at use cases - bound to be wrong :) Based on the updated Design Schematic

    Last edited: 1/10/06
  2. lmoelleb

    lmoelleb

    Joined:
    23/4/05
    Messages:
    266
    Personally I believe you are going into too much detail here, with the risk of drowning important decision in specifications like needing a "Save as".

    Instead of the methods, I would try to focus on what the user will want to do (so the goal, not how it is achieved).

    For example the user does not want to decompile bulk or single file. He wants to place his models in his scenery, and is in theory not really caring how we do it, as long as his model shows up where he expects. :)

    I am not sure the user really wants to see object libraries either (please notice I am saying "I am not sure", not "I am certain he won't"). He might think more in the form "I want to place an object", and then not really caring if it comes from a 3rd party library, a standard FS scenery object, or his own MDL file. Actually this is one of the few really big doubts I have on how this should be done (based on my experience from my current tool that is doing a lot of what we are trying here). But I will not hijack this thread for that, but post it separately when I find the time (which might not be today).
  3. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    Fair Point, on the other hand a user would certainly want to be able to create a new scenery project, open an existing one etc.

    Again fair point it is more of a method. I guess it could be part of loading a scenery project since we could be getting background data from FS BGL Files.

    The user will almost certainly want to be able to select objects from libraries. He will also want to add the information about the objects in those libraries into the program so that he can select them to place them. He might also want to categorize them to make it easier to find the building he wants out of the several hundred he has spread over a dozen libraries. I think that all the scenery design programs that I currently know about allow the user to import information about objects and libraries. If the scenery designer is designing for third party distribution then the he will need to know what libraries the objects he has used come from so that he can advise users on which ones they need to have installed so that the scenery works.
  4. lmoelleb

    lmoelleb

    Joined:
    23/4/05
    Messages:
    266
    Jon,

    I am not arguing against the functions being needed, but they are needed because they are required for the user to carry out his use cases - they are the means to do it, not the goal.

    For example "He will also want to add the information about the objects in those libraries into the program so that he can select them to place them"

    As I see it, the use case here is that he wants to add objects from a library to Flight Simulator. The information he adds to the objects is not a goal in itself - it is a necessary step in order to carry out his goal efficently.

    Sorry for being a bit insistent on this, I am just trying to keep the documentation short, as if it get's too detailed we will diviate from it anyway. Hence I only created three use cases with regards to placing 3D objects.
  5. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    That's fair enough Lars, I suspect, well know, that you have a lot more experience in these matters than me :) i guess I get drawn into implementation details far too quickly :eek:
  6. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    Well I have beenn thinking about this and stepped back to what the goals of the system are and get four use cases now:

    • Configure Preferences
    • Manage Objects
    • Design Scenery
    • Deploy Scenery

    The last two are what it is all about I think, the first two I think are there - one the user will want to configure the program to suit their needs and set things up for their environment and second I think that they will want to manage the objects they can use in design and deployment. That could fall into two categories - 3D objects on the one hand and everything else.

    Does that seem better?
    Last edited: 1/10/06
  7. Golf-HotelDelta

    Golf-HotelDelta

    Joined:
    20/12/04
    Messages:
    9,769
    Country:
    unitedkingdom
    Can I add a request for custom autogen placement? For FS9 I use my own programs for helipads and vegetation but Annotator and AGenT for buildings and library objects.
  8. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    Sure I will add it to the list.
  9. lmoelleb

    lmoelleb

    Joined:
    23/4/05
    Messages:
    266
    Better, but I do not think preferences is a use case. Just ask yourself one simple question: Will a user use start the program to perform this task? Setting preferences is something the user will do in order to achive the task they want to perform (design scenery). They would never do it just for the sake of managing preferences. Managing objects can be a usecase for people who want to release library objects, but for scenery designers I would also call this a mean to reach the goal. I do not open my current program to manage my objects, I do it to design scenery. Hence the object management is one of the tasks performed when I place 3D objects.

    Have you looked at the three usecases I gave for 3D model placement? Any thought of those? I was probsbly a bit sloppy and should have made transforming existing objects clearer, but I still think they hold water pretty well.

    For scenery deployment/generation I actually have two use cases (and hence a feature requirements to support it):

    1) Generate a scenery for internal testing
    2) Generate a scenery for public release

    Basically this comes from a feature we have in the tool I already created - in reality people would NOT be ready for release at the same time, and it annoyed everyone that they could not just work on when something was finalized for release. Add to that the fact that some people disapear from the scenery creation world for a few months now and then leavnig half done scenery in the project. Hence the tool should track that some things in it are not yet ready for release, so it should only be included in the internal builds. One could argue we should have more release types, for example:
    * beta
    * private (meaning only the specific developer, not the internal scenery of everyone in the group)
    but personally I do not think this is necessary.
  10. scruffyduck

    scruffyduck Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    17/9/05
    Messages:
    24,981
    Country:
    wales
    OK I agree Scenery Design and Deployment are the primary goals for the program, managing objects is a means to achieving scenery design.
  11. arno

    arno Administrator Staff Member FSDevConf team Resource contributor

    Joined:
    28/5/04
    Messages:
    21,300
    Country:
    netherlands
    Yes of course, but adding autogen only makes sense once we have mesh scenery implemented as well. So it will not be in the first phase :).

Share This Page