Deciding on a Project/Weekly Work:

Once we formed our group, we ended up narrowing down our ideas to two projects that we were particularly interested in. These two projects were:

1) PSP Remote Desktop Application - Mark is looking to develop a better Remote Desktop Application for the PSP than that which is currently out. Although Mark would be the primary stakeholder, the homebrew community itself is also a stakeholder, and could provide for an interesting dynamic.

2) Mosaically.com Improvement Project - This would primarily focus on improving the customer experience and adding social sharing capabilities to Mosaically.com's existing design. At the same time, it would involve removing the manual element of creating mosaics, so that it can become and easier and more enjoyable experience for users.
We were all pretty hesitant to decide on which project we wanted to work on, so after an exercise in democracy and then in unbiased decision making, we chose the Mosaically.com Improvement Project.

This week, we worked on deciding the elicitation techniques for the project. I won't post the full details here, but in general the elicitation techniques we decided on were:

Questionnaires - Easy to distribute and to manage, these could be easily given to current users of the system and focus on how the system might best be improved. By distributing the questionnaire over a medium such as a forum, we could obtain large amounts of feedback to help us determine the most important aspects that need to be improved.

Use Cases - Being that this product focuses very heavily on user interaction, use cases provide the perfect medium for specifying our requirements. We intend to start by creating a list of use case scenarios based on the information obtained from the questionnaires and talking to our primary stakeholder. As a team, we would then detail and refine each use case to best fit the needs of the user.

Study Similar Products - This is a fairly unique method of gathering requirements, since there are actually competing products we can use to compare against. We'd start by researching what competition exists and look at their feature sets. Combining this with our questionnaires and use cases, we can determine which features are most used in competing products, and tailor our improvement to these areas.

Of course, we'll also be having face-to-face meetings and e-mails with our client, but these three methods best reflected how we would obtain requirements which met the needs of both the primary stakeholder and the end user.

Non-Disclosure

Hey guys, I just found out that we will need to sign a non-disclosure and non-compete agreement. Not a big deal, just some red tape. I'll let you guys know when i find out more.

Requirements Elicitation

As a team we discussed and detailed 3 of our main elicitation techniques
Questionnaires
Use Cases
Study Similar Products

(See Activity 3.16.doc in the group locker)