Getting requirements from stakeholders: Difference between revisions

Latest revision as of 05:56, 8 January 2023

System Fundamentals^[1]

Understanding what your users want is very important. Your goal is to build software which meets the needs of users. There are different, complementary ways of gathering information from stakeholders. Different ways of collecting information can include surveys, interviews, and direct observations. There are other methods of gathering information but this is what you should minimally understand. You should understand each method for gathering requirements provides a different view (or lens, if you will) of client requirements. It is critical you understand the requirements prior to building a system.

Requirements[edit]

Method	Definition	Advantages	Disadvantages
Surveys (questionnaires)	Surveys can be used to gather input from a large number of stakeholders quickly and efficiently.	Are efficient: Surveys can be distributed to a large number of stakeholders quickly and easily, and the responses can be collected and analyzed automatically. Are cost-effective: Surveys are a relatively inexpensive method for gathering information compared to other methods such as interviews or focus groups. Allow anonymity: Surveys allow stakeholders to provide input anonymously, which can encourage honesty and openness. Can be completed at the respondent's convenience: Surveys do not require stakeholders to take time out of their busy schedules to meet with a facilitator, which can increase response rates.	May not provide sufficient detail: Surveys typically ask questions that can be answered briefly, which may not provide enough detail to fully understand the stakeholder's needs and requirements. Can be prone to bias: The way a question is phrased or the options provided in a survey can influence the response, leading to biased results. May have low response rates: Depending on the audience, surveys may have a low response rate, which can make it difficult to accurately represent the needs of all stakeholders. May not be suitable for all stakeholders: Some stakeholders may not be comfortable or able to complete a survey, in which case alternative methods may be necessary to gather their input.
Interviews	This involves one-on-one or small group meetings with stakeholders to gather information about their needs and expectations.	Allow for in-depth discussion: Interviews allow for a more in-depth and detailed exploration of a stakeholder's needs and requirements compared to methods such as surveys. Provide the opportunity to clarify and validate understanding: During an interview, a facilitator can ask follow-up questions and seek clarification to ensure that they fully understand the stakeholder's needs and requirements. Can build rapport and trust: Interviews allow for a more personal interaction between the facilitator and the stakeholder, which can help to build rapport and trust. This can be especially useful when working with stakeholders who are hesitant to share their needs and expectations. Can be tailored to the individual stakeholder: Interviews can be customized to the specific needs and preferences of the individual stakeholder, which can make them more engaging and effective at gathering information.	Can be time-consuming: Interviews can be time-consuming, especially if a large number of stakeholders need to be interviewed. Can be resource-intensive: Interviews require a facilitator to be present, which can be a resource-intensive process. May not be suitable for all stakeholders: Some stakeholders may not be comfortable or able to participate in an interview, in which case alternative methods may be necessary to gather their input.
Direct observations	Observing stakeholders as they perform their daily tasks can provide valuable insights into their needs and requirements.	Provides real-time insights: Observation allows the facilitator to see firsthand how stakeholders perform their tasks and interact with the current system or product, which can provide valuable insights into their needs and requirements. Allows for the gathering of context: Observation allows the facilitator to gather information about the environment in which stakeholders work, which can provide context for their needs and requirements. Can identify unanticipated needs: Observing stakeholders in their natural environment can reveal needs and requirements that may not have been identified through other methods such as interviews or surveys.	May be disruptive: Observation can be disruptive to the stakeholders being observed, which may affect their performance and the accuracy of the observations. Can be resource-intensive: Observation requires a facilitator to be present and actively observing, which can be a resource-intensive process. May not be suitable for all stakeholders: Some stakeholders may not be comfortable with being observed, in which case alternative methods may be necessary to gather their input. May be limited in scope: Observation can only provide insights into the specific tasks and processes being observed, which may not provide a complete picture of the stakeholder's needs and requirements.

Real-world practical advice[edit]

Make sure you are talking to the right people about system requirements. Many software projects have been doomed to fail because they were built on faulty requirements or poorly understood requirements. Also, a combination of the techniques are also usually most effective.

Standards[edit]

These standards are used from the IB Computer Science Subject Guide^[2]

Describe methods of obtaining requirements from stakeholders.

References[edit]

↑ http://www.flaticon.com/
↑ IB Diploma Programme Computer science guide (first examinations 2014). Cardiff, Wales, United Kingdom: International Baccalaureate Organization. January 2012.

[1] ttp://www.flaticon.com/

[2] IB Diploma Programme Computer science guide (first examinations 2014). Cardiff, Wales, United Kingdom: International Baccalaureate Organization. January 2012.

[1]

[2]

@@ Line 1: / Line 1: @@
 [[file:system_fund.png|right|frame|System Fundamentals<ref>http://www.flaticon.com/</ref>]]
-Understanding what your users want is very important. Your goal is to build software which meets the needs of users. There are different, complementary ways of gathering information from stakeholders.  Different ways of collecting information can include surveys, interviews, direct observations, prototyping, and RFP's. You should understand each method for gathering requirements provides a different view (or lens, if you will) of client requirements. It is critical you understand the requirements prior to building a system.
+Understanding what your users want is very important. Your goal is to build software which meets the needs of users. There are different, complementary ways of gathering information from stakeholders.  Different ways of collecting information can include surveys, interviews, and direct observations. There are other methods of gathering information but this is what you should minimally understand.  You should understand each method for gathering requirements provides a different view (or lens, if you will) of client requirements. It is critical you understand the requirements prior to building a system.
-=== SL version ===
+=== Requirements ===
 {| style="width: 95%;" class="wikitable"
@@ Line 9: / Line 9: @@
 | '''Method''' || '''Definition''' || '''Advantages''' || '''Disadvantages'''
 |-
-| '''Surveys (questionnaires)'''  ||  A survey is a list of questions aimed at extracting specific data from a particular group of people <ref>https://en.wikipedia.org/wiki/Survey_(human_research)</ref> || You can easily reach many people, good to reach people in remote locations || provides less information than direct contact or interviews. Interpreting the meaning of a question or answer can be difficult.
+| '''Surveys (questionnaires)'''  ||  Surveys can be used to gather input from a large number of stakeholders quickly and efficiently. ||
+# Are efficient: Surveys can be distributed to a large number of stakeholders quickly and easily, and the responses can be collected and analyzed automatically.
+# Are cost-effective: Surveys are a relatively inexpensive method for gathering information compared to other methods such as interviews or focus groups.
+# Allow anonymity: Surveys allow stakeholders to provide input anonymously, which can encourage honesty and openness.
+# Can be completed at the respondent's convenience: Surveys do not require stakeholders to take time out of their busy schedules to meet with a facilitator, which can increase response rates.
+ ||
+# May not provide sufficient detail: Surveys typically ask questions that can be answered briefly, which may not provide enough detail to fully understand the stakeholder's needs and requirements.
+# Can be prone to bias: The way a question is phrased or the options provided in a survey can influence the response, leading to biased results.
+# May have low response rates: Depending on the audience, surveys may have a low response rate, which can make it difficult to accurately represent the needs of all stakeholders.
+# May not be suitable for all stakeholders: Some stakeholders may not be comfortable or able to complete a survey, in which case alternative methods may be necessary to gather their input.
 |-
-| '''Interviews''' || define || a || d
+| '''Interviews''' ||  This involves one-on-one or small group meetings with stakeholders to gather information about their needs and expectations.  ||
+# Allow for in-depth discussion: Interviews allow for a more in-depth and detailed exploration of a stakeholder's needs and requirements compared to methods such as surveys.
+# Provide the opportunity to clarify and validate understanding: During an interview, a facilitator can ask follow-up questions and seek clarification to ensure that they fully understand the stakeholder's needs and requirements.
+# Can build rapport and trust: Interviews allow for a more personal interaction between the facilitator and the stakeholder, which can help to build rapport and trust. This can be especially useful when working with stakeholders who are hesitant to share their needs and expectations.
+# Can be tailored to the individual stakeholder: Interviews can be customized to the specific needs and preferences of the individual stakeholder, which can make them more engaging and effective at gathering information.
+||
+# Can be time-consuming: Interviews can be time-consuming, especially if a large number of stakeholders need to be interviewed.
+# Can be resource-intensive: Interviews require a facilitator to be present, which can be a resource-intensive process.
+# May not be suitable for all stakeholders: Some stakeholders may not be comfortable or able to participate in an interview, in which case alternative methods may be necessary to gather their input.
 |-
-| '''Direct observations''' || define || adv || disa
+| '''Direct observations''' || Observing stakeholders as they perform their daily tasks can provide valuable insights into their needs and requirements. ||
-|-
+# Provides real-time insights: Observation allows the facilitator to see firsthand how stakeholders perform their tasks and interact with the current system or product, which can provide valuable insights into their needs and requirements.
-| '''Prototyping''' || define || adv || disad
+# Allows for the gathering of context: Observation allows the facilitator to gather information about the environment in which stakeholders work, which can provide context for their needs and requirements.
-|-
+# Can identify unanticipated needs: Observing stakeholders in their natural environment can reveal needs and requirements that may not have been identified through other methods such as interviews or surveys.
-| '''RFP's''' || define || adv || disad
+||
+# May be disruptive: Observation can be disruptive to the stakeholders being observed, which may affect their performance and the accuracy of the observations.
+# Can be resource-intensive: Observation requires a facilitator to be present and actively observing, which can be a resource-intensive process.
+# May not be suitable for all stakeholders: Some stakeholders may not be comfortable with being observed, in which case alternative methods may be necessary to gather their input.
+# May be limited in scope: Observation can only provide insights into the specific tasks and processes being observed, which may not provide a complete picture of the stakeholder's needs and requirements.
 |}
-=== HL version ===
-In addition to the material above, you should know and understand it is helpful to think of a stakeholder as a customer. A customer is a person or organization that buys goods or services from a store or business<ref>New Oxford American Dictionary (Second Edition)</ref>
-There are two different types of customers:
-Internal customers: people inside the company who will be using the new system
-External customers people outside the company who will be using the new system
-The big idea here is there are many different types of stakeholders, and you need to carefully understand WHO might be using a system and WHAT ROLE they have interacting and using your system.
 == Real-world practical advice ==
-You should always be nervous when there is more than one person in charge of a project. We call this double-headed management, and it is very dangerous because you may get two very different specifications about the system. It is always a good idea to have '''only one''' single person who describes what a system should do. In project management, we call this a "senior customer" or a "senior user".
+Make sure you are talking to the right people about system requirements. Many software projects have been doomed to fail because they were built on faulty requirements or poorly understood requirements. Also, a combination of the techniques are also usually most effective.
-== Do you understand this material? ==
-Imagine you are the chief information officer for a company. The company wants to plan a system that keeps track of employees, their birthdays, salaries, and date the employee was hired. What are ten questions you would ask as you plan this system? It may be helpful to review [https://en.wikipedia.org/wiki/Context_analysis this wikipedia entry which discusses context analysis].
-Please consider the following examples, and answer the questions:
-=== Example 1 ===
-This is a simple example:
-A small business wants to plan a new system. The new system is a computer kiosk inside the store which allows customers to sign up for a email newsletter. If a custmer signs up for a newsletter inside the store, they will get a 10% discount on their first purchase at the store. The owner hopes this 10% discount will be an incentive for customers to sign up for the email newsletter.  The business will then regularly  email the customers special offers and savings. The business owner expects to benefit from this system by having increased sales. The customers expect to benefit from this system by having access to special offers, to save money, and to see what is new and trendy at their store.
-Question 1: List the stakeholders we should consult when planning this new system. Be careful, as there is a hidden stakeholder group that is not mentioned here!
-Question 2: Infer from the example what questions should be asked of each stakeholder group.
-== Do you have an advanced understanding of this material? ==
-=== Example 2 ===
-This is a complex example:
-A school of 900 students wants to plan a new system. The school hopes the new system is a secure web-based application which manages attendance data. The school administrators want to carefully track attendance for the students so it can identify when students have been absent for a customizable threshold. For example, the school might set a threshold of 5 absences within 30 days, which then automatically notifies the student, parent, and teacher there is a problem with attendance. The threshold might be 3 times within 10 days, or something like that. The system should keep track of attendance and tardies. The system should have customizable attendance codes. For example, "abscence for school trip", "excused abscence", "medical abscence" are all allowed abscence codes.
-School administrators expect to benefit by having data about attendance so they can support students and parents to be in school. School administrators also expect to benefit by giving parents and students information about attendance (so parents can support their children to be in school). Finally, school adinistrators expect to benefit by using attendance data to apply for government funding (as they can prove how many students were in class on a specific day).
-Parents expect to benefit by knowing when their children are in school or miss school. This way parents can support their children to be in school. Being in school is a '''shared value''' that the school hopes the parents share.
-Students expect to benefit by understanding how many days of school of they have missed. The school expects students to have a strong "ownership of learning" and manage their attendance.
-Question 1: List the stakeholders we should consult when planning this new system. Be careful, as there is a hidden stakeholder group that is not mentioned here!
-Question 2: Infer from the example what questions should be asked of each stakeholder group.
 == Standards ==
+These standards are used from the IB Computer Science Subject Guide<ref>IB Diploma Programme Computer science guide (first examinations 2014). Cardiff, Wales, United Kingdom: International Baccalaureate Organization. January 2012.</ref>
-* Identify the context for which a new system is planned. [[Level 2]]
+* Describe methods of obtaining requirements from stakeholders.
-* Identify the relevant stakeholders when planning a new system. [[Level 2]]
 == References ==