Requirements Model Part Two

From Eclipsepedia

Jump to: navigation, search

< 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.

The brief Requirements Statement may also help in guiding through the discussion on the required model.

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 before getting down to the business of building a tool.

Another example where I would like to see more concreteness is in the various types of Elucidators. Whilst only the generic Elucidator class might go into the core of ORMF, I really think it would be important to have, readily available, a whole set of "ubiquitous" elucidators, which are pretty much represented in the concrete Elucidator type classes in my original model. After all, I cannot think of any analyst who would not like to have Glossary Terms, Notes or Issues at her disposal out of the box.

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)

I have been spending some quality time with CDO which may provide the versioning support that we want more or less out of the box. For those of you not familiar with CDO it is an EMF sub-project that "is a 3-tiers solution for distributed shared models and a complete model repository server." What is attractive about CDO for ORMF that it provides much of the scalability, persistence, client update, querying and versioning features that are desirable for ORMF. I still have a considerable amount of learning to do, but so far it looks very feasible. I should be able to resolve my open questions and concerns over the coming week. 17:36, 6 February 2009 (UTC)

Discussion point: Profiles

We need to be a little wary of this: I do not think EMF supports profiles directly. However there may be a workaround if we decide they are important in our model. Perhaps Joel can elucidate on this point. 17:46, 6 February 2009 (UTC)

I an afraid the UML Profiles and EMF do not play to together. After doing some research I post to the EMF newsgroup and got a reply from Ed Merks, see the thread here [1]

There are comparable features offered by EMF to enable extension that we can utilise.

My suggestion is that these conversations should not be focused on the technology of how adopters approach the task of extending the Core ORMF, but rather on what needs to be achieved by the extension. 18:09, 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 Veit 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)

I would like to qualify the comment about enumerations. If what Veit meant was using a standard Jave Eumeration, then the issue is that they are a finite set that is determined at compile time. There is no way to extend them, meaning expand the list of values.

On the other hand if we are using the term loosely to indicate a list of valid values, then I prefer the term LOV (List of Values) that could, f.i., be stored in the database, and be easily expanded. 17:42, 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)

Hello, I also think modelling the "Owner-Relationship" as a Class is a good idea. First I wanted to pose some arguments against using a class, since I felt that ownership has no member-attributes I can think of at the moment. Thus ownership should be modelled with a relationship rather tha a class. But after I gave this issue more thought I think modelling the ownwership as a class is better. First this class doesn't add to much complexity. Besides I think we can ommit complexity of the model to a certain degree, if we agree about the point that the users of tools build on ORMF don't have to be aware of the model. If this is the case, only possible tool developers are concerned with the model and then expresiveness is more important that simplicity. Second a class is way more flexible. A class offers the possibility to add Annotations later (see the Profile thread and especially Ed Merks comment) and if one wants to build e.g. a grapical editor based on GMF on the Metamodel it is way easier to reflect the ownership graphically if it is modelled as a class.ORMF Ownership Relation.jpg 12:34, 9 February 2009 (UTC)

Discussion point: 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 Veit'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)