Skip to main content
Jump to: navigation, search

Requirements Model Part Two

Revision as of 12:04, 6 February 2009 by (Talk | contribs) (New page: {{Backlink|Requirements Model}} === Introduction === Following the extensive conversation and model proposals so far, I have mined the exchanges and collected the important issues that ne...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

< To: Requirements Model


Following the extensive conversation and model proposals so far, I have mined the exchanges and collected the important issues that need further in depth exploration and I am presenting them on this page as separate discussion points, one for each issue I have identified. I hope the list is complete; if not, please feel free to add whatever I have missed.

I think we should delve into the issues before coming up with an up to date model that reflects all needs and concerns.

Discussion point: ORMF scope and boundaries

A lot has been said about this issue already. I appreciate the need for genericity and I am happy to see a "pure" core to ORMF that only includes classes like the ones you identify. I do think however that we need another layer (or maybe more than one? :-) that delves down into more concrete classes.

The key requirement here is that ORMF should be generic and flexible, but at the same time we want for adopters to be able to create their own tools without the need to create a whole requirements model almost from scratch. As Wolfgang's diagrams expressing the HHP and Volere models show, with ORMF being as abstract as he proposes, there is a big hunk of model that an adopter would have to define fbefore getting down to the business of building a tool.

I am trying to put together a requirements statement for ORMF, which will hopefully help in deciding what is to be inside and what is to be outside of the ORMF box.

The key elements here, in my mind, are ease of use and, above all, ease of extension. 17:04, 6 February 2009 (UTC)

Discussion point: versioning

Wolfgang's suggestion to use discriminators to provide versioning seems a good one to me.

We do need to explore this subject much more deeply to see if it is possible for us to tackle it frontally in release 1.0. Handling version control, restoring specific versions of the artefacts, viewing and resolving differences etc. appear to me to be hairy issues that require a lot of effort. 17:04, 6 February 2009 (UTC)

Discussion point: extension by specialisation vs attribute

I am not against using attributes if this makes the model less ponderous.

I have two concerns:

  • using an enumeration, as Viet suggests for a requirement kind, is not a good idea as it does not offer itself to easy extension by adopters;
  • we need to delve more deeply into the various types of requirements to see whether the distinctions between them are simply in a label that defines their type or if there are deeper and more substantial differences in their natures, in terms of the information that needs to be captured for each type and, possibly, their behaviour. 17:04, 6 February 2009 (UTC)

Discussion point: Stakeholder vs Owner

I personally do not think that Owner and Stakeholder are two mutually esxclusive classes. I see Stakeholder being the useful class in the model, and owner being the (special) relationship a stakeholder has with an Artefact when she owns it (i.e. is ultimately responsible for its capture and maintenance). 17:04, 6 February 2009 (UTC)

Stereotypes and tags

We need to discuss more deeply merits and deficiencies of the two approaches. I think we really need to be mindful of Wolfgang's "meta data hell" warning here. 17:04, 6 February 2009 (UTC)

Discussion point: DescribableElement class

I believe Wolfgang's reply to Viet's concerns on this issue have clarified matters. I think the idea of a general DescribableElement class is a bit redundant, as we are already considering the Taggable interface for that purpose.

I agree with Wolfgang and I actually love the idea of the Discriminator being tightly indentified with some sort of search criteria and linked to the Collection element which represents search results. Elegant and flexible, I think. 17:04, 6 February 2009 (UTC)

Discussion point: Status attribute

I certainly agree that this is an important concept to be associated with a requirements artefact, especially from the management perspective. I think though that it is not the only one in this category. Others come to mind, such as priority, difficulty, and possibly others that are utilised by the Project Manager to prioritise their requirements and, ultimately, to create their project plans.

I concur with Wolfgang's concerns about the complexity introduced by a Lifecycle element. I would suggest that we create a list of all the management related attributes that we want to support and think about developing them along similar lines. 17:04, 6 February 2009 (UTC)

Discussion point: Business rules and business flows

As I mentioned already, our initial vision for business rules and flows was as elucidators for primary requirements artefacts. However I realise that we do need to discuss whether or not we want to support these elements in a more primary role. 17:04, 6 February 2009 (UTC)

Discussion point: parent/child relationship

I am not quite sure where we stand on this issue. Is it still relevant? 17:04, 6 February 2009 (UTC)

Discussion point: Different levels of abstraction for use cases

If we deem use cases outside of ORMF, this is probably an issue we can leave for later, when we start thinking about Useme as the exemplary tool. Maybe it is worth considering whether or not, if we want to support the concept of varying levels of abstraction, we could make use of Wolfgang's discriminator mechanism for it. 17:04, 6 February 2009 (UTC)

Discussion point: Design Constraint, Vision and Goals

I guess this issue may be lumped in with the first issue regarding ORMF's boundaries. 17:04, 6 February 2009 (UTC)

Back to the top