Author Topic: Modelling design considerations?  (Read 213 times)

OpenIT Solutions

  • EA User
  • **
  • Posts: 511
  • Karma: +5/-0
    • View Profile
Modelling design considerations?
« on: June 26, 2020, 05:34:21 pm »
Hi,

Any thoughts on the best way to model 'design considerations' in Sparx. Is there a standard UML approach to capturing design considerations. Any additional Sparx functionality that can/should be used to document these ?

Thanks,

Jon.

Uffe

  • EA Practitioner
  • ***
  • Posts: 1775
  • Karma: +122/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Re: Modelling design considerations?
« Reply #1 on: June 26, 2020, 06:17:36 pm »
Hi Jon,

Is there a standard UML approach to capturing design considerations.

Not in UML proper. Design considerations belong to the realm of requirements, and UML doesn't do requirements. (You can't express design considerations as a use case. At least, you can, I suppose, but what a hell of a life.)

Depending on precisely how you interpret the term I'd say they should be modelled as requirements or requirement types.
If your design considerations are very generic, something like "extensibility" and nothing more, make them requirement types. You will want to nail down what exactly is meant by "extensibility" somewhere along the line.
If your design considerations are more specific, something like "it should be possible to add a new major feature to the solution with no more than six weeks' work", then that's more of a requirement in itself and you could create a DesignConsideration requirement type for it.

Another option might be to turn them into constraint types. I'm less enamored of that, since constraints aren't model elements and therefore can't be traced.

HTH,


/Uffe
My theories are always correct, just apply them to the right reality.

Richard Freggi

  • EA User
  • **
  • Posts: 302
  • Karma: +11/-5
    • View Profile
Re: Modelling design considerations?
« Reply #2 on: June 28, 2020, 01:19:50 am »
Hi Jon,

Is there a standard UML approach to capturing design considerations.

Not in UML proper. Design considerations belong to the realm of requirements, and UML doesn't do requirements. (You can't express design considerations as a use case. At least, you can, I suppose, but what a hell of a life.)

Depending on precisely how you interpret the term I'd say they should be modelled as requirements or requirement types.
If your design considerations are very generic, something like "extensibility" and nothing more, make them requirement types. You will want to nail down what exactly is meant by "extensibility" somewhere along the line.
If your design considerations are more specific, something like "it should be possible to add a new major feature to the solution with no more than six weeks' work", then that's more of a requirement in itself and you could create a DesignConsideration requirement type for it.

Another option might be to turn them into constraint types. I'm less enamored of that, since constraints aren't model elements and therefore can't be traced.

HTH,


/Uffe

Yes design consideration are a type of requirement and/or constraint, TOGAF is a pretty good way to handle it, the key point of TOGAF requirement management is that the modeler must have the experience and skill to decide which phases  will impacted by  the requirement eg. Phase A, B. C, D, E, F... in practice you need to maintain your use case model, sequence diagram, class diagram, component diagram at conceptual and logical level consistent with the requirement (using tagged values or other Sparx mechanisms to keep track of the original requirement).  Works pretty good after you get some experience.