Re: The Overview & Requirements Spec is TOAST ??

> I don't think I agreed to update the Overview & Requirements spec on the
> fly?
>
> Particularly changing the requirements & overview spec at the same time as
> we're changing the messsaging services spec is completely untenable as it
> will lead to inconsistencies, and require a tremendous amount of time to do
> - that I haven't got. It also makes it a meaningless exercise since the
> REQUIREMENTS that are defined are no longer being used as REQUIREMENTS.

I think that we are assuming that all our requirements have been captured in the general ebXML requirements so that this document is no longer required. My only convern is that I am not confident that we have a process that allows us to add or modify the requirements as our discovery process continues. I am a strong supporter of having all the ebXML requirements in a single place; however, I am not sure that we have a process that can define, valdiate, and add these requirements as quickly as we may need. I offer the Brussels meeting as an example. I remember that as we worked through the Message Header document we were discovering requirements moment by moment. We are almost six months further along, but I am confident that there are still requirements lurking about that must be properly stated.

> So basically folks, now, my view is that the Overview and Requirements spec
> is TOAST !! We no longer need to refer to it, nor are we using it to:
> 1. control the scope of what we do
> 2. provide a reference of what we are trying to achieve.
>
> This also goes completely against all the project management/systems
> development activities I have ever been involved in where you write the
> requirements first then build to them.
I completely agree. We state the requirements then build; however, our history seems to show that we either have not done a very good job of defining the requirements or that the problem is evolving at the same moment we are trying to define it. I honestly believe that we have tried to do the very best job possible to define the requirements, but the problem is still immature. Just look at the security area if you doubt this fact. I am willing to say that we have validated requirements that we must build to--I also say that we have emerging requirements that we must recognize when they surface. I can support a process that validates the requirements and then passes them to the Requirements PT for inclusion in the ebXML requirements document, still I would like confidence that a highly-reactive process has been put in place to do this.

>
> So my conclusion is ...
>
> LET ANARCHY PREVAIL
>
> Ok, now perhaps I'm putting it a bit strong, but do we really want to build
> a solution without having ANY requirements onm which is based. I think not.
>
> David
>
> -----Original Message-----
> From: CTaylorEvans@aol.com [mailto:CTaylorEvans@aol.com]
> Sent: Tuesday, August 29, 2000 6:35 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Re: Do we need to revisit the Overview & Requirements document
>
>
> At the San Jose meeting David 'volunteered' to be the keeper of the
> requirements document and bring it up to date with all recent discussions.
>
> Best regards,
> Colleen
>

ebxml-transport message