A key aspect of any successful project is understanding stakeholder needs. In software development, the analysis phase whether using formal requirements engineering as part of a prescriptive approach or working directly with stakeholders on an incremental basis as part of an agile approach.
For the class project, we are at the inception phase which has high risk because of the unknowns. Almost all SDLCs (including agile) suggest a methodological approach should be taken to determining project feasibility and eliciting requirements.
Project feasibility is about addressing major risk leading catastrophic failure of effort. Project feasibility considers internal and external factors to analysis and identify overall project risk, suggest methods to mitigate unknowns, make a "go" / "no go" recommendation of the project. Project feasibility is based on:
For the Class Project, can you determine project feasibility "as is" (based on current information)? If not what methods do you suggest to get to the point on making that "go" / "no go" recommendation? Feasibility should be addressed as part of your project plan.
After feasibility, we need to begin to identify the details of the system -- what are we expected to develop? Software developers during this analysis phase need to interact with stakeholders to elicit and validate project requirements. From a tactical sense, we can use a variety of different elicitation methods such:
The benefits and costs associated will each different method should be considered along with expected value of method in providing real requirements for this type of project. Our understanding of these factors should be part of the justification for the overall project plan.
For the Class Project, you need to develop how to get through inception and early elaboration for project. What is your proposal for efficiently gathering, validating, and managing the requirements of the project?
Also, remember that the Kano model and "blue ocean" thinking can raise the overall impact and value the project can have.
Last, we need to determine the form and expression of artifacts which may or may not be defined by SDLC approach take and how will they be managed to drive project development but avoid