Sign up to Coursera courses for free
In Elicitation: Artifact and Stakeholder Driven Analysis, you will learn to use both recorded and presently unrecorded knowledge in your elicitation techniques. As you get started in finding out about the new product, you must first learn about the product that was (if there was one) and then learn about the system to be. Oftentimes, you'll find yourself in an environment you know nothing about! This course will help you find ways to learn about the domain, the system that was, and the system to be. Please review: "Who this class is for to determine if you are ready to take this graduate level course".
Artifact Driven Elicitation
-One step of gathering domain knowledge and knowledge of the system that was and the system to be is through artifact-driven elicitation. Here we will discuss what artifact-driven elicitation entails, how to go about learning background from the stakeholders, and methods to obtain and deal with the data.
Storyboarding and Scenarios
-As you talk with customers early on, developing storyboards and scenarios help. They are easily communicable to both the customer and later to developers and work in all software development lifecycles. Mockups and prototypes can also be used- CAREFULLY. Here we explain these concepts along with their large benefits and dangers.
Reusing Existing Knowledge
-In understanding the system to be and the system that was, existing knowledge of the domain and current scenarios needed are helpful. These can be related back to models. This lesson discusses knowledge that can be obtained, from what resources, and how that can be mapped to existing models for help in further elicitation.
Interviewing- Learning from the Sources
-Knowledge of the system-as-is and the system-to-be can be obtained through interviews. While the concept of conducting an interview seems easy overall, an efficient and effective interview is challenging to conduct. Here we'll talk about guides to meeting effectiveness and guidelines for conducting a useful interview, specifically for determining what the stakeholder has and needs.