Preview Extract
Chapter 2 - Investigating System Requirements Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases Instructor's Notes (for each section) Key Terms Lecture notes Quick quizzes Classroom Activities Troubleshooting Tips Discussion Questions Chapter Overview In Chapter 1 we presented a complete example of one iteration of a development project. We also introduced the six core processes of the SDLC. In this chapter we focus on the third core process: "Discover and understand the details of the problem and the need." (Since we are teaching SA&D by example and by hands-on, we move immediately into the analysis tasks of investigating and understanding the user’s needs, e.g. the requirements. Later in Chapters 10 and 11 we return to core processes 1 and 2 to teach about project management.) Since we will be using Ridgeline Mountain Outfitters (RMO) as a running case example throughout the book, we first present the detail background information on RMO. Each of the six core processes has several detailed activities. These detailed activities are the activities that are done by system developers in order to execute a core process. Immediately after the description of RMO, the chapter presents the detailed activities for Core Process 3 and explains them in detail. Another major topic in this chapter is a definition and discussion of requirements, including information gathering techniques, and how requirements are captured by building models. The next topic is a discussion on stakeholders - who they are and how to gather information, e.g. requirements, from them. Finally the chapter ends with instructions on how to use UML activity diagrams to document user workflows. This chapter is an important chapter with key concepts to help the students understand the need and importance of system analysis and how to gather user requirements.
Learning Objectives After reading this chapter, the student should be able to: Describe the activities of systems analysis Explain the difference between functional and nonfunctional requirements Identify and understand different kinds of stakeholders and their contributions to requirements definition Describe information-gathering techniques and determine when each is best applied Describe the role of models and UML in systems analysis Develop UML activity diagrams to model workflows Notes on Opening Case and EOC Cases Opening Case Mountain Vista Motorcycles (MVM): This case highlights the need to understand the business context for which the system is going to be built. In this case MVM would like to have a Internet presence that is attractive and engaging for its clientele. The problem, of course, is to understand its clientele and what kind of Web presence would most beneficial. Without understanding its clientele, MVM could easily build a system that is ineffective, or even worse is one that alienates or bores its clients. In this case, the normal role of the systems analyst needs to be expanded to help the user understand new technology and how it can be used to enhance and expand MVM's Web presence. As in many new system development endeavors analysts and users must work together as a team to determine what system capabilities are needed to best fit the business need. EOC Cases Starting with this chapter there will be a chapter specific case and four running cases. The running cases go throughout the rest of the book, e.g. for each chapter. John and Jacob, Inc.: Online Trading System: This end-of-chapter case describes the process of identifying the people that should be included in system requirements development. The project manager has some uncertainties and issues that need to be resolved in order to be inclusive. Most of the issues concern how to select users, customers, and other stakeholders to assist in defining system requirements. Community Board of Realtors (running case): Community Board of Realtors is a professional organization that supports real estate offices and agents. The system to be designed will provide information on real estate listings. It will also maintain data on the agents themselves. For this chapter the student is asked to identify stakeholders and information requirements. Spring Breaks 'R' Us Travel Services (SBRU) (running case): SBRU is an online travel services that books spring break trips to resorts for college students. This is a rich case that has multiple users including both students and resorts. Resorts will use the system to post vacation specials and vacancies. Students will use the system to make reservations. The system will also contain a social networking component to allow students to connect with each other during the spring break vacation. Students are asked to identify stakeholders, define functional requirements, consider security issues, and identify methods to define user requirements. On the Spot Courier Services (running case): On the Spot is a small, but growing, courier service that needs to track customers, package pickups, package deliveries, and delivery routes. The system will require real time update of pickups and deliveries with mobile devices. It will also allow the customers to schedule their own pickups via a Web based interface. In this chapter the students are asked to define the stakeholders, determine methods to elicit requirements, consider communication needs, and identify the major functions of the new system. Sandia Medical Devices (running case): Sandia Medical Devices is a company that specializes in medical monitoring through remote, mobile telecommunication devices. One of the primary devices is a portable and wearable glucose monitor embedded in a wristband which transmits results to a medical center real time. This case will have telecommunications requirements for mobile devices as well as Web interfaces and home office administrative functions. In this chapter the students are asked to define the stakeholders, determine how to elicit requirements, identify some functional and nonfunctional requirements. Instructor's Notes (for each section) The RMO Consolidated Sales and Marketing System Project Key Terms technology architecture – a set of computing hardware, network hardware and topology, and system software employed by an organization application architecture – the organization and construction of software resources to implement an organization’s information systems Lecture Notes Existing RMO Information Systems and Architecture At present, RMO has a disparate collection of computers dispersed across home offices, retail stores, telephone centers, order fulfillment/shipping centers, and warehouses—everything connected by a complex set of local area networks (LANs), wide area networks (WANs), and virtual private networks (VPNs). RMO’s technology architecture is modern but not state of the art. The term application architecture describes how software resources are organized and constructed to implement an organization’s information systems. Currently, the major RMO systems include: Supply Chain Management (SCM) – five year old system in Java and Oracle. Supports purchasing, distribution, and inventory control. The new Tradeshow system will interface with it. Phone/Mail Order System – twelve year old system in Visual Studio and Microsoft SQL Server. It is at capacity. Retail Store System (RSS) – a retail store package purchased by RMO. Does point of sale and a real-time inventory update. Customer Support System (CSS) – fifteen year old system, with upgrades eleven years ago. Web-based catalog and Internet storefront with shopping cart. Current problems with sales systems includes: Treating phone, Web, and retail sales as separate systems rather than as an integrated whole Employing outdated Web-based storefront technology Not supporting modern technologies and customer interaction modes, including mobile computing devices and social networking RMO plans to replace the three customer order, retail, and support systems with a new Consolidate Sales and Marketing System (CSMS). The New Consolidated Sales and Marketing System (CSMS) The new CSMS system will consist of four subsystems: The Sales subsystem provides such basic functions as searching the online catalog and purchasing items and paying for them online. The Order Fulfillment subsystem will perform all the normal tasks of shipping items and allowing customers to track the status of their orders as well as the shipments. The Customer Account subsystem provides all those services that enhance the customer experience. The Marketing subsystem is for employees to set up the information and services for customers, including information about all the merchandise offered by RMO. Systems Analysis Activities Lecture Notes Figure 2-2 illustrates the five systems analysis activities that make up core process three. This core process also goes by the name systems analysis. By completing these activities, the analyst defines in great detail what the information system needs to accomplish to provide the organization with the desired benefits. In essence, analysis activities are a second and more thorough pass at defining the problem and need. The first pass was done to create the System Vision Document. Gather Detailed Information Beginning analysts often underestimate how much there is to learn about the work the user performs. The analyst must become an expert in the business area the system will support. Systems analysts obtain information from people who will be using the system, either by interviewing them or by watching them work. They obtain additional information by reviewing planning documents and policy statements. Analysts also study existing systems, including their documentation. They also frequently obtain additional information by looking at what other companies (particularly vendors) have done when faced with a similar business need. Define Requirements System requirements include the functions the system must perform (functional requirements) and such related issues as user interface formats and requirements for reliability, performance, and security (nonfunctional requirements). As the analyst gathers information, he or she will use that information to create models that express the user's needs in terms of precise processing requirements. Building and refining requirements models occupies much of the analyst’s time. Prioritize Requirements Once the system requirements are well understood, it is important to establish which requirements are most crucial for the system. It is important to prioritize requirements because resources are always limited, and the analyst must always be prepared to justify the scope of the system. Therefore, it is important to know what is absolutely required. Unless the analyst carefully evaluates priorities, system requirements tend to expand as users make more suggestions (a phenomenon called scope creep). Requirements priorities also help to determine the number, composition, and ordering of project iterations. Develop User-Interface Dialogs Such requirements models as use cases, activity diagrams, and interaction diagrams can be developed based on user input, but it is often difficult for users to interpret and validate such abstract models. In contrast, user validation of an interface is much simpler and more reliable because the user can see and feel the system. To most users, the user interface is all that matters. Thus, developing user-interface dialogs is a powerful method of eliciting and documenting requirements. Evaluate Requirements with Users Whether it is building models or creating user-interface dialogs, the requirements must be validated by the user to insure that the new system does, in fact, meet the business need. Analysts usually use an iterative process in which they elicit user input, work alone to model requirements or create dialogs, return to the user for additional input or validation, and then work alone to incorporate the new input and refine the models. Quick Quiz Q: What is another, more common, name given to Core Process Three? A: Systems Analysis Q: What are the five activities that comprise core process three? A: Gather detailed information, Define requirements, Prioritize requirements, Develop user-interface dialogs, and Evaluate requirements with users. Q: How are these activities different than the problem definition and business need that was used to develop the System Vision Document that we learned about in Chapter 1? A: This is a second pass through the requirements at a much more detailed level. Instead of just identifying the business needs, during the core process three the analyst must understand in detail all of the processing requirements of each users work tasks. What Are Requirements? Key Terms system requirements – the activities a system must perform or support and the constraints that the system must meet functional requirements – the activities that the system must perform nonfunctional requirements – system characteristics other than the activities it must perform or support FURPS – an acronym that stands for functional, usability, reliability, performance, and security requirements usability requirements – operational characteristics related to users, such as the user interface, related work procedures, online help, and documentation reliability requirements – requirements that describe system dependability performance requirements – operational characteristics related to measures of workload, such as throughput and response time security requirements – requirements that describe how access to the application will be controlled and how data will be protected during storage and transmission FURPS+ – an extension of FURPS that includes design constraints as well as implementation, interface, physical, and supportability requirements design constraints – restrictions to which the hardware and software must adhere implementation requirements – constraints such as required programming languages and tools, documentation method and level of detail, and a specific communication protocol for distributed components interface requirements – required interactions among systems physical requirements – characteristics of hardware such as size, weight, power consumption, and operating conditions supportability requirements – how a system is installed, configured, monitored, and updated Lecture Notes System requirements are all the activities the new system must perform or support and the constraints that the new system must meet. Generally, analysts divide system requirements into two categories: functional and nonfunctional requirements. In this section we use the FURPS+ model to categorize system requirements. Figure 2-3 defines the meanings of the elements of the FURPS+ acronym. They are: Functions Usability Reliability Performance Security + Design constraints Implementation Interface Physical Support Note: Probably the best way to teach this material is using the FURPS+ model and review each definition in the key term list. Quick Quiz Q: What does FURPS+ stand for? A: See above. Q: What is the difference between functional and nonfunctional requirements? A: Functional are those things that the system must do, e.g. the business functions or processes. Nonfunctional are all the other constraints on the system such as performance, reliability, and security. The system must meet both types of requirements to be an effective productive system. Stakeholders Key Terms Stakeholders – persons who have an interest in the successful implementation of the system internal stakeholders – persons within the organization who interact with the system or have a significant interest in its operation or success external stakeholders – persons outside the organization’s control and influence who interact with the system or have a significant interest in its operation or success operational stakeholders – persons who regularly interact with a system in the course of their jobs or lives executive stakeholders – persons who don’t interact directly with the system but who either use information produced by the system or have a significant financial or other interest in its operation and success client – person or group that provides the funding for a system development project Lecture Notes Stakeholders are your primary source of information for system requirements. Stakeholders are all the people who have an interest in the successful implementation of the system. One useful way to help identify all the interested stakeholders is to consider two characteristics by which they vary: internal stakeholders versus external stakeholders and operational stakeholders versus executive stakeholders. Figure 2-4 illustrates an example of the stakeholders for an accounting system. Two other types of stakeholders not categorized by internal/external or operational/executive are the clients and the technical staff. The client may not use the system directly, but he or she is the one who pays for the system. In that sense, the new system must meet the client's objectives and reasons for funding the project. The technical staff are stakeholders because they also have oversight responsibility to ensure that the new system meets all the operational criteria for the organization. The Stakeholders at RMO The following list of types of stakeholders can be used by the development team to help identify individual stakeholders: Phone/mail sales order clerks Warehouse and shipping personnel Marketing personnel who maintain online catalog information Marketing, sales, accounting, and financial managers Senior executives Customers External shippers (e.g., UPS and FedEx) Analysis of each of these categories will identify the individuals that have an interest in the deployment and utility of the new system. However, the analysis should be comprehensive and not too narrow. For example customers could include existing as well as potential customers. Quick Quiz Q: What is the difference between internal and external stakeholders? A: Internal stakeholders exist within the organization using the system. External stakeholders, such as customers, use the system, but are not part of the organization per se. Q: What is the difference between operational and executive stakeholders? A: Operational stakeholders use the system to carry out the business processes and functions. Executive stakeholders might require information and reports about the data within the system, but not not use the system for business functions. Q: Why is the technical staff considered a stakeholder? A: They have a keen interest in the development and use of the system because they have responsibility to ensure that the system functions properly within the context of the organization. Information-Gathering Techniques Key Terms open-ended questions – questions that encourage discussion or explanation closed-ended questions – questions that elicit specific facts Lecture Notes One of the most important skills that a systems analyst can develop is the ability to gather the right information so that the new system requirements are accurate and complete. There are several methods that can be used to gather information, some are more effective and efficient than others. The most common methods are the following: Interviewing users and other stakeholders Distributing and collecting questionnaires Reviewing inputs, outputs, and documentation Observing and documenting business procedures Researching vendor solutions Collecting active user comments and suggestions Interviewing users and other stakeholders This is the most frequently used method because it is the most information rich. However, it is also the most time consuming. There are five steps that analysts usually do: Prepare detailed questions Meet with individuals or groups of users Obtain and discuss answers to the questions Document the answers Follow up as needed in future meetings or interviews When analysts are preparing questions, they should consider three themes. Question Themes: What Are the Business Processes? In the first question—What do you do?—the focus is on understanding the business functions. In most cases, the users will provide answers in terms of the current system. As an analyst, you must carefully discern which of those functions are fundamental business functions, which will remain, and which may possibly be eliminated with an improved system. How is the Business Process Performed? The second question—How can it be done?—moves the discussion from the current system to the new system. The focus is on how the new system should support the function rather than on how it is performed under the existing system. Thus, the first two questions go hand-in-hand to discover the need and begin the definition of the system requirements in terms of the new system. What Information is Required? The final question—What information is needed?—defines specific information that the new system must provide. The answers to the second and third questions form the basis for the definition of the system requirements. If when the analyst focuses the investigation around these three themes, he will be able to ask intelligent, meaningful questions in his investigation. Question Types: Questions can be either open-ended, which allow the stakeholder to discuss and explain, or closed-ended, which are useful for getting specific facts and numbers. Focus of Questions—Current System or New?: A difficult issue in interviewing users and other stakeholders is whether to focus the questions around the existing system or to emphasize only the new system. Each project is different, and analysts must use good judgment on how much time to spend on the old system. Analysts should remember that the only utility in reviewing existing systems, to ensure that correct requirements are obtained for the new system. So if the new system duplicates many of the extant business processes, then those processes should be reviewed. Interview Preparation, Conduct, and Follow-Up: An interview with a user or stakeholder requires planning and preparation. Without proper preparation, the interview can waste valuable time and can even fail to discover important information. Preparing for the interview: Every successful interview requires preparation. The first and most important step in preparing for an interview is to establish the objective of the interview. The second step is to determine which users should be involved in the interview. The third step is to prepare detailed questions to be used in the interview. The last step is to make the final interview arrangements and to communicate those arrangements to all participants. Conducting the interview: New systems analysts are usually quite nervous about conducting interviews. However, in most cases, the users are excited about getting a better system to help them do their jobs. Practicing good manners usually ensures that the interview will go well. Here are a few guidelines: Dress appropriately. Arrive on time. Limit the time of the interview. Look for exception and error conditions. Probe for details. Take careful notes. Following up the interview: Analysts often document the details of the interview by constructing models of the business processes. Review your findings with the other project members in the interview and document the results (that is, build the models) within a day or two to avoid forgetting important details. Distributing and Collect Questionnaires Questionnaires enable analysts to collect information from a large number of stakeholders. Questionnaires are often used to obtain preliminary insight into stakeholder information needs, which helps to determine areas that need further research by using other methods. However, questionnaires are not well suited to helping you learn about processes, workflows, or techniques. Review Inputs, Outputs, and Procedures There are two sources of information about inputs, outputs, and procedures. One source is external to the organization—industry-wide professional organizations and other companies. The project team would be negligent in its duties if its members were not familiar with best practice information. The second source of inputs, outputs, and procedures is existing business documents and procedure descriptions within the organization. Observe and Document Business Procedures Firsthand experience is invaluable to understand exactly what occurs within business processes. More than any other activity, observing a business process in action will help analysts understand the business functions. However, there is a danger that the user and analyst will decide to re-implement the existing process instead of moving to a newer and more advanced approach. Research Vendor Solutions Many of the problems and opportunities that companies want to address with new information systems have already been solved by other companies. Researching existing solutions will frequently help users generate new ideas for how to better perform their business functions. Frequently these solutions from vendors are excellent and state of the art. It is also usually cheaper to purchase a solution than to build one from scratch. However, there is always a danger of buying something that does not quite fit the needs of the business. Care should be taken when purchasing a solution. Collect Active User Comments and Suggestions User feedback from initial and later testing is a valuable source of requirements information. Interviews, discussions, and model reviews are an imperfect way of eliciting complete and accurate requirements. The phrase “I’ll know it when I see it” applies well to requirements definition. Users often cannot completely or accurately state their requirements until they can interact with a live system that implements those requirements. Quick Quiz Q: What are the three question themes that analyst should use to develop interview questions? Why are these themes important? A: What are the business operations and processes? The purpose of the first theme is to identify the various business processes that must be supported in the new system. How should those operations be performed? The purpose of the second theme is to understand the details of the business process in the context of a new system. What information is needed to perform the operation? The purpose of the third theme is directly tied to the development of the new system, and what information it must maintain and provide. Q: List two or three effective methods to gather information. A: Interviewing users and other stakeholders, Distributing and collecting questionnaires, Reviewing inputs, outputs, and documentation, Observing and documenting business procedures, Researching vendor solutions, Collecting active user comments and suggestions Q: What is the purpose of an activity diagram? A: An activity diagram is used to document the detailed steps of a business process or workflow. A workflow is a sequence of processing steps necessary to completely handle one business transaction or customer request. Models and Modeling Key Terms model – representation of some aspect of a system textual models – text-based system models such as memos, reports, narratives, and lists graphical models – system models that use pictures and other graphical elements mathematical models – system models that describes requirements numerically or as mathematical expressions Unified Modeling Language (UML) – standard set of model constructs and notations defined by the Object Management Group Lecture Notes A model is a representation of some aspect of the system being built, and the analyst needs to create a variety of models to represent all aspects of the system. Some models are high-level overviews; some are detailed views; some focus on one aspect of the system, such as inputs, processes, outputs, or data storage; some show how the other models fit together; and some show the same problem from a different perspective. Models and the process of creating models are important to system development for the following reasons: Learning from the modeling process Reducing complexity by abstraction Remembering all of the details Communicating with other development team members Communicating with a variety of users and stakeholders Documenting what was done for future maintenance/enhancement Frequently students will disparage the need to build models. However, the modeling process is frequently the only way that the analyst really comes to understand the user requirements and to think through all of the “what if” processing options. Without building models, analysts seldom dig deep enough to really understand the requirements. Analysis and design models can be grouped into three generic types: Textual models—Analysts use such textual models as memos, reports, narratives, and lists to describe requirements that are detailed and are difficult to represent in other ways. Graphical models—Graphical models make it easier to understand complex relationships that are difficult to follow when described as a list or narrative. Many graphical models used in system development are drawn according to the notation specified by the Unified Modeling Language (UML). Mathematical models—Mathematical models are one or more formulas that describe technical aspects of a system. Also in an Agile project, often models are quickly built, used for one of the above reasons, such as to document some decisions or details, and then discarded after they are used to write program code. However, even in an Agile project, it may be necessary to keep the documentation and models in order to verify decisions that were made. Today's object-oriented development most frequently uses the Unified Modeling Language (UML) to build the models necessary for system development. All the diagrams in this textbook conform to UML 2.0 specifications. Quick Quiz Q: What are the primary of the reasons for creating models during systems development? A: Learning from the modeling process, reducing complexity by abstraction, remembering all of the details, communication with team members and stakeholders. Q: What are three types of models? A: Graphical models, textual models, and mathematical models. Q: Name several (four or five) UML models. A: Use case diagram, class diagram, sequence diagram, communication diagram, activity diagram, and state machine diagram. Documenting Workflows with Activity Diagrams Key Terms Workflow – sequence of processing steps that completely handles one business transaction or customer request activity diagram – describes user (or system) activities, the person who does each activity, and the sequential flow of these activities synchronization bar – activity diagram component that either splits a control path into multiple concurrent paths or recombines concurrent paths swimlane – heading activity diagram column containing all activities for a single agent or organizational unit Lecture Notes As mentioned earlier, through the process of building models an analyst not only documents a business process or workflow, but he/she also will come to understand the workflow in more depth. UML activity diagrams provide a simple technique to document business workflows. The key terms define each element of an activity diagram. Figure 2-14 provides a visual elements that are used on an activity diagram. Creating activity diagrams to document workflows is straightforward. The first step is to identify the agents to create the appropriate swimlanes. Next, follow the various steps of the workflow and then make appropriate ovals for the activities. Usually there is a swimlane for the actor or user of the system, and another swimlane for the actions done by the system. Use a decision symbol to represent an either/or situation—one path or the other path but not both. Use synchronization bars for parallel paths—situations in which both paths are taken. Include a beginning and an ending synchronization bar. Quick Quiz Q: List at least three components that are used to draw an activity diagram. A: Swimlane, Activity Oval, Transition Arrow, Synchronization bar, Decision activity Classroom Activities Most of the concepts in this chapter are logical and common sense. There are, however, three areas that need to strengthened before students really understand. The first is the importance of building models. Often students do not understand the need to build models. Start driving this idea home in this chapter and then more in the following chapters. A good activity is to have a set of house plans, or a schematic of an electrical circuit. Can the builder build the house without house plans? Obviously not. Another area is the need to ask probing questions during the interview process. A good activity here is to take a case and give it to one team of students and have them read it and understand it. Then have another team of students interview them to determine some set of requirements. It is good if you have a case with some fairly detailed components – especially some exception conditions. Then after the interview have the first team grade the second team on how well they did. This is usually a good exercise to show the importance of going deep with probing questions to really understand the user's needs. Most beginners are very superficial in their approach and in their questions. One other critically important skill and area of learning in this chapter is the ability to develop an activity diagram. As explained in the chapter, the process of modeling helps analysts (and especially novices) understand the business process. Building an activity diagram in class can also help solidify the previous two points. By actually creating a model, students can learn how helpful a model can be to understand a process. And if they first must ask questions to find out the information and then build the model, all three objectives can be achieved with a single in-class exercise. For example, a typical process might be to document the business process of buying a laptop computer from the campus bookstore. The process can be made more interesting by identifying exception conditions such as the students credit is no good, or maybe even something as simple as selling a demo model (which may require a special warranty or no warranty). If time allows, a couple of solutions could be review with a structured walk-through to show the process of validating and correcting the models. Many of the important concepts in this chapter can be taught very effectively with in-class exercises as explained above. Troubleshooting Tips As mentioned above, the two primary areas that students have difficulty in this chapter is the skill of learning to interview well, in particular to probe deeply to really understand the issues. Even experienced analysts often do not ask enough “what if” questions to determine all of the exception conditions. The most effective way for students to learn this skill is by practicing – especially practicing and then getting feedback about all the information that they missed. The other area where students will need help is in developing activity diagrams. The basic skill is not too difficult, but knowing how detailed to make the action steps, i.e. the ovals, is sometimes a problem. Whether to say, "enter your name" then "enter your address" etc. or to just say "enter client information" is the issue. The answer is generally to enter a complete form full of data is sufficient. In learning about activity diagrams, students will often get synchronization bar and the decision activity confused. It sometimes helps to say use the following analogies. Synchronization bar = AND condition, multitasking, concurrent threads Decision Activity = OR condition, single thread (non-active thread dies) Discussion Questions 1. Functional Requirements and Nonfunctional Requirements The development team is expected to determine both functional and nonfunctional requirements. Some analysts may have strong business backgrounds which help them to understand the functional requirements quite well, but have a harder time even knowing what is important in the nonfunctional area. Similarly an analyst may have strong programming and other technical skills but not understand workflows or business process well. The following questions might help in a discussion on determining requirements. If you (the student) do not have a strong technical background, how do you ensure that you have found out all of the important nonfunctional requirements? How do you test or validate that you are not missing important things? Navigating the landscape of nonfunctional requirements can indeed be challenging, especially for individuals without a strong technical background. However, there are several strategies you can employ to ensure thorough exploration and validation of nonfunctional requirements: 1. Collaboration and Communication: Engage closely with technical stakeholders, such as developers, architects, or system administrators, to gain insights into nonfunctional aspects relevant to the project. These stakeholders often possess valuable expertise and can help identify critical nonfunctional requirements. 2. Research and Learning: Invest time in understanding common categories of nonfunctional requirements, such as performance, security, scalability, reliability, and usability. Explore resources such as industry standards, best practices, and case studies to broaden your knowledge and identify potential blind spots. 3. Requirement Elicitation Techniques: Utilize various requirement elicitation techniques, such as interviews, surveys, workshops, and brainstorming sessions, to gather insights from a diverse range of stakeholders. Encourage open discussion and prompt participants to consider both functional and nonfunctional aspects of the system. 4. Questioning and Probing: Ask targeted questions during requirement gathering sessions to uncover hidden nonfunctional requirements. For example, inquire about performance expectations, security constraints, usability preferences, or regulatory compliance needs. Probe deeper to ensure comprehensive coverage across different nonfunctional dimensions. 5. Prioritization and Validation: Prioritize nonfunctional requirements based on their importance to the project's success criteria, stakeholder needs, and organizational priorities. Create a structured approach for validating nonfunctional requirements, such as conducting feasibility studies, prototyping, simulations, or benchmarking against industry standards. 6. Iterative Refinement: Recognize that requirement elicitation is an iterative process and that nonfunctional requirements may evolve over time. Continuously refine and validate nonfunctional requirements throughout the project lifecycle, incorporating feedback from stakeholders and adjusting priorities as needed. 7. Documentation and Traceability: Document nonfunctional requirements systematically, ensuring clarity, specificity, and traceability to corresponding functional requirements. Use appropriate tools and templates to organize and communicate nonfunctional requirements effectively, facilitating shared understanding among project stakeholders. By leveraging these strategies and actively engaging with both technical and non-technical stakeholders, you can enhance your ability to identify, validate, and prioritize nonfunctional requirements, thereby contributing to the overall success of the project. Similarly if you (the student) do not have a strong business process background, or very much knowledge about the problem domain (e.g. the business area being supported), how do you ensure that you have asked all the important questions and that your requirements are accurate, thorough, and comprehensive? If you lack a strong background in business processes or knowledge about the problem domain, there are several strategies you can employ to ensure that you gather accurate, thorough, and comprehensive requirements: 1. Collaborate with Subject Matter Experts (SMEs): Engage with individuals who have expertise in the business domain or specific business processes you're working on. SMEs can provide invaluable insights into the intricacies of the domain, helping you ask the right questions and understand the nuances of the requirements. 2. Conduct Stakeholder Interviews: Schedule interviews with stakeholders from various departments or roles impacted by the project. This allows you to gather different perspectives and uncover potential requirements that might not be immediately obvious. Make sure to prepare open-ended questions to encourage detailed responses. 3. Utilize Requirement Gathering Techniques: Employ various requirement gathering techniques such as workshops, surveys, and observations to capture a comprehensive set of requirements. Each technique offers unique advantages and can help you gain a deeper understanding of the problem domain. 4. Refer to Existing Documentation: Review any existing documentation, such as business process manuals, project charters, or previous requirements documents. This can provide valuable context and help you identify areas that require further exploration. 5. Ask Probing Questions: Don't hesitate to ask probing questions during discussions or interviews to clarify ambiguous requirements or uncover underlying needs. For example, ask about potential edge cases, exceptions, or future scalability requirements. 6. Validate Requirements Iteratively: Share your initial set of requirements with stakeholders for feedback and validation. Iteratively refining and validating requirements ensures that they accurately reflect the needs of the stakeholders and the business. 7. Stay Updated on Industry Trends: Keep yourself informed about industry trends, best practices, and emerging technologies related to the problem domain. This knowledge can help you anticipate future requirements and ensure that your solution remains relevant in the long term. By employing these strategies and approaches, even if you lack a strong background in the business domain, you can ensure that you gather accurate, thorough, and comprehensive requirements for your project. What are some techniques that might help you to have good interviews that get to the root of the issues? Conducting effective interviews is crucial for eliciting comprehensive requirements, both functional and nonfunctional. Here are some techniques that can help ensure successful interviews that delve into the root of the issues: 1. Preparation: • Familiarize yourself with the project context, objectives, and stakeholders before the interview. • Develop a structured interview plan with specific objectives and a list of topics to cover. • Identify key stakeholders and their roles in relation to the project. 2. Active Listening: • Listen attentively to the interviewee's responses, focusing on understanding their perspectives, concerns, and priorities. • Ask open-ended questions to encourage detailed explanations and uncover underlying issues. • Paraphrase and summarize the interviewee's statements to demonstrate understanding and clarify any ambiguities. 3. Probing Questions: • Use probing questions to delve deeper into specific areas of interest or ambiguity. • Ask follow-up questions to explore connections between different requirements or to gather additional context. • Challenge assumptions and seek clarification when necessary to ensure a clear understanding of the requirements. 4. Empathy and Rapport Building: • Build rapport with the interviewee to create a comfortable and open environment for discussion. • Demonstrate empathy towards the interviewee's perspectives, experiences, and challenges. • Establish trust by being transparent about the interview process and the purpose of gathering requirements. 5. Visual Aids and Examples: • Use visual aids, such as diagrams, prototypes, or mock-ups, to illustrate concepts and stimulate discussion. • Provide concrete examples or scenarios to help the interviewee contextualize their requirements and articulate their needs more effectively. 6. Contextual Inquiry: • Conduct interviews in the context where the work occurs, if feasible, to observe workflows, interactions, and pain points firsthand. • Observe and ask questions about existing processes, tools, and behaviors to uncover implicit requirements and opportunities for improvement. 7. Recordkeeping and Documentation: • Take detailed notes during the interview to capture key insights, requirements, and decisions. • Use recording tools or transcripts, with the interviewee's consent, to ensure accuracy and facilitate further analysis. • Document interview findings promptly and systematically, organizing them into structured requirements documentation for future reference. 8. Iterative Feedback and Validation: • Seek feedback from stakeholders on the interview process and preliminary requirements to ensure alignment and completeness. • Validate interview findings through follow-up discussions, reviews, or prototypes to confirm understanding and address any discrepancies or misunderstandings. By applying these techniques, you can conduct interviews that go beyond surface-level discussions and uncover the underlying issues, needs, and requirements essential for successful project outcomes. 2. Analyst (and Project) Leadership Which set of skills are more important, business skills or technical skills? Which set of skills is easier to learn, business skills or technical skills? When do you need an analyst with a strong business background to lead the analysis phase? When do you need an analyst with a strong technical background to lead the analysis phase? The importance of business skills versus technical skills in analyst (and project) leadership can depend on various factors, including the nature of the project, the industry, and the specific goals of the analysis phase. Let's break down each aspect: 1. Importance of Skills: • Business Skills: These are crucial for understanding the strategic objectives of the project, aligning analysis outcomes with business goals, communicating findings effectively to stakeholders, and making informed decisions that drive business success. Business skills encompass areas such as problem-solving, communication, critical thinking, and understanding market dynamics. • Technical Skills: These are essential for conducting the analysis itself, leveraging tools and technologies to gather, process, and analyze data effectively. Technical skills may include proficiency in programming languages, data manipulation, statistical analysis, and familiarity with relevant software or platforms. 2. Ease of Learning: • Business Skills: While business skills are often considered softer skills, they can be challenging to master due to their subjective and context-dependent nature. However, they are generally easier to learn through practice, experience, and continuous professional development. • Technical Skills: Technical skills tend to be more specialized and may require specific training or education. Learning technical skills can be more structured and may involve formal education, certifications, or hands-on experience with relevant tools and technologies. 3. When to Prioritize Business Skills: • An analyst with a strong business background is particularly valuable when the project requires a deep understanding of market dynamics, customer needs, industry trends, or regulatory requirements. • They are essential for projects focused on strategic planning, market research, product development, or business process optimization. • In situations where stakeholder engagement and effective communication are critical, a leader with strong business acumen can ensure alignment between analysis outcomes and organizational objectives. 4. When to Prioritize Technical Skills: • An analyst with a strong technical background is indispensable when the project involves complex data analysis, modeling, or algorithm development. • They are crucial for projects that heavily rely on data-driven insights, such as predictive analytics, machine learning, or optimization. • In scenarios where the analysis phase requires advanced statistical techniques, data manipulation, or programming expertise, a leader with strong technical skills can ensure the accuracy and reliability of analysis outcomes. In many cases, a successful analyst (and project) leader will possess a balanced combination of both business and technical skills. However, the relative importance of each set of skills may vary depending on the specific project requirements and organizational context. Ultimately, the key is to leverage the strengths of the team members and ensure that both business objectives and technical rigor are adequately addressed throughout the analysis phase. Instructor Manual for Systems Analysis and Design in a Changing World John W. Satzinger, Robert B. Jackson, Stephen D. Burd 9781305117204, 9781111951641
