Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Requirements Model Part Two

Revision as of 13:42, 6 February 2009 by Joel.Rosi-Schwartz.Etish.org (Talk | contribs) (Discussion point: extension by specialisation vs attribute)

< To: Requirements Model

Introduction

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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Joel.Rosi-Schwartz.Etish.org 17:36, 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Joel.Rosi-Schwartz.Etish.org 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).

--Barbara.Rosi-Schwartz.Etish.org 17:04, 6 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 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?

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 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.

--Barbara.Rosi-Schwartz.Etish.org 17:04, 6 February 2009 (UTC)

Back to the top