Requirements: one doc or two?

I'm starting work on a formal requirements doc for IndieUI, based on the
work we did at the last Face to Face meeting, and wanted to get input on
whether we expect to publish a single requirements document for all of
IndieUI, or separate ones for Events and User Context. I was expecting
to cross this bridge later, but it affects the name of the source I
would commit to the repository, so would like to answer sooner.

Regardless of the decision we take for the formal requirements, I think
we would continue to work on the two sets of requirements mostly
separately, as we've been doing. So I don't see this affecting current work.

Advantages of putting the two sets of requirements in one doc:

  * We show a unified plan for IndieUI 1.0;
  * It's easier to show how scenarios are met by a combination of Events
    and User Context requirements - if there are cases where that's
    valuable;
  * The doc can still be organized into sub-sections to separate the
    requirements somewhat;
  * We only have one formal deliverable to push through the bureaucracy;
  * This will encourage us to update the requirements more often, since
    an update to either Events or User Context triggers a republication
    of the entire set.

Advantages of separting them:

  * If Events and User Context are quite different from each other, it's
    less confusing to have separate requirements;
  * It's easier to work on them on completely separate timelines;
  * They can focus on meeting different scenarios.

I lean towards having a single requirements document (the first version
of which would only have Events requirements). But it's not a strong
leaning, I want to get other preferences.

Michael

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>