...
To weigh the relative merits of each option we used a project management tool called a product requirements matrix, a grid that lists each feature the finished system should be able to perform (read this page for a fuller description). The matrix Gabe Galson made in consultation with the Services and Metadata groups can be found at the top of this page. The Groups ranked each feature's importance, giving it one of four ratings: 'must have', 'should have', 'could have', or 'won’t have'. These rankings, generated by stakeholders, can be cross referenced with a 'difficulty of execution' ranking that can be assigned by by the developers and technical team. Or, they can be consulted by developers who can advise on the best solution. This matrix is a bit more complex than the standard example, as we’re already locked into DSpace as our administrative interface, and whatever front end approach we decide on must take this into account. This means, for starters, that certain features requested by the Groups could either be fulfilled via DSpace, or via the second system, depending on the approach we take. It also means that the fact that a feature is front end (relating to the interface) or back end (relating to the administration of the objects and metadata the system contains) is important, as it determines whether it can be done through DSpace’s out-of-the-box functionalities, or whether it must be rebuilt in the second system. Note that the matrix is still a work in progress, and will be revised and brought back to the Services Group for further review. Stay tuned!
...