Elicitation Notes - ReqEng-Analysis/Ashlynn_Glitz-Glitter_Boutique GitHub Wiki

General Techniques

Interviews: A "traditional" meeting where the stakeholder explains what they want in the product and the facilitator asks open-ended or clarifying questions. These are meant to be very interactive for the stakeholders where they are constantly being asked clarifying questions to clearly identify aspects of the product to be created.
Scenarios: A description of how the product would work under certain circumstances. This can be described as a step-by-step progression of what happens in a specific "scenario" of the product. There are different types of scenarios, like the sunny day scenario, which is what should happen if the product is used in the main way it is supposed to be used. There are also alternative paths, which do not necessarily imply that the product is being used incorrectly, it just means that there are other ways to use the product.
Prototypes: Prototypes are one of the most visual methods of elicitation. They typically include some type of wireframes or mockups of the product. These can be low-fidelity which is a high-level view of what the system may look like. They are quickly created and are mainly used to clarify that something that is being explained is understood clearly between different parties. This is compared to high fidelity where their prototypes are very close to what the final product should look like. At this point, most of the details have been ironed out by the stakeholders, and the stakeholders should have already seen many low and medium-fidelity prototypes that they have given their input on. Using prototypes allows for clearer communication between different stakeholders and the developers. Because these are visual it is easily communicated between parties.
Facilitated meetings: Facilitated meetings can be similar to focus groups where stakeholders can give their feedback on a product. This can give further direction to changes and improvements that should be made to the product. These can be difficult to facilitate as it matters which stakeholders take part in the meeting. These can be even more informational than traditional interviews since the stakeholders that take part in facilitated meetings are typically the primary users of the product.
Observation: Observations can be conducted by software engineers observing the environment and practices of the intended users of the system. Given a specific product, it may be vital for software engineers to observe the environment of the intended users of the product to get a better idea of how the product is going to be used. It also allows engineers to be more familiar with the terminology that is used in the proposed system. It also may be beneficial since engineers will be more understanding of what the product is being used for which will aid in the development of a more successful and specific product.
User stories: User stories are statements that are written from the perspective of the user to drive development. Because they are written from the perspective of the user, they allow for the production of the product to be focused on the user, which can be said to be the most important stakeholder. User stories can help the product stay within the scope of the problem statement and allow developers to stay focused on the purpose and goal of the system. User stories help developers have a clearer idea of the goal of the product.

Examples of Stakeholders

Below are a few of the typical stakeholders in software

Users: The group of individuals who interact with the system/product. The product is built for this group of individuals so it's important to keep them in mind throughout the entire software process.
Customers: The group of individuals who requested for the product to be created. They can also represent the target market of the proposed software.
Market analysts: This group of people analyzes some of the trends and tendencies of the target market in order to have a clearer idea of what the target market may look for in a product. Market Analysts are typically used when there was no direct customer who commissioned the product to be created, so it is up to the market analyst to gather clearer information on what users may want in a product.
Regulators: Specific business domains may have regulations or policies that they must follow for a variety of reasons, for example, government policies. Regulators are responsible for ensuring that the product complies with the related regulations and policies that are applicable.
Software Engineers: This group of individuals is responsible for creating and developing the product. They are also responsible for providing insight to the customers regarding the reality of the proposed product. Since it is a piece of software it is important that software engineers are active in the elicitation process to give an informed perspective of what they are capable of including in the product.

Identifying Stakeholders

Stakeholders are different for every project. Stakeholders consist of any individual who has an interest in the product. This includes but is not limited to, for example, users, developers, customers, clients, regulators, and individuals who are funding the project. In essence identification of stakeholders requires knowledge of the individuals who will have an influence on the product. Their influence will have a direct impact on how the product should be designed and the functionalities within the product. Knowledge and feedback from stakeholders can ensure that the right product is created. For example, having the knowledge that users, who are stakeholders, may have certain disabilities will directly affect some of the functionalities that will be implemented into the product.

Sources

Goals: Goals are concerned with the high-level objective of a product that is being created. It is important that stakeholders define a clear goal and refer back to said goal throughout the duration of the project.
Domain Knowledge: Domain knowledge specifies some of the terminology and environment that is needed to understand how the software should perform. This connects back to the elicitation method of conducting observations, as it will be easier to create a piece of software and research about a company given a mutual understanding of the domain in which the product is being used.
Stakeholders: It is important that a piece of software assess the different viewpoints of a piece of software. There are many stakeholders that are typically part of the process, so it is important to analyze each and weigh which input is more important to create a successful product. All stakeholders are important to some extent, so it is important to create a piece of software with these many perspectives in mind.
Business Rules: These can describe or create constraints for a piece of software. They provide direction in eliciting requirements and are important to include in this phase. Since it is a rule for the business it should also be a requirement for the piece of software.
The operational environment: This is concerned with the environment in which the product is being used. This can define some of the constraints and the functionality of the product. For example, time may need to be taken into consideration in certain domains, like software for first responders versus software for cashiers. It is important to assess the ease of use and the efficiency of the product in the operational environment.
The organizational environment: It is important to assess the current organization of the company while creating requirements. A piece of software should not require the business to change its organization, it is to be built for and around the current organization. The software should ensure that it is supporting the current processes of the businesses.

User Characteristics Page

https://github.com/ReqEng-Analysis/Ashlynn_Glitz-Glitter_Boutique/wiki/User-Characteristics