Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Technology Project and PMC » A Requirements plugin...anybody interested?
A Requirements plugin...anybody interested? [message #55642] Wed, 02 July 2003 12:33 Go to next message
Eclipse UserFriend
Originally posted by: steve.bannerman.comlab.ox.ac.uk

All,

Reqs
--
I'm currently working on a doctorate in software engineering. I recently
started an open source project to provide: (1) a generic requirements markup
language (RML); and (2) tool sets to browse/transform a set of requirements
files. The name of the project is "Reqs."

At a high level, it proposes embodying requirements in an analogous manner
to embodying source code: individual requirements in .rml files just like
individual Java classes in .java files (I know, except for inner classes
:-)). This avoids the "monolithic" requirements documents that we all love
to hate. Then, we can use the same configuration management tools that we
use in managing source code for requirements. You can check out the open
source project at: http://reqs.comlab.ox.ac.uk:8080/reqs.

Requirement Browsing Perspective
--
Anyhow, the reason that I'm writing this newsgroup is that one of the
planned extensions to the core is an Eclipse extension. What I envision is
us, as Eclipse users, being able to load a set of requirements files into
our Eclipse workspace, browse them, sort them, filter them, and sometimes
even change them (if they're wrong or if we want to indicate that we've
implemented the code and the automated tests to support them, for example).

So talking in Eclipse terminology, I expect a Requirements Browsing
perspective (since the requirements files are organized within packages that
exist within folders). At the web site there is a Swing application that
you can download (under products) and from there you can probably use your
imagination as to how it might look within Eclipse.

Potential Benefits
--
Not only would this provide a tool of general applicability to all Eclipse
users, it might even provide some benefit to some or all of the Eclipse
projects or subprojects. If they don't already have a mechanism for
allocating requirements to releases (or Sprints in Scrum), rather than just
relying on a defect tracking tool, it could help.

It could provide a way for the team to place their requirements into a
repository and under version control as well as decide what attributes (if
any) they want to attach to their requirements (for example: what is the
priority of this requirement and how long do we think it will take to
implement). The core toolset is pretty configurable in this sense.

However, there may all ready be similar tools available that I'm not aware
of...if so, my apologies. I looked a little at "Koi" but it seemed to be
targeting real-time collaboration...this is not. Rather, it is just meant
to be a way to communicate requirements over the most ubiquitous computing
resource we have: the file system, and in a non-real time manner.

So, if anybody (or the project committee) is interested in such a
project/subproject, that's great. I'm willing to host the code at the web
site mentioned earlier. Alternatively, we could host the project here and
link to it from the other web site.

Interested to hear the community's thoughts...

Cheers
--
Steve Bannerman
steve.bannerman@comlab.ox.ac.uk
44.(0)1865.273866
Re: A Requirements plugin...anybody interested? [message #55670 is a reply to message #55642] Thu, 03 July 2003 07:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_0317_01C34156.9CEDD110
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Hi, Steve.

It sounds interesting, but can you explain current project status and =
fuatures to be developed.
I have some work experience and requirements gathering and providing =
requirements specifications for programmers and can note that =
requirements are always not enought for programmers. They always require =
detailed definition of system under development, otherwise they are =
doing something else.
So to provide full substitution for usual text documents (and text =
editors like MS Word) you have to support full set of project =
documentation.
But at this point another question arise. It is common to explain ideas =
and design with UML and ER models, so full featured tool have to support =
embedded diagrams. It may not provide editing capabilities, but must be =
capable of displaying them.

Finally I suggest you to visit xmlbasedsrs.tigris.org

--=20
Best wishes,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_0317_01C34156.9CEDD110
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D""><FONT size=3D2>Hi, =
Steve.<BR><BR>It sounds=20
interesting, but can you explain current project status and fuatures to =
be=20
developed.<BR>I have some work experience and requirements gathering and =

providing requirements specifications for programmers and can note that=20
requirements are always not enought for programmers. They always require =

detailed definition of system under development, otherwise they are =
doing=20
something else.<BR>So to provide full substitution for usual text =
documents (and=20
text editors like MS Word) you have to support full set of project=20
documentation.<BR>But at this point another question arise. It is common =
to=20
explain ideas and design with UML and ER models, so full featured tool =
have to=20
support embedded diagrams. It may not provide editing capabilities, but =
must be=20
capable of displaying them.<BR><BR>Finally I suggest you to visit <A=20
href=3D"http://xmlbasedsrs.tigris.org">xmlbasedsrs.tigris.org</A><BR><BR>=
--=20
<BR>Best wishes,<BR>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></BODY></HTML=
>

------=_NextPart_000_0317_01C34156.9CEDD110--
Re: A Requirements plugin...anybody interested? [message #55698 is a reply to message #55670] Thu, 03 July 2003 14:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: steve.bannerman.comlab.ox.ac.uk

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C3417A.161B76A0
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Mikhail,

Thanks for your response and ideas...here are my replies. If you get a =
chance to look at the web site (http://reqs.comlab.ox.ac.uk:8080/reqs), =
it has more information (hopefully):

(1) current project status - core is "fairly" mature, meaning that the =
"model" modeling the requirements (workbench, folders, packages, =
requirements, filters, sorters, processors) and the associated behaviors =
are fairly mature;

(2) features to be developed - Eclipse plugin (subject of this thread), =
Web application (prototyped but not yet publicl available), and Swing =
(initial version publicly available);

(3) requirements are not enough for programmers - definitely, I =
wholeheartedly agree. That's why the framework allows for associations =
with other artifacts. To illustrate using your example, here's an =
example .rml file:

<requirement>
<title>Create switch</title>
<state name=3D"partially supported"></state>
<description>Create a switch in the context of a site</description>
<attributes>
<attribute type=3D"string" name=3D"owner" value=3D"John =
Smith"></attribute>
<attribute type=3D"date" name=3D"created" =
value=3D"01/01/2003"></attribute>
<attribute type=3D"integer" name=3D"estimated effort (hrs)" =
value=3D"8"></attribute>
</attributes>
<associations>
<association type=3D"url" name=3D"some doc" =
value=3D"file:///c/docs/doc1.doc"></association>
<association type=3D"url" name=3D"some dgm" =
value=3D"http://artifacts/diagrams/dgm1.dgm"></association>
<association type=3D"url" name=3D"some defect" =
value=3D"http://bugzilla/show_bug.cgi?id=3D1"></association>
</associations>
</requirement>

The intent is to make this toolset as simple as possible and defer the =
work to other toolsets where possible (i.e. Word for a .doc and a =
diagram editor for a .dgm). This is similar to how Eclipse opens up a =
platform application to edit a file (if you associate that type of file =
with the platform application).

Another typical example would be associating the requirement with any =
defects that are identified by testers (in, for example, bugzilla). =
Such associations would come and go as the defects are found and fixed =
(respectively).

(4) A main difference between this framework and the one you cited =
(http://xmlbasedsrs.tigris.org) is "granularity." I'm proposing a single =
requirement per requirement file...a line item for the project manager =
types with an effort and a priority; that project proposes that an =
entire SRS be modeled in a single .xml file.

While this may not sound like a big difference, I think it is. Think =
about why we don't write entire Java applications in a single .java file =
(or why we shouldn't!). By keeping the requirements in separate files, =
there is better concurrency and they can be packed into a =
hierarchy...and as you know, hierarchies are a wonderful thing for =
making things understandable and maintainable.

Another difference is that extensions to the core will hide the form of =
the .rml files from those editing the content of the requirements. While =
developers can edit the .rml files however the want (emacs, vi, notepad, =
whatever), there are some on project teams who don't have the skills or =
the desire to edit .xml files.

Does all of that make sense? Hopefully it does.

--=20
Steve Bannerman=20
steve.bannerman@comlab.ox.ac.uk=20
44.(0)1865.273866=20


"Mikhail Krivoshein" <mikkri@pisem.net> wrote in message =
news:be0lra$2cd$1@rogue.oti.com...
Hi, Steve.

It sounds interesting, but can you explain current project status and =
fuatures to be developed.
I have some work experience and requirements gathering and providing =
requirements specifications for programmers and can note that =
requirements are always not enought for programmers. They always require =
detailed definition of system under development, otherwise they are =
doing something else.
So to provide full substitution for usual text documents (and text =
editors like MS Word) you have to support full set of project =
documentation.
But at this point another question arise. It is common to explain =
ideas and design with UML and ER models, so full featured tool have to =
support embedded diagrams. It may not provide editing capabilities, but =
must be capable of displaying them.

Finally I suggest you to visit xmlbasedsrs.tigris.org

--=20
Best wishes,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_0016_01C3417A.161B76A0
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>
<P>Mikhail,</P>
<P>Thanks for your response and ideas...here are my replies. If you get =
a chance=20
to look at the web site (<A=20
href=3D"http://reqs.comlab.ox.ac.uk:8080/reqs">http://reqs.comlab.ox.ac.u=
k:8080/reqs</A>),=20
it has more information (hopefully):</P>
<P>(1) current project status - core is "fairly" mature, meaning that =
the=20
"model" modeling the requirements (workbench, folders, packages, =
requirements,=20
filters, sorters, processors) and the associated behaviors are fairly=20
mature;</P>
<P>(2) features to be developed - Eclipse plugin (subject of this =
thread), Web=20
application (prototyped but not yet publicl available), and Swing =
(initial=20
version publicly available);</P>
<P>(3) requirements are not enough for programmers - definitely, I=20
wholeheartedly agree. That's why the framework allows for associations =
with=20
other artifacts. To illustrate using your example, here's an example =
..rml=20
file:</P>
<P><FONT face=3DArial =
size=3D1>&lt;requirement&gt;<BR>&nbsp;&lt;title&gt;Create=20
switch&lt;/title&gt;<BR>&nbsp;&lt;state name=3D"partially=20
supported"&gt;&lt;/state&gt;<BR>&nbsp;&lt;description&gt;Create a switch =
in the=20
context of a =
site&lt;/description&gt;<BR>&nbsp;&lt;attributes&gt; <BR>&nbsp;=20
&lt;attribute type=3D"string" name=3D"owner" value=3D"John=20
Smith"&gt;&lt;/attribute&gt;<BR>&nbsp; &lt;attribute type=3D"date" =
name=3D"created"=20
value=3D"01/01/2003"&gt;&lt;/attribute&gt;<BR >&nbsp; &lt;attribute =
type=3D"integer"=20
name=3D"estimated effort (hrs)"=20
value=3D"8"&gt;&lt;/attribute&gt;<BR>&nbsp;&lt;/attributes&gt; <BR>&nbsp;&=
lt;associations&gt;<BR>&nbsp;=20
&lt;association type=3D"url" name=3D"some doc" value=3D"</FONT><A=20
href=3D'file:///c/docs/doc1.doc"></association'><FONT face=3DArial=20
size=3D1>file:///c/docs/doc1.doc"&gt;&lt;/association</FONT></A><FONT =
face=3DArial=20
size=3D1>&gt;<BR>&nbsp; &lt;association type=3D"url" name=3D"some dgm"=20
value=3D"</FONT><A =
href=3D'http://artifacts/diagrams/dgm1.dgm"></association'><FONT=20
face=3DArial=20
size=3D1>http://artifacts/diagrams/dgm1.dgm"&gt;&lt;/association</FONT></=
A><FONT=20
face=3DArial size=3D1>&gt;<BR>&nbsp; &lt;association type=3D"url" =
name=3D"some defect"=20
value=3D"</FONT><A =
href=3D'http://bugzilla/show_bug.cgi?id=3D1"></association'><FONT=20
face=3DArial=20
size=3D1>http://bugzilla/show_bug.cgi?id=3D1"&gt;&lt;/association</FONT><=
/A><FONT=20
face=3DArial size=3D1>&gt;<BR>&nbsp;=20
&lt;/associations&gt;<BR>&lt;/requirement&gt; </FONT></P>
<P>The intent is to make this toolset as simple as possible and defer =
the work=20
to other toolsets where possible (i.e. Word for a .doc and a diagram =
editor for=20
a .dgm). This is similar to how Eclipse opens up a platform application =
to edit=20
a file (if you associate that type of file with the platform =
application).</P>
<P>Another typical example would be associating the requirement with any =
defects=20
that are identified by testers (in, for example, bugzilla).&nbsp; Such=20
associations would come and go as the defects are found and fixed=20
(respectively).</P>
<P>(4) A main difference between this framework and the one you cited =
(<A=20
href=3D"http://xmlbasedsrs.tigris.org">http://xmlbasedsrs.tigris.org</A>)=
is=20
"granularity." I'm proposing a single requirement per requirement =
file...a line=20
item for the project manager types with an effort and a priority; that =
project=20
proposes that an entire SRS be modeled in a single .xml file.</P>
<P>While this may not sound like a big difference, I think it is. Think =
about=20
why we don't write entire Java applications in a single .java file (or =
why we=20
shouldn't!). By keeping the requirements in separate files, there is =
better=20
concurrency and they can be packed into a hierarchy...and as you know,=20
hierarchies are a wonderful thing for making things understandable and=20
maintainable.</P>
<P>Another difference is that extensions to the core will hide the form =
of the=20
..rml files from those editing the content of the requirements. While =
developers=20
can edit the .rml files however the want (emacs, vi, notepad, whatever), =
there=20
are some on project teams who don't have the skills or the desire to =
edit .xml=20
files.</P>
<P>Does all of that make sense? Hopefully it does.</P>
<P></FONT>-- <BR>&nbsp;&nbsp; Steve Bannerman <BR>&nbsp;&nbsp; <A=20
href=3D"mailto:steve.bannerman@comlab.ox.ac.uk">steve.bannerman@comlab.ox=
..ac.uk</A>=20
<BR>&nbsp;&nbsp; 44.(0)1865.273866 <BR></P></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Mikhail Krivoshein" &lt;<A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A>&gt; wrote in =
message <A=20
=
href=3D"news:be0lra$2cd$1@rogue.oti.com">news:be0lra$2cd$1@rogue.oti.com<=
/A>...</DIV><FONT=20
size=3D2>Hi, Steve.<BR><BR>It sounds interesting, but can you explain =
current=20
project status and fuatures to be developed.<BR>I have some work =
experience=20
and requirements gathering and providing requirements specifications =
for=20
programmers and can note that requirements are always not enought for=20
programmers. They always require detailed definition of system under=20
development, otherwise they are doing something else.<BR>So to provide =
full=20
substitution for usual text documents (and text editors like MS Word) =
you have=20
to support full set of project documentation.<BR>But at this point =
another=20
question arise. It is common to explain ideas and design with UML and =
ER=20
models, so full featured tool have to support embedded diagrams. It =
may not=20
provide editing capabilities, but must be capable of displaying=20
them.<BR><BR>Finally I suggest you to visit <A=20
=
href=3D"http://xmlbasedsrs.tigris.org">xmlbasedsrs.tigris.org</A><BR><BR>=
--=20
<BR>Best wishes,<BR>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT>=20
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0016_01C3417A.161B76A0--
Re: A Requirements plugin...anybody interested? [message #55725 is a reply to message #55698] Thu, 03 July 2003 15:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01C3419B.8D0DE420
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Steve,

thank you for this explanation.
I'll read your article this evening and post my thoughts here today.
It was not easy to find PDF file on your site because of not so good =
color schema and absense of any graphical marks, like PDF icon.

Best regards,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_006B_01C3419B.8D0DE420
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>Steve,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>thank you for this&nbsp;explanation.</FONT></DIV>
<DIV><FONT size=3D2>I'll read your article this evening and post my =
thoughts here=20
today.</FONT></DIV>
<DIV><FONT size=3D2>It was not&nbsp;easy to find PDF file on your site =
because of=20
not so good color schema and absense of any graphical marks, like PDF=20
icon.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Best regards,</FONT></DIV>
<DIV><FONT size=3D2>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_006B_01C3419B.8D0DE420--
Re: A Requirements plugin...anybody interested? [message #55752 is a reply to message #55698] Fri, 04 July 2003 07:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01C34220.F17B4440
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Hi, Steve.

I have read your idea description. It is really interesting.
I think it will be nice to reuse already existing facilities of =
configuration managment system to track requirements changes (one file =
per requirement idea). Also use of XML for data representation brings =
many opportunities for requirements analysis as a whole thing (your =
filters idea).

But I think you misunderstand capabilities of lightweight requirements =
management systems and their weak sides. For example, our system is =
divided in about ten modules with low coupling, so we successfully beat =
complexity with dividing requirements into packeges, one package per =
module. Concurrency issues are also handled. We use two separate sets of =
documents. The first set describes stable version of system and the =
second is separated into smaller parts with related Change Requests. So =
in the second part of our documentation set we have one requirements =
document per Change Request. Usually Change Request are small, so there =
is no need to concurrently change related requirements document. After =
some time delay (Change request is completed, results are tested and =
deloyed into production) we move documents from the second set into the =
first set.
Really weak side of such document flow is that then I want to get all =
requirements for system or some module I have to join them from large =
amount of separate documents. Also it is very hard to trace requirements =
set for some module by release.
So if I'll be capable to incorporate it with our development process and =
document flow, I'll get ability to incorporate some requirements =
analysis practicies. And it will be valuable result.

At the end I ask you about my involvement into project. I can help to =
find weak sides and after some level of maturity I can try to =
incorporate this tool into our environment and provide early feedback. =
Also I can help with Java and XML coding, but I'm notably constrained =
with time that I can contribute to this project.

Best regards,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_00BF_01C34220.F17B4440
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>Hi, Steve.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I have&nbsp;read your idea description. It is really =

interesting.</FONT></DIV>
<DIV><FONT size=3D2>I think it will be nice to reuse already existing =
facilities=20
of configuration managment system to track requirements changes (one =
file per=20
requirement idea). Also use of XML for data representation brings many=20
opportunities for requirements analysis as a whole thing (your filters=20
idea).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>But I think you misunderstand capabilities of =
lightweight=20
requirements management systems and their weak sides. For example, our =
system is=20
divided in about ten modules with low coupling, so we successfully beat=20
complexity with dividing requirements into packeges, one package per =
module.=20
Concurrency issues are also handled. We use two separate sets of =
documents.=20
The&nbsp;first set describes stable version of system and the second is=20
separated into smaller parts with related Change Requests. So in the =
second part=20
of our documentation set we have one requirements document per Change =
Request.=20
Usually Change Request are small, so there is no need to concurrently =
change=20
related requirements document. After some time delay (Change request is=20
completed, results are tested and deloyed into production)&nbsp;we move=20
documents from the second set into the first set.</FONT></DIV>
<DIV><FONT size=3D2>Really weak side of such document flow is that then =
I want to=20
get all requirements for system or some module I have to join them from =
large=20
amount of separate documents. Also it is very hard to trace requirements =
set for=20
some module by release.</FONT></DIV>
<DIV><FONT size=3D2>So if I'll be capable to incorporate it with our =
development=20
process and document flow, I'll get&nbsp;ability =
to&nbsp;incorporate&nbsp;some=20
requirements analysis practicies. And it will be valuable =
result.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>At the end I ask you about my involvement into =
project. I can=20
help to find weak sides and&nbsp;after some level of maturity&nbsp;I can =
try to=20
incorporate this tool into our environment and provide early feedback. =
Also I=20
can help&nbsp;with Java and XML coding, but I'm notably constrained with =
time=20
that I can contribute to this project.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Best regards,</FONT></DIV>
<DIV><FONT size=3D2>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_00BF_01C34220.F17B4440--
Re: A Requirements plugin...anybody interested? [message #56639 is a reply to message #55642] Tue, 05 August 2003 10:55 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Steve,

I'm a bit surprised that you have had so little response to you post.
You may consider reposting to the e.platform forum, it appears to me
that many announcements of this type show up there. Just a thought.

- joel

Steve Bannerman wrote:
> All,
>
> Reqs
> --
> I'm currently working on a doctorate in software engineering. I recently
> started an open source project to provide: (1) a generic requirements markup
> language (RML); and (2) tool sets to browse/transform a set of requirements
> files. The name of the project is "Reqs."
>
> At a high level, it proposes embodying requirements in an analogous manner
> to embodying source code: individual requirements in .rml files just like
> individual Java classes in .java files (I know, except for inner classes
> :-)). This avoids the "monolithic" requirements documents that we all love
> to hate. Then, we can use the same configuration management tools that we
> use in managing source code for requirements. You can check out the open
> source project at: http://reqs.comlab.ox.ac.uk:8080/reqs.
>
> Requirement Browsing Perspective
> --
> Anyhow, the reason that I'm writing this newsgroup is that one of the
> planned extensions to the core is an Eclipse extension. What I envision is
> us, as Eclipse users, being able to load a set of requirements files into
> our Eclipse workspace, browse them, sort them, filter them, and sometimes
> even change them (if they're wrong or if we want to indicate that we've
> implemented the code and the automated tests to support them, for example).
>
> So talking in Eclipse terminology, I expect a Requirements Browsing
> perspective (since the requirements files are organized within packages that
> exist within folders). At the web site there is a Swing application that
> you can download (under products) and from there you can probably use your
> imagination as to how it might look within Eclipse.
>
> Potential Benefits
> --
> Not only would this provide a tool of general applicability to all Eclipse
> users, it might even provide some benefit to some or all of the Eclipse
> projects or subprojects. If they don't already have a mechanism for
> allocating requirements to releases (or Sprints in Scrum), rather than just
> relying on a defect tracking tool, it could help.
>
> It could provide a way for the team to place their requirements into a
> repository and under version control as well as decide what attributes (if
> any) they want to attach to their requirements (for example: what is the
> priority of this requirement and how long do we think it will take to
> implement). The core toolset is pretty configurable in this sense.
>
> However, there may all ready be similar tools available that I'm not aware
> of...if so, my apologies. I looked a little at "Koi" but it seemed to be
> targeting real-time collaboration...this is not. Rather, it is just meant
> to be a way to communicate requirements over the most ubiquitous computing
> resource we have: the file system, and in a non-real time manner.
>
> So, if anybody (or the project committee) is interested in such a
> project/subproject, that's great. I'm willing to host the code at the web
> site mentioned earlier. Alternatively, we could host the project here and
> link to it from the other web site.
>
> Interested to hear the community's thoughts...
>
> Cheers
Re: A Requirements plugin...anybody interested? [message #594438 is a reply to message #55642] Thu, 03 July 2003 07:31 Go to previous message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_0317_01C34156.9CEDD110
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Hi, Steve.

It sounds interesting, but can you explain current project status and =
fuatures to be developed.
I have some work experience and requirements gathering and providing =
requirements specifications for programmers and can note that =
requirements are always not enought for programmers. They always require =
detailed definition of system under development, otherwise they are =
doing something else.
So to provide full substitution for usual text documents (and text =
editors like MS Word) you have to support full set of project =
documentation.
But at this point another question arise. It is common to explain ideas =
and design with UML and ER models, so full featured tool have to support =
embedded diagrams. It may not provide editing capabilities, but must be =
capable of displaying them.

Finally I suggest you to visit xmlbasedsrs.tigris.org

--=20
Best wishes,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_0317_01C34156.9CEDD110
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D""><FONT size=3D2>Hi, =
Steve.<BR><BR>It sounds=20
interesting, but can you explain current project status and fuatures to =
be=20
developed.<BR>I have some work experience and requirements gathering and =

providing requirements specifications for programmers and can note that=20
requirements are always not enought for programmers. They always require =

detailed definition of system under development, otherwise they are =
doing=20
something else.<BR>So to provide full substitution for usual text =
documents (and=20
text editors like MS Word) you have to support full set of project=20
documentation.<BR>But at this point another question arise. It is common =
to=20
explain ideas and design with UML and ER models, so full featured tool =
have to=20
support embedded diagrams. It may not provide editing capabilities, but =
must be=20
capable of displaying them.<BR><BR>Finally I suggest you to visit <A=20
href=3D"http://xmlbasedsrs.tigris.org">xmlbasedsrs.tigris.org</A><BR><BR>=
--=20
<BR>Best wishes,<BR>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></BODY></HTML=
>

------=_NextPart_000_0317_01C34156.9CEDD110--
Re: A Requirements plugin...anybody interested? [message #594452 is a reply to message #55670] Thu, 03 July 2003 14:45 Go to previous message
Eclipse UserFriend
Originally posted by: steve.bannerman.comlab.ox.ac.uk

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C3417A.161B76A0
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Mikhail,

Thanks for your response and ideas...here are my replies. If you get a =
chance to look at the web site (http://reqs.comlab.ox.ac.uk:8080/reqs), =
it has more information (hopefully):

(1) current project status - core is "fairly" mature, meaning that the =
"model" modeling the requirements (workbench, folders, packages, =
requirements, filters, sorters, processors) and the associated behaviors =
are fairly mature;

(2) features to be developed - Eclipse plugin (subject of this thread), =
Web application (prototyped but not yet publicl available), and Swing =
(initial version publicly available);

(3) requirements are not enough for programmers - definitely, I =
wholeheartedly agree. That's why the framework allows for associations =
with other artifacts. To illustrate using your example, here's an =
example .rml file:

<requirement>
<title>Create switch</title>
<state name=3D"partially supported"></state>
<description>Create a switch in the context of a site</description>
<attributes>
<attribute type=3D"string" name=3D"owner" value=3D"John =
Smith"></attribute>
<attribute type=3D"date" name=3D"created" =
value=3D"01/01/2003"></attribute>
<attribute type=3D"integer" name=3D"estimated effort (hrs)" =
value=3D"8"></attribute>
</attributes>
<associations>
<association type=3D"url" name=3D"some doc" =
value=3D"file:///c/docs/doc1.doc"></association>
<association type=3D"url" name=3D"some dgm" =
value=3D"http://artifacts/diagrams/dgm1.dgm"></association>
<association type=3D"url" name=3D"some defect" =
value=3D"http://bugzilla/show_bug.cgi?id=3D1"></association>
</associations>
</requirement>

The intent is to make this toolset as simple as possible and defer the =
work to other toolsets where possible (i.e. Word for a .doc and a =
diagram editor for a .dgm). This is similar to how Eclipse opens up a =
platform application to edit a file (if you associate that type of file =
with the platform application).

Another typical example would be associating the requirement with any =
defects that are identified by testers (in, for example, bugzilla). =
Such associations would come and go as the defects are found and fixed =
(respectively).

(4) A main difference between this framework and the one you cited =
(http://xmlbasedsrs.tigris.org) is "granularity." I'm proposing a single =
requirement per requirement file...a line item for the project manager =
types with an effort and a priority; that project proposes that an =
entire SRS be modeled in a single .xml file.

While this may not sound like a big difference, I think it is. Think =
about why we don't write entire Java applications in a single .java file =
(or why we shouldn't!). By keeping the requirements in separate files, =
there is better concurrency and they can be packed into a =
hierarchy...and as you know, hierarchies are a wonderful thing for =
making things understandable and maintainable.

Another difference is that extensions to the core will hide the form of =
the .rml files from those editing the content of the requirements. While =
developers can edit the .rml files however the want (emacs, vi, notepad, =
whatever), there are some on project teams who don't have the skills or =
the desire to edit .xml files.

Does all of that make sense? Hopefully it does.

--=20
Steve Bannerman=20
steve.bannerman@comlab.ox.ac.uk=20
44.(0)1865.273866=20


"Mikhail Krivoshein" <mikkri@pisem.net> wrote in message =
news:be0lra$2cd$1@rogue.oti.com...
Hi, Steve.

It sounds interesting, but can you explain current project status and =
fuatures to be developed.
I have some work experience and requirements gathering and providing =
requirements specifications for programmers and can note that =
requirements are always not enought for programmers. They always require =
detailed definition of system under development, otherwise they are =
doing something else.
So to provide full substitution for usual text documents (and text =
editors like MS Word) you have to support full set of project =
documentation.
But at this point another question arise. It is common to explain =
ideas and design with UML and ER models, so full featured tool have to =
support embedded diagrams. It may not provide editing capabilities, but =
must be capable of displaying them.

Finally I suggest you to visit xmlbasedsrs.tigris.org

--=20
Best wishes,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_0016_01C3417A.161B76A0
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>
<P>Mikhail,</P>
<P>Thanks for your response and ideas...here are my replies. If you get =
a chance=20
to look at the web site (<A=20
href=3D"http://reqs.comlab.ox.ac.uk:8080/reqs">http://reqs.comlab.ox.ac.u=
k:8080/reqs</A>),=20
it has more information (hopefully):</P>
<P>(1) current project status - core is "fairly" mature, meaning that =
the=20
"model" modeling the requirements (workbench, folders, packages, =
requirements,=20
filters, sorters, processors) and the associated behaviors are fairly=20
mature;</P>
<P>(2) features to be developed - Eclipse plugin (subject of this =
thread), Web=20
application (prototyped but not yet publicl available), and Swing =
(initial=20
version publicly available);</P>
<P>(3) requirements are not enough for programmers - definitely, I=20
wholeheartedly agree. That's why the framework allows for associations =
with=20
other artifacts. To illustrate using your example, here's an example =
..rml=20
file:</P>
<P><FONT face=3DArial =
size=3D1>&lt;requirement&gt;<BR>&nbsp;&lt;title&gt;Create=20
switch&lt;/title&gt;<BR>&nbsp;&lt;state name=3D"partially=20
supported"&gt;&lt;/state&gt;<BR>&nbsp;&lt;description&gt;Create a switch =
in the=20
context of a =
site&lt;/description&gt;<BR>&nbsp;&lt;attributes&gt; <BR>&nbsp;=20
&lt;attribute type=3D"string" name=3D"owner" value=3D"John=20
Smith"&gt;&lt;/attribute&gt;<BR>&nbsp; &lt;attribute type=3D"date" =
name=3D"created"=20
value=3D"01/01/2003"&gt;&lt;/attribute&gt;<BR >&nbsp; &lt;attribute =
type=3D"integer"=20
name=3D"estimated effort (hrs)"=20
value=3D"8"&gt;&lt;/attribute&gt;<BR>&nbsp;&lt;/attributes&gt; <BR>&nbsp;&=
lt;associations&gt;<BR>&nbsp;=20
&lt;association type=3D"url" name=3D"some doc" value=3D"</FONT><A=20
href=3D'file:///c/docs/doc1.doc"></association'><FONT face=3DArial=20
size=3D1>file:///c/docs/doc1.doc"&gt;&lt;/association</FONT></A><FONT =
face=3DArial=20
size=3D1>&gt;<BR>&nbsp; &lt;association type=3D"url" name=3D"some dgm"=20
value=3D"</FONT><A =
href=3D'http://artifacts/diagrams/dgm1.dgm"></association'><FONT=20
face=3DArial=20
size=3D1>http://artifacts/diagrams/dgm1.dgm"&gt;&lt;/association</FONT></=
A><FONT=20
face=3DArial size=3D1>&gt;<BR>&nbsp; &lt;association type=3D"url" =
name=3D"some defect"=20
value=3D"</FONT><A =
href=3D'http://bugzilla/show_bug.cgi?id=3D1"></association'><FONT=20
face=3DArial=20
size=3D1>http://bugzilla/show_bug.cgi?id=3D1"&gt;&lt;/association</FONT><=
/A><FONT=20
face=3DArial size=3D1>&gt;<BR>&nbsp;=20
&lt;/associations&gt;<BR>&lt;/requirement&gt; </FONT></P>
<P>The intent is to make this toolset as simple as possible and defer =
the work=20
to other toolsets where possible (i.e. Word for a .doc and a diagram =
editor for=20
a .dgm). This is similar to how Eclipse opens up a platform application =
to edit=20
a file (if you associate that type of file with the platform =
application).</P>
<P>Another typical example would be associating the requirement with any =
defects=20
that are identified by testers (in, for example, bugzilla).&nbsp; Such=20
associations would come and go as the defects are found and fixed=20
(respectively).</P>
<P>(4) A main difference between this framework and the one you cited =
(<A=20
href=3D"http://xmlbasedsrs.tigris.org">http://xmlbasedsrs.tigris.org</A>)=
is=20
"granularity." I'm proposing a single requirement per requirement =
file...a line=20
item for the project manager types with an effort and a priority; that =
project=20
proposes that an entire SRS be modeled in a single .xml file.</P>
<P>While this may not sound like a big difference, I think it is. Think =
about=20
why we don't write entire Java applications in a single .java file (or =
why we=20
shouldn't!). By keeping the requirements in separate files, there is =
better=20
concurrency and they can be packed into a hierarchy...and as you know,=20
hierarchies are a wonderful thing for making things understandable and=20
maintainable.</P>
<P>Another difference is that extensions to the core will hide the form =
of the=20
..rml files from those editing the content of the requirements. While =
developers=20
can edit the .rml files however the want (emacs, vi, notepad, whatever), =
there=20
are some on project teams who don't have the skills or the desire to =
edit .xml=20
files.</P>
<P>Does all of that make sense? Hopefully it does.</P>
<P></FONT>-- <BR>&nbsp;&nbsp; Steve Bannerman <BR>&nbsp;&nbsp; <A=20
href=3D"mailto:steve.bannerman@comlab.ox.ac.uk">steve.bannerman@comlab.ox=
..ac.uk</A>=20
<BR>&nbsp;&nbsp; 44.(0)1865.273866 <BR></P></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Mikhail Krivoshein" &lt;<A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A>&gt; wrote in =
message <A=20
=
href=3D"news:be0lra$2cd$1@rogue.oti.com">news:be0lra$2cd$1@rogue.oti.com<=
/A>...</DIV><FONT=20
size=3D2>Hi, Steve.<BR><BR>It sounds interesting, but can you explain =
current=20
project status and fuatures to be developed.<BR>I have some work =
experience=20
and requirements gathering and providing requirements specifications =
for=20
programmers and can note that requirements are always not enought for=20
programmers. They always require detailed definition of system under=20
development, otherwise they are doing something else.<BR>So to provide =
full=20
substitution for usual text documents (and text editors like MS Word) =
you have=20
to support full set of project documentation.<BR>But at this point =
another=20
question arise. It is common to explain ideas and design with UML and =
ER=20
models, so full featured tool have to support embedded diagrams. It =
may not=20
provide editing capabilities, but must be capable of displaying=20
them.<BR><BR>Finally I suggest you to visit <A=20
=
href=3D"http://xmlbasedsrs.tigris.org">xmlbasedsrs.tigris.org</A><BR><BR>=
--=20
<BR>Best wishes,<BR>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT>=20
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0016_01C3417A.161B76A0--
Re: A Requirements plugin...anybody interested? [message #594463 is a reply to message #55698] Thu, 03 July 2003 15:44 Go to previous message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_006B_01C3419B.8D0DE420
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Steve,

thank you for this explanation.
I'll read your article this evening and post my thoughts here today.
It was not easy to find PDF file on your site because of not so good =
color schema and absense of any graphical marks, like PDF icon.

Best regards,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_006B_01C3419B.8D0DE420
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>Steve,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>thank you for this&nbsp;explanation.</FONT></DIV>
<DIV><FONT size=3D2>I'll read your article this evening and post my =
thoughts here=20
today.</FONT></DIV>
<DIV><FONT size=3D2>It was not&nbsp;easy to find PDF file on your site =
because of=20
not so good color schema and absense of any graphical marks, like PDF=20
icon.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Best regards,</FONT></DIV>
<DIV><FONT size=3D2>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_006B_01C3419B.8D0DE420--
Re: A Requirements plugin...anybody interested? [message #594474 is a reply to message #55698] Fri, 04 July 2003 07:39 Go to previous message
Eclipse UserFriend
Originally posted by: mikkri.pisem.net

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01C34220.F17B4440
Content-Type: text/plain;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

Hi, Steve.

I have read your idea description. It is really interesting.
I think it will be nice to reuse already existing facilities of =
configuration managment system to track requirements changes (one file =
per requirement idea). Also use of XML for data representation brings =
many opportunities for requirements analysis as a whole thing (your =
filters idea).

But I think you misunderstand capabilities of lightweight requirements =
management systems and their weak sides. For example, our system is =
divided in about ten modules with low coupling, so we successfully beat =
complexity with dividing requirements into packeges, one package per =
module. Concurrency issues are also handled. We use two separate sets of =
documents. The first set describes stable version of system and the =
second is separated into smaller parts with related Change Requests. So =
in the second part of our documentation set we have one requirements =
document per Change Request. Usually Change Request are small, so there =
is no need to concurrently change related requirements document. After =
some time delay (Change request is completed, results are tested and =
deloyed into production) we move documents from the second set into the =
first set.
Really weak side of such document flow is that then I want to get all =
requirements for system or some module I have to join them from large =
amount of separate documents. Also it is very hard to trace requirements =
set for some module by release.
So if I'll be capable to incorporate it with our development process and =
document flow, I'll get ability to incorporate some requirements =
analysis practicies. And it will be valuable result.

At the end I ask you about my involvement into project. I can help to =
find weak sides and after some level of maturity I can try to =
incorporate this tool into our environment and provide early feedback. =
Also I can help with Java and XML coding, but I'm notably constrained =
with time that I can contribute to this project.

Best regards,
Mikhail Krivoshein,
mikkri@pisem.net
------=_NextPart_000_00BF_01C34220.F17B4440
Content-Type: text/html;
charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1251">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT size=3D2>Hi, Steve.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I have&nbsp;read your idea description. It is really =

interesting.</FONT></DIV>
<DIV><FONT size=3D2>I think it will be nice to reuse already existing =
facilities=20
of configuration managment system to track requirements changes (one =
file per=20
requirement idea). Also use of XML for data representation brings many=20
opportunities for requirements analysis as a whole thing (your filters=20
idea).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>But I think you misunderstand capabilities of =
lightweight=20
requirements management systems and their weak sides. For example, our =
system is=20
divided in about ten modules with low coupling, so we successfully beat=20
complexity with dividing requirements into packeges, one package per =
module.=20
Concurrency issues are also handled. We use two separate sets of =
documents.=20
The&nbsp;first set describes stable version of system and the second is=20
separated into smaller parts with related Change Requests. So in the =
second part=20
of our documentation set we have one requirements document per Change =
Request.=20
Usually Change Request are small, so there is no need to concurrently =
change=20
related requirements document. After some time delay (Change request is=20
completed, results are tested and deloyed into production)&nbsp;we move=20
documents from the second set into the first set.</FONT></DIV>
<DIV><FONT size=3D2>Really weak side of such document flow is that then =
I want to=20
get all requirements for system or some module I have to join them from =
large=20
amount of separate documents. Also it is very hard to trace requirements =
set for=20
some module by release.</FONT></DIV>
<DIV><FONT size=3D2>So if I'll be capable to incorporate it with our =
development=20
process and document flow, I'll get&nbsp;ability =
to&nbsp;incorporate&nbsp;some=20
requirements analysis practicies. And it will be valuable =
result.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>At the end I ask you about my involvement into =
project. I can=20
help to find weak sides and&nbsp;after some level of maturity&nbsp;I can =
try to=20
incorporate this tool into our environment and provide early feedback. =
Also I=20
can help&nbsp;with Java and XML coding, but I'm notably constrained with =
time=20
that I can contribute to this project.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Best regards,</FONT></DIV>
<DIV><FONT size=3D2>Mikhail Krivoshein,<BR><A=20
href=3D"mailto:mikkri@pisem.net">mikkri@pisem.net</A></FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_00BF_01C34220.F17B4440--
Re: A Requirements plugin...anybody interested? [message #594774 is a reply to message #55642] Tue, 05 August 2003 10:55 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Steve,

I'm a bit surprised that you have had so little response to you post.
You may consider reposting to the e.platform forum, it appears to me
that many announcements of this type show up there. Just a thought.

- joel

Steve Bannerman wrote:
> All,
>
> Reqs
> --
> I'm currently working on a doctorate in software engineering. I recently
> started an open source project to provide: (1) a generic requirements markup
> language (RML); and (2) tool sets to browse/transform a set of requirements
> files. The name of the project is "Reqs."
>
> At a high level, it proposes embodying requirements in an analogous manner
> to embodying source code: individual requirements in .rml files just like
> individual Java classes in .java files (I know, except for inner classes
> :-)). This avoids the "monolithic" requirements documents that we all love
> to hate. Then, we can use the same configuration management tools that we
> use in managing source code for requirements. You can check out the open
> source project at: http://reqs.comlab.ox.ac.uk:8080/reqs
>
> Requirement Browsing Perspective
> --
> Anyhow, the reason that I'm writing this newsgroup is that one of the
> planned extensions to the core is an Eclipse extension. What I envision is
> us, as Eclipse users, being able to load a set of requirements files into
> our Eclipse workspace, browse them, sort them, filter them, and sometimes
> even change them (if they're wrong or if we want to indicate that we've
> implemented the code and the automated tests to support them, for example).
>
> So talking in Eclipse terminology, I expect a Requirements Browsing
> perspective (since the requirements files are organized within packages that
> exist within folders). At the web site there is a Swing application that
> you can download (under products) and from there you can probably use your
> imagination as to how it might look within Eclipse.
>
> Potential Benefits
> --
> Not only would this provide a tool of general applicability to all Eclipse
> users, it might even provide some benefit to some or all of the Eclipse
> projects or subprojects. If they don't already have a mechanism for
> allocating requirements to releases (or Sprints in Scrum), rather than just
> relying on a defect tracking tool, it could help.
>
> It could provide a way for the team to place their requirements into a
> repository and under version control as well as decide what attributes (if
> any) they want to attach to their requirements (for example: what is the
> priority of this requirement and how long do we think it will take to
> implement). The core toolset is pretty configurable in this sense.
>
> However, there may all ready be similar tools available that I'm not aware
> of...if so, my apologies. I looked a little at "Koi" but it seemed to be
> targeting real-time collaboration...this is not. Rather, it is just meant
> to be a way to communicate requirements over the most ubiquitous computing
> resource we have: the file system, and in a non-real time manner.
>
> So, if anybody (or the project committee) is interested in such a
> project/subproject, that's great. I'm willing to host the code at the web
> site mentioned earlier. Alternatively, we could host the project here and
> link to it from the other web site.
>
> Interested to hear the community's thoughts...
>
> Cheers
Previous Topic:jar export problem
Next Topic:Classpaths in projects
Goto Forum:
  


Current Time: Thu Dec 26 23:26:31 GMT 2024

Powered by FUDForum. Page generated in 0.04921 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top