Use Cases and Requirements priorities

Hi all,

At our meeting this week, we discussed which use cases were deemed to be 
"highest priority", and I took the action to look at whether the "high 
priority" UCs were covering a large number of our requirements.

TL;DR: 23 of 28 requirements are covered by the "high priority" use 
cases. And there are other ways to split them which may help us with 
setting the "level 1" goalposts.


Now for the detail:

1) I updated the wiki page for use cases and requirements with a mention 
of priority. At the moment, use cases 1 (Video Chat), 2 (HTML5 game with 
audio, effects, music) and 7 (Audio/Music visualization) are HIGH 
priority, and UC6 (Wavetable synthesis of a virtual music instrument) is 
MEDIUM priority. All the others (including the newly added use case 13 
for audio recording+saving) are LOW priority.

These priorities have gone unchallenged since the meeting on Monday, and 
since my pointer to the minutes two days ago, so I assume we have consensus?


2) I made a detailed mapping of the 13 uses cases and 28 requirements. 
See e.g:
http://www.w3.org/2011/audio/wiki/Use_Cases_and_Requirements#UC1_.E2.80.94_Related_Requirements

This is the part which I have done in good faith but I am sure there are 
mistakes. There were many use cases where it wasn't entirely clear 
whether “Modularity of Transformation" was required, or "Dynamic 
Compression" (the latter because I am not enough of an expert to be 
certain). Likewise, some of our requirements (such as "Audio Quality") 
are very vague and hardly usable, and others (“Support for basic 
polyphony” and “Mixing Sources”) are near-equivalent.

That said, I think the map is a flawed but reasonable approximation of 
the territory. I have re-mapped it to the table I had sent a couple of 
weeks ago. I am attaching the latest version to this mail. The visual 
representation makes it easy to know which requirements are associated 
with more or fewer use cases.


Interestingly, if I count only whether a requirement is associated to a 
high priority use case, I find that 23 out of the 28 we have are.

The exceptions:
* Playback rate adjustment
* Dynamic range compression (possibly my mistake)
* Generation of common signals for synthesis and parameter modulation 
purposes
* The ability to read in standard definitions of wavetable instruments
* Acceptable performance of synthesis

Alternatively, we could split requirements thus:

* 9 Requirements are shared by more than half of the UCs
     Support for primary audio file formats
     Playing / Looping sources of audio
     Support for basic polyphony
     Audio quality
     Modularity of transformations
     Transformation parameter automation
     Gain adjustment
     Filtering
     Mixing Sources

* 14 Requirements shared by less than half of the Use Cases, but 
required by HIGH priority UCs
     One source, many sounds
     Capture of audio from microphone, line in, other inputs
     Sample-accurate scheduling of playback
     Buffering
     Rapid scheduling of many independent sources
     Triggering of audio sources
     Spatialization
     Noise gating
     The simulation of acoustic spaces
     The simulation of occlusions and obstructions
     Ducking
     Echo cancellation
     Level detection
     Frequency domain analysis

* 5 Requirements shared by less than half of the UCs and not required by 
HIGH priority UCs
     Dynamic range compression
     Playback rate adjustment
     Generation of common signals for synthesis and parameter modulation 
purposes
     The ability to read in standard definitions of wavetable instruments
     Acceptable performance of synthesis



Thoughts? Opinion on whether this is helpful? Glaring mistakes in the 
process? Other ways you'd go at it?


Thanks,
-- 
Olivier