Information systems projects are created to solve a problem or optimize processes in the organization. Therefore, gathering requirements of what the new system should do and how it should work must be at the front of any decisions made by the system analyst when designing a new system or collecting information. All stakeholders should participate in providing input to the system analyst so he/she can make informed decisions on how the application should work. However, the final users are the most important part of the information system because if the system does not solve their problems or does not do what they expect, they won’t use it. There is where we see the resistance to change from users when they don’t feel part of the information system planning, and when they feel that all decisions were made without considering their points of view.
A requirement is a statement of what the system should do or what features are needed by the system (Dennis et al., 2012). The requirements for an information system are gathered by the requirements determination. The requirements determination is about transforming the system requests that are set at a high level into a detailed list of “must-have” items that the development team can add to the final system (Dennis et al., 2012). The following are methods and strategies for requirements determination and what are the conditions for selecting the methods listed.
Methods and Strategies for Determining Requirements
Most systems development failures are caused by poor planning, bad management of risks, little involvement of the users, and poor requirements determination (Stair & Reynolds, 2010). Therefore, requirements determination is one of the keystones for the success of a project. There are multiple methods and strategies for determining requirements for a new application. These are five popular methods that are used in most information system requirement determination: interviews, joint application design, focus groups, prototyping, and observation.
Interviews
Interviews are one of the most common ways to gather requirements from the stakeholders. The interviews are usually conducted one-on-one with an interviewer and an interviewee that goes over questions about the system needed and the requirements that will satisfy the users’ needs (Dennis et al., 2015). An interview is a scheduled and planned meeting that is used to obtain information from another person (Rosenblatt & Shelly, 2014). It is necessary to have the skills to plan, conduct, document, and evaluate interviews to gain insights for system design (Rosenblatt & Shelly, 2014).
Even though interviews might be the most popular method for requirements determination, it is not easy and requires a lot of planning. Five steps in the interview process need to be done for a proper interview. The steps are selecting interviewees, preparing interview questions, preparing the interview, performing the interview, and the interview follow-up (Dennis et al., 2015).
When selecting interviewees, it is necessary to have the right people for the interview. A preliminary investigation needs to be done to find the right people to interview. For instance, it is important to talk mainly to middle managers and heads of departments (Rosenblatt & Shelly, 2014) to have an idea of the overall requirements of the system and what type of users will be working with the application daily.
The next step is preparing the interview question by establishing the objectives of the interview (Rosenblatt & Shelly, 2014). Then, create a standard list of interview questions so the same questions can be asked to users that will be doing the same work. Therefore, we can compare different answers and the similarities between users (Rosenblatt & Shelly, 2014). The questions could be closed-ended or open-ended. But, open-ended questions allow the interviewees to elaborate more and provide more information when they answer questions (Dennis et al., 2015).
The third step in the interview process is preparing for the interview. In this step, the interviewer should prepare a general plan listing the questions and follow-up questions that will be asked in order in anticipation of possible answers from the interviewees (Dennis et al., 2015).
The fourth step is conducting the interview. One goal of conducting the interview is to build a relationship with the interviewee so the person answering the questions is willing to tell the whole truth instead of telling us what they think we want to hear (Dennis et al., 2015). Also, it is necessary to let the interviewees know that they are not being tested or evaluated, that there are no right/wrong answers; and that the point of the interview is to learn more about the system and what needs to be done.
The last step in the process is the post-interview follow-up. Therefore, after the interview is over and the information is gathered, the interviewer might have some follow-up questions for clarification on some of the topics covered in the interview (Dennis et al., 2015). In addition, the follow-up questions need to be asked as soon as possible before the interviewee forgets the information presented during the interview (Dennis et al., 2015).
The benefit of using interviews is that they are easy to organize however they are time-consuming when reconciling discrepancies (Podeswa, 2005).
Joint Application Design
The Joint Application Design/Development or JAD is a technique for project teams, users, and management to work together to identify the requirements of the system (Dennis et al., 2015). This is a popular technique for gathering requirements because the users are active participants in the process (Rosenblatt & Shelly, 2014). Users should participate in the process because they have a vital stake in the system and they are the ones that will use or reject the system once it is completed (Rosenblatt & Shelly, 2014).
JAD is about three to five days of workshops that gather business people, users, and IS professionals under one facilitator to define high-level strategic plans to detailed system specifications (Langer, 2008). In addition, JAD sessions are great tools for political situations where getting consensus from stakeholders is very challenging (Langer, 2008).
The participants of JAD sessions are a JAD session leader, users, sponsors, managers, systems analysts, scribes, and information systems professionals (staff). The session leader is the person that organizes the JAD sessions (Valacich & George, 2021). The leader has experience or is a trained professional in group management and has knowledge of information systems analysis (Valacich & George, 2021). The users are the ones that will be working directly with the system once it is in production and have a clear understanding of what the system should do (Valacich & George, 2021). The managers of the people that will be using the system will provide business insights and expectations from the system (Dixit, 2007). The sponsors are the ones that are positioned relatively high in the company that support the development of the project (Dixit, 2007). But, sponsors are not required for the workshop. If they are present, they have passive participation (Dixit, 2007). The scribe takes notes during the JAD sessions and the notes could be done using diagrams using a CASE tool (Dixit, 2007). The system analysts are the members of the systems analysis team that are there to learn more from users and managers and should avoid dominating the session (Dixit, 2007). Then, there is an IS staff that is not exactly part of the system analyst team but there are specialists in some areas of Information Technology like database designers, database administrators, programmers, and others (Valacich & George, 2021).
JAD has several advantages including easier reconciling of discrepancies and reduced analysis time (Podeswa, 2005). Nevertheless, it is difficult to gather all the stakeholders at the same time in one room because of conflicts in schedules (Podeswa, 2005).
Focus Groups
Focus groups are close to JAD workshops but the group is advising and providing ideas instead of making final decisions about the project (Jonasson, 2012). They can be seen as a combination of the JAD workshops and interviews as it is used only with final users and not with any other type of stakeholders. For instance, focus groups are popular when creating new products with a large user base to discover what features are important for the users (Jonasson, 2012).
The questions asked in focus groups are open-ended questions to gather more information and encourage communication between participants (Gottesdiener, 2005). Also, there is one moderator and the group consists of six to twelve people that belong to the same demographics (Gottesdiener, 2005).
Prototyping
Prototyping is another unobtrusive method of determining user requirements that gathers users’ feedback by presenting a rough version of the system so the users can react to it and the analyst takes notes (Kendall & Kendall, 2014). Based to the book Systems Analysis and Design, there are four types of prototypes: patched-up, nonoperational, firs-of-a-series, and selected features (Kendall & Kendall, 2014).
The patched-up is a functional prototype but it is created as patched-up or patched together (Kendall & Kendall, 2014). It is a system that has all the features of the requirements but it is not efficient in terms of speed or design as it is put together fast to get feedback from the users (Kendall & Kendall, 2014).
The nonoperational prototype is a nonworking design or model that is set up to test areas of the application in terms of design (Kendall & Kendall, 2014). The system might be seen as a full-scale design but behind the scenes, there is nothing operational (Kendall & Kendall, 2014).
The next prototype is the first of a series that is about creating a functional prototype called a pilot that will help guide the design based on continuous feedback from users by creating subsequent prototypes during the development phase (Kendall & Kendall, 2014).
The fourth prototype is the selected features one which works by building an operational model of the application that includes some of the final features but not all (Kendall & Kendall, 2014). Only the essential features are included in this prototype, allowing user feedback to help the analyst understand the users (Kendall & Kendall, 2014).
Job Shadowing or Observation
Observations or job shadowing are visits to the workplace by information systems analysts to see the workers perform their jobs (Gottesdiener, 2005). Observations can be done in two ways: active or passive. The active way is interacting directly with the user in their environment performing the task while the passive is done via video recordings or a one-way mirror without communicating or asking questions to the users (Jonasson, 2012). The observations are important while gathering requirements because they can uncover issues in the workplace that could affect the requirements (Gottesdiener, 2005) and they provide context to the requirements when analysts and developers are talking about those tasks to be performed. In addition, some users might not be aware or cannot explain correctly what they do and how they do it so observing the users in their environment could answer questions and give context to analysts (Soren Lauesen, 2002).
Selecting an approach
As previously mentioned, requirements determination is vital for an information system that solves users’ needs and is aligned with the organizational goals. The process of selecting an information systems requirements determination depends on two factors: the involvement of the users and the software development methodology. If the users are available to answer questions and provide feedback, methods that are closely related to gathering information directly from the users could be used. For instance, interviews, focus groups, and JAD sessions could be used. However, if the users are not available, requirements could be gathered using alternative methods like reading documentation, passive observation, and business process reengineering.
If the software development methodology is an agile one, then it is expected continual user involvement in the creation of the application by testing new versions and providing feedback (Valacich & George, 2021).
Conclusion
In conclusion, requirements determination for information systems is an important part of the analysis phase of the software development lifecycle. If the system analyst does not have a plan to collect the requirements of the project by listening to the users, there are few chances that the system will solve their problems or be aligned to the vision of the company. In addition, the analyst should have a process for selecting the method system requirements that will be depending on the type of software methodology and the availability of the stakeholders to participate in the development or design of the application.
References
Dennis, A., Barbara Haley Wixom, David Paul Tegarden, & Seeman, E. (2015). System Analysis & Design: An Object-Oriented Approach with UML (5th ed.). Wiley.
Dennis, A., Roth, R. M., & Wixom, B. H. (2012). System analysis and design (5th ed.). John Wiley.
Dixit, J. B. (2007). Structured System Analysis and Design. Laxmi Publications.
Gottesdiener, E. (2005). The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements (1st ed.). Goal/Qpc.
Jonasson, H. (2012). Determining Project Requirements: Mastering the BABOK and the CBAP Exam. Crc Press.
Kendall, K. E., & Kendall, J. E. (2014). Systems Analysis and Design (9th ed.). Pearson Education.
Langer, A. M. (2008). Analysis and Design of Information Systems. Springer.
Podeswa, H. (2005). UML for the IT Business Analyst: A Practical Guide to Object-Oriented Requirements Gathering. Thomson Course Technology Ptr.
Rosenblatt, H. J., & Shelly, G. B. (2014). Systems Analysis and Design (10th ed.). Course Technology/Cengage Learning.
Soren Lauesen. (2002). Software Requirements: Styles and Techniques. Pearson Education.
Stair, R. M., & Reynolds, G. W. (2010). Principles of Information Systems: A Managerial Approach (9th ed.). Course Technology Cengage Learning.
Valacich, J. S., & George, J. F. (2021). Modern Systems Analysis And Design (9th ed.). Pearson Education Limited.
