Book a Demo

Author Topic: Context / Scope diagram  (Read 4812 times)

Dee

  • EA Novice
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Context / Scope diagram
« on: September 25, 2013, 04:41:12 pm »
Hello,

I'm very very new to EA and have spent the best part of the last two days experimenting with it. I work as a BA and am looking to use EA to be my requirements repository.

I've looked through the examples of the Use Case Model, business process model etc, but will use them. However, the starting point for our requirements as per the framework that we follow at work is a high level work context diagram that helps define scope. I can't see a model or a diagram that can be used as a basic work context diagram. I've tried doing one using the Mind Mapping model, but I'm wondering if there's a better way to do this. This is the kind of context diagram I'm looking to build.

http://www.epubbud.com/read.php?g=M3JQBF9V&p=40&two=1

I want to be able to re-use what I build, and then link it to a Use Case Model, and then requirements.

I have no training in BPMN or UML; just letting you know :)

Cheers,
Dee

Helmut Ortmann

  • EA User
  • **
  • Posts: 970
  • Karma: +42/-1
    • View Profile
Re: Context / Scope diagram
« Reply #1 on: September 25, 2013, 05:04:04 pm »
Hello,

I usually use a class diagram as a context diagram. Your system at hand in the middle and the stuff outside of your system at hand around.

For the stuff around your system you can use classes or actors.

As connection you may use associations or information flow.

Helmut
Coaching, Training, Workshop (Addins: hoTools, Search&Replace, LineStyle)

Gary

  • EA User
  • **
  • Posts: 84
  • Karma: +1/-0
    • View Profile
Re: Context / Scope diagram
« Reply #2 on: September 25, 2013, 06:15:03 pm »
We use a block diagram (essentially the same as Helmut but the SysML version). We add a block for the system and a boundary named for the context as we can have different levels of context. So from one context viewpoint the system is the whole system from another we may have shifted view down a level so that other internal subsystems are now external actors in the context of a particular subsystem. Use cases are then identified as the interactions across the boundary.

Gary