Home » Archived » ORMF » The importance of standards
| The importance of standards [message #4617] |
Mon, 10 March 2008 16:54  |
|
[Tim deBoer said]
The other thing you'll want to mention is relevant standards and
specifications. I don't know if there are any standards or specs in the
requirements space, but you should mention them, and whether you are
following them or why not. Where possible, most Eclipse tools follow
external standards to ensure compatibility and acceptance of users.
[Harm Sluiman said]
Also, there are no "standards" for requirements and defects etc. which
are in the end the data artifacts you will pass so if you can also find
a way to embrace or influence some W3C. OMG or ISO group to start
defining a draft which you provide the reference impl for you will be
guaranteed a winner.
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
| Re: The importance of standards [message #4686 is a reply to message #4617] |
Mon, 10 March 2008 18:41  |
|
On 2008-03-10 16:54:06 +0000, Joel Rosi-Schwartz
<Joel.Rosi-Schwartz@Etish.org> said:
> [Tim deBoer said]
> The other thing you'll want to mention is relevant standards and
> specifications. I don't know if there are any standards or specs in the
> requirements space, but you should mention them, and whether you are
> following them or why not. Where possible, most Eclipse tools follow
> external standards to ensure compatibility and acceptance of users.
>
> [Harm Sluiman said]
> Also, there are no "standards" for requirements and defects etc. which
> are in the end the data artifacts you will pass so if you can also find
> a way to embrace or influence some W3C. OMG or ISO group to start
> defining a draft which you provide the reference impl for you will be
> guaranteed a winner.
This certainly opens up Pandora's box :-) As far as I know there are
no meaningful standards in the space. Certainly the IEEE plays a role
and I suspect other organisations have some say. So I suspect that you
are quite right Harm that nobody has actually tackled standardising
this space. I also suspect that it would be wise to find out why that
is before rushing in; I hear the strains of "Fools rush in where angles
fear to tread" playing in the background :-) That said it would be
really exiting to be part of an effort that was actually able to bring
some sanity and consensus to this. I am game for at least exploring
what it would take.
Thanks,
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
| |
| Re: The importance of standards [message #6028 is a reply to message #4686] |
Mon, 10 March 2008 23:34 |
Eclipse User |
|
|
|
Originally posted by: neil.prestemon.sri.com
The IEEE last tackled standards in this space in 1998.
(at least that's what I'm learning in my current Software Engineering
class).
The de-facto industry standards I've seen seem to consist of; a Project
Lead drafting a few HTML pages or an Excel spreadsheet at the start of a
project, which is perhaps paid attention to through the first three-to-six
months, and ultimately bears no resemblance to the finished product.
Where more rigorous standards are applied; I've seen very expensive tools
used, where node-locked licenses are not purchased for all stakeholders,
so you end up with an "ivory-tower" effect. . . the people who signed the
contract, wrote the checks, etc. have their idea of what the agreed upon
requirements were - (which ultimately bears no resemblance to the finished
product). In this case - you end up spending a lot of time, effort, and
money, developing a product that can pass the same validation testing as
defined by the requirements - yet, was somehow not what the customer had
in mind five years ago when they went through elicitation.
As I've written in email to Joel; an RM tool can take two approaches
(okay, two extremes across a spectrum) - the tool can enforce a certain
approach, and create a standard - in which case, you're fighting a couple
of decades worth of culture and habit (of the potential adopter), so you
better bring some compelling value to that enforcement. (which, IMO, Useme
does bring).
Or, the tool can be designed to be flexible in its approach (and an Open
Framework is, by nature, more flexible), which would appeal to a wider
market, but with more UI/configuration options, would probably be more
difficult to use.
Some approaches are wedded to development methodologies, which could erect
further barriers to adoption - (ie. an RM tool that's designed around
Scrum is going to be less appealing to a company that uses a heavyweight
process).
In any case: standards, indeed, would be a lively debate, because you get
into the whole agile-versus-traditional engineering-process religious
flamewar. :)
|
|
| |
| Re: The importance of standards [message #561695 is a reply to message #4617] |
Mon, 10 March 2008 18:41 |
|
On 2008-03-10 16:54:06 +0000, Joel Rosi-Schwartz
<Joel.Rosi-Schwartz@Etish.org> said:
> [Tim deBoer said]
> The other thing you'll want to mention is relevant standards and
> specifications. I don't know if there are any standards or specs in the
> requirements space, but you should mention them, and whether you are
> following them or why not. Where possible, most Eclipse tools follow
> external standards to ensure compatibility and acceptance of users.
>
> [Harm Sluiman said]
> Also, there are no "standards" for requirements and defects etc. which
> are in the end the data artifacts you will pass so if you can also find
> a way to embrace or influence some W3C. OMG or ISO group to start
> defining a draft which you provide the reference impl for you will be
> guaranteed a winner.
This certainly opens up Pandora's box :-) As far as I know there are
no meaningful standards in the space. Certainly the IEEE plays a role
and I suspect other organisations have some say. So I suspect that you
are quite right Harm that nobody has actually tackled standardising
this space. I also suspect that it would be wise to find out why that
is before rushing in; I hear the strains of "Fools rush in where angles
fear to tread" playing in the background :-) That said it would be
really exiting to be part of an effort that was actually able to bring
some sanity and consensus to this. I am game for at least exploring
what it would take.
Thanks,
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme
|) ::: (| The Open Requirements Management Tool
====w=w==== [https://useme.dev.java.net]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
| |
| Re: The importance of standards [message #561921 is a reply to message #4686] |
Mon, 10 March 2008 23:34 |
| Eclipse User |
|
|
|
Originally posted by: neil.prestemon.sri.com
The IEEE last tackled standards in this space in 1998.
(at least that's what I'm learning in my current Software Engineering
class).
The de-facto industry standards I've seen seem to consist of; a Project
Lead drafting a few HTML pages or an Excel spreadsheet at the start of a
project, which is perhaps paid attention to through the first three-to-six
months, and ultimately bears no resemblance to the finished product.
Where more rigorous standards are applied; I've seen very expensive tools
used, where node-locked licenses are not purchased for all stakeholders,
so you end up with an "ivory-tower" effect. . . the people who signed the
contract, wrote the checks, etc. have their idea of what the agreed upon
requirements were - (which ultimately bears no resemblance to the finished
product). In this case - you end up spending a lot of time, effort, and
money, developing a product that can pass the same validation testing as
defined by the requirements - yet, was somehow not what the customer had
in mind five years ago when they went through elicitation.
As I've written in email to Joel; an RM tool can take two approaches
(okay, two extremes across a spectrum) - the tool can enforce a certain
approach, and create a standard - in which case, you're fighting a couple
of decades worth of culture and habit (of the potential adopter), so you
better bring some compelling value to that enforcement. (which, IMO, Useme
does bring).
Or, the tool can be designed to be flexible in its approach (and an Open
Framework is, by nature, more flexible), which would appeal to a wider
market, but with more UI/configuration options, would probably be more
difficult to use.
Some approaches are wedded to development methodologies, which could erect
further barriers to adoption - (ie. an RM tool that's designed around
Scrum is going to be less appealing to a company that uses a heavyweight
process).
In any case: standards, indeed, would be a lively debate, because you get
into the whole agile-versus-traditional engineering-process religious
flamewar. :)
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 15:45:35 GMT 2024
Powered by FUDForum. Page generated in 0.03394 seconds |
] 
Search
Help
Register
Login
Home
