We achieved our objective with Version 1, in that we got our foot in the door. The software adequately captured the essence of the board/card game, and was Reliable and Usable enough not to scare the users off--they're asking for more. Unfortunately, Microsoft has taken notice that we've identified a market niche, and has started their own versions of the games. Therefore, the U of O Funding Services no longer sees the project as viable past Version 2 (individual project teams, of course, are free to take on Microsoft on their own).

The Version 2 high-level project trade-offs are the same as they were for Version 1: the schedule/deadline is rigid, there is a minimum required feature set (and is flexible beyond that), and budget is up to you. The deadline is 3/10.

The high-level (quality attribute) emphasis of this version should be Reliability and Usability (the features will primarily focus on providing flexibility and ease-of-use for the user). The scope should be relatively small, to allow nailing the target. We'll be more picky about "bugs" and interface design.

Also, more emphasis on the artifacts (SRS, etc.) will be placed on this version, as opposed to version 1.0. To allow this, the only artifacts (i.e., non-functioning components) are: SRS, Project Plan, V&V/Test Plan (and ADD, if significant modifications are made that you want to draw attention to). If the Version 1 documents are used (i.e., added to), it should be easy for the reader to determine what the Version 2 features are (e.g., a "New in Version 2" section at the beginning of the documents).

Extensibility/Modifiability should have already been handled in version 1.0, so should need an emphasis placed here. Of course, if in attempting to add the additional feature set in 2.0 design shortcoming from 1.0 are recognized, it's appropriate to address them here. From a grade standpoint, corrections made in 2.0 can compensate for shortcomings in 1.0 (the ultimate goal is mastering the concepts).