Requirements Model Part Two

< To: Requirements Model

Please note: The new requirements model is now available here. This page is useful for historical purposes.

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.

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.

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

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

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

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

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. I have added an Image showing the two possibilities. Maybe we even find a abstract class that subsumes Relationships between requirements and the ownership realtionship. There may be even more things. --Vhoff.lufgi3.informatik.rwth-aachen.de 12:34, 9 February 2009 (UTC)

This leads to the question then: what is the relationship between a Stakeholder and an Owner? Must an Owner be a Stakeholders or is it possible for a user to be an Owner without being a Stakeholder? I have a hard time thinking about why I would want to give ownership to someone who is not an interested party. So then, would an Owner than be a specialisation of a Stakeholder? Or possibly simply a stereotype?

Let me present another view of the world. The system clearly needs the concept of a User, if for nothing more exiting, Authentication and Authorisation. I have found it very useful to model Roles on top of the User such that each user can have one or more Roles with some Roles be applied to specific resources. This turns out to be extremely flexible and powerful.

--Joel.Rosi-Schwartz.Etish.org 12:47, 9 February 2009 (UTC)

Here is a quick diagram to make what I am talking about more concrete. I believe that it captures your intent Veit, but it is more general.

--Joel.Rosi-Schwartz.Etish.org 17:30, 11 February 2009 (UTC)

I think that this aproach is quite elegant and very flexible. But here the question is how flexible do we want to be? If we are this flexible within the model, tailoring is needed before a the model can be actually used to capture requirements. In this case one has to define the different RoleTypes before a ORMF-model can be instantiated. I don't think that those roles are project specific or dependant on the actual project that is to be developed, but on the "requirements model". Here I don't mean the ORMF-Metamodel but the abstract idea how to capture requirements. I.e. Volere could be a "requirements model" and the Volere-Artefacts could be captured with the help of the ORMF-Metamodel. Having a flexible solution like you propose, one has to tailor the model to reflect the RoleTypes Volere proposes first. I quite like this idea! But if we decide to have a highly generic model like this, more of this tailoring patterns will arise e.g. Status. Maybe if we decide to have a tailorable model we should think about whitebox-tailoring i.e. SubClassing again. Wolfgang propopsed something like this in the very beginning of the discussion. Anyhow, i think in your model the dependancy between Role and RoleType should be the other way round. A Role should reference a RoleType. This wont be a containment relationship then.

--Vhoff.lufgi3.informatik.rwth-aachen.de 09:24, 12 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)

I have reviewed Wolfgangs statement and I agree with his point. This was basically a misunderstanding of the names of the model elements. Maybe the name Discriminator is not good, since I thought of a generic textual addon like a description. I don't like the name Filter too, since this seems to technical to me. Anyhow I now undestand the concept of Discriminators and agree that they are usefull.

--Vhoff.lufgi3.informatik.rwth-aachen.de 09:38, 12 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)