Getting requirements from stakeholders

From Computer Science Wiki
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, 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.

SL version[edit]

Method Definition Advantages Disadvantages
Surveys (questionnaires) A survey is a list of questions aimed at extracting specific data from a particular group of people [2] 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.
Interviews An interview is a conversation where questions are asked and answers are given. In common parlance, the word "interview" refers to a one-on-one conversation with one person acting in the role of the interviewer and the other in the role of the interviewee. The interviewer asks questions, the interviewee responds, with participants taking turns talking. Interviews usually involve a transfer of information from interviewee to interviewer, which is usually the primary purpose of the interview, although information transfers can happen in both directions simultaneously.[3] You can gather in-depth information and explore topics which are tangentially related to the system. There is flexibility in information You are usually limited to few people, not many people. If an interview isn't structured, you may get fragmented information. It can be harder to quantify requirements from an interview.
Direct observations Direct observation is a social research technique that involves the direct observation of phenomena in their natural setting. observational research tends to be less reliable but often more valid. The main advantage of observational research is flexibility. The researchers can change their approach as needed. Also it measures behavior directly, not reports of behavior or intentions. The problem with this approach is subjects may modify their behaviour when they know they are being watched. They portray their “ideal self” rather than their true self in what is called the Hawthorne Effect.[4]

HL version[edit]

In addition to the above material, you should understand the idea of senior user[5]. A senior user:

  • Uses a projects specialist products to realize their benefits
  • Operates, maintains or supports the project's outputs
  • Is otherwise impacted by a project's products

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.

Do you understand this material?[edit]

Please consider the following examples, and answer the questions:

Example 1[edit]

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 customer 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: Discuss the best methods to collect requirements from the different stakeholder groups. You should include rationale for your choices.

Do you have an advanced understanding of this material?[edit]

Example 2[edit]

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: Discuss the best methods to collect requirements from the different stakeholder groups. You should include rationale for your choices.

Standards[edit]

  • Identify the context for which a new system is planned. Level 2
  • Identify the relevant stakeholders when planning a new system. Level 2


References[edit]