Ch04_Requirements-1.pdf

Systems Analysis and Design, 13 th Edition Chapter 4: Requirements Engineering Scott Tilley, S...

Systems Analysis and Design, 13 th Edition Chapter 4: Requirements Engineering Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 1  Chapter Objectives (1 of 2) By the end of this chapter, you should be able to: 1. Explain system requirements and the challenges associated with the requirements engineering process. 2. Apply team-based requirements engineering techniques, including joint application development (JAD), rapid application development (RAD), and agile methods. 3. Develop a fact-finding plan for gathering requirements. 4. Conduct an interview to gather system requirements. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2  Chapter Objectives (2 of 2) By the end of this chapter, you should be able to (continued): 5. Use other requirements gathering techniques, including document review, observation, questionnaires and surveys, brainstorming, sampling, and research. 6. Explain how requirements are gathered in agile projects. 7. Utilize different requirements representation techniques, including natural language, diagrams, and models. 8. Explain how to validate and verify requirements. 9. Explain how tools can help with requirements engineering activities. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3  System Requirements (1 of 4) A system requirement is a characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users Requirements engineering is composed of the following activities: − Gathering requirements: understanding the problem − Representing requirements: describing the problem − Validating and verifying requirements: agreeing on the problem Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4  System Requirements (2 of 4) System requirements can be classified as functional and non- functional A functional requirement is a statement of the services a system provides − An example of this requirement is “a website shall report online volume statistics every four hours and hourly during peak periods” A non-functional requirement is a statement of operational system constraints − An example of this requirement is “the system must support 25 users online simultaneously” Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5  System Requirements (3 of 4) Requirement challenges include the following: − Imprecision - requirements are often imprecise because they are usually represented using natural language − Agreement - another challenge is getting everyone to agree on the exact meaning of the requirement statements − Creep - business changes can lead to changing requirements which can lead to “feature creep”  Rapidly changing requirements can cause problems for systems analysts and other team members Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6  System Requirements (4 of 4) Systems analysts must also consider the following: − Scalability refers to a system’s ability to handle increased business volume and transactions in the future − Security is crucial for networked systems and has changed from a non-functional requirement to a functional requirement − System developers must identify and document indirect expenses contributing to the total cost of ownership (TCO) Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7  Team-Based Techniques (1 of 8) Joint application development (JAD) is a user-oriented technique for fact-finding and requirements engineering JAD sessions are planned by selecting participants, defining the scope, and setting goals and objectives for the sessions JAD sessions are facilitated by a trained moderator or facilitator Information gathered during JAD sessions is organized and documented clearly and concisely JAD sessions are often conducted iteratively, allowing for continuous refinement of requirements Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8  Team-Based Techniques (2 of 8) Table 4-1 Typical JAD participants and roles. JAD Participant Role JAD project leader Develops an agenda, acts as a facilitator, and leads the JAD session Top management Provides enterprise-level authorization and support for the project Managers Provide department-level support for the project and understanding of how the project must support business functions and requirements Users Provide operational-level input on current operations, desired changes, input and output requirements, user interface issues, and how the project will support day-to-day tasks Systems analysts and other IT Provide technical assistance and resources for JAD team members on issues such as staff members security, backup, hardware, software, and network capability Recorder Documents results of JAD sessions and works with systems analysts to build system models and develop CASE tool documentation Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9  Team-Based Techniques (3 of 8) Benefits of JAD include the following: − Stakeholder involvement − Improved communication − Time and cost efficiency − Accelerated decision making − Reduced rework Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10  Team-Based Techniques (4 of 8) Rapid Application Development (RAD) is an iterative and incremental team-based approach to systems analysis and design that focuses on quickly developing high-quality software applications RAD follows an iterative and incremental development process RAD emphasizes continuous and active user involvement and uses prototyping techniques to build working models of the application RAD projects are timeboxed with a fixed time frame for each phase RAD encourages collaborative development and the reuse of existing components Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11 Team-Based Techniques (5 of 8) Figure 4-1 The four phases of the RAD model are requirements planning, user design, construction, and cutover. Notice the continuous interaction between the user design and construction phases. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12  Team-Based Techniques (6 of 8) The main objective of RAD is to cut development time and expense by involving users in every phase of systems development The benefits of RAD include the following: − Faster time to market − Improved user satisfaction − Increased flexibility and adaptability − Risk mitigation − Enhanced collaboration Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13  Team-Based Techniques (7 of 8) Agile methods attempt to develop a system incrementally by building prototypes and constantly adjusting them to user requirements An agile approach emphasizes continuous feedback − Each incremental step is affected by what was learned in the previous steps Scrum is another agile method that involves the same interaction, though it is more mental than physical − Agile team members play specific roles in a Scrum session Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14  Team-Based Techniques (8 of 8) The benefits of agile methods include the following: − Adaptability to changing requirements − Continuous customer involvement − Early and frequent delivery of value − Increased transparency and visibility − Continuous improvement and quality focus Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15  Requirements Elicitation (1 of 2) Requirements elicitation (gathering) or fact-finding (collecting information) is the first step in the requirements engineering process During requirements gathering, the systems analyst will use various techniques, including the following: − Interviews − Document review − Observation − Surveys and questionnaires − Sampling and research Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16  Requirements Elicitation (2 of 2) Table 4-3 Sample questions during requirements elicitation as the focus shifts from the current system to the proposed system. Current System Proposed System Who does it? Why does this person do it? Who should do it? What is done? Why is it done? What should be done? Where is it done? Why is it done there? Where should it be done? When is it done? Why is it done then? When should it be done? How is it done? Why is it done this way? How should it be done? Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17  Knowledge Check Activity 4-1 Is the requirement “The system shall respond within 2 seconds” a functional or non-functional requirement? Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18  Knowledge Check Activity 4-1: Answer Is the requirement “The system shall respond within 2 seconds” a functional or non-functional requirement? Answer: This is an example of a non-functional requirement, which is a statement of operational system constraints. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19  Interviews (1 of 4) An interview is a planned meeting during which the analyst obtains information from another person The following are steps in the interview process: − Determine the people to interview − Establish objectives for the interview − Develop interview questions − Prepare for the interview − Conduct the interview − Document and evaluate the interview Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20  Other Elicitation Techniques (1 of 5) Document review can help the analyst understand how the current system is supposed to work The observation of current operating procedures is a fact-finding technique that allows the analyst to verify statements made in interviews and determine whether procedures operate as described A questionnaire (survey) contains several standard questions that can be sent to many individuals − They can be used to obtain information including workloads, reports received, volumes of transactions handled, job duties, difficulties, and opinions of how the job could be performed better Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24 Other Elicitation Techniques (2 of 5) Figure 4-8 Part of an online questionnaire. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25  Other Elicitation Techniques (3 of 5) Interviews versus Questionnaires − The interview is more familiar and personal than a questionnaire − Interviewing is costly and time-consuming − A questionnaire allows many people to provide input and suggestions on their own time without scheduling a block of time − People may offer more candid responses in a questionnaire − The analyst should select the technique that will work best in a particular situation Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26  Other Elicitation Techniques (4 of 5) Brainstorming refers to a small group discussion of a specific issue − In structured brainstorming, each participant speaks when it is their turn or passes − In unstructured brainstorming, anyone can speak at any time Documents should be collected using sampling − A systematic sampling would select every tenth customer for review − A stratified sample could select five customer from each of four postal codes − A random sample selects any 20 customers Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27  Other Elicitation Techniques (5 of 5) Research is another important fact-finding technique that can include the following: − The Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments Research can also involve a visit to a physical location, called a site visit, where the objective is to observe a system used at another location − During the visit, observe the system and note any problems or limitations and learn about support provided by the vendor Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28  Knowledge Check Activity 4-2 Explain how the observation fact-finding technique works. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29  Knowledge Check Activity 4-2: Answer Explain how the observation fact-finding technique works. Answer: The observation of current operating procedures is a fact- finding technique. Seeing the system in action provides additional perspective and a better understanding of system procedures. Personal observation also allows the analyst to verify statements made in interviews and determine whether procedures operate as described. Through observation, it might be discovered that neither the system documentation nor the interview statements are accurate. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30  Requirements Elicitation in Agile Projects (1 of 2) Requirements elicitation characteristics include the following: − Iterative and incremental progress − Collaboration − Adaptive process − Backlog management − Validation and verification Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31  Requirements Elicitation in Agile Projects (2 of 2) Requirements elicitation is performed using a variation of interviews Requirements begin as features − Features are split into smaller user stories − User stories are distilled into scenarios where storyboards are used A scenario (also known as use case) describes a specific situation in which a system interacts with an end user (or another system) Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32  Representing Requirements (1 of 6) Once requirements have been gathered, they must be recorded An analyst should document their work according to the following principles: − Record information as soon as it is obtained − Use the simplest recording method possible − Record findings in such a way that someone else can understand them − Organize documentation so related material is located easily Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33  Representing Requirements (2 of 6) Most requirements are represented using unstructured natural language Requirements can be stored in a simple file, a database that may facilitate searching its contents, or an Excel spreadsheet Requirements represented as structured natural language can be stored on a simple index card There are formal techniques based on mathematics that can be used to represent complex requirements Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34  Representing Requirements (3 of 6) For people who are more visual, diagrams are an option to represent system requirements A functional decomposition diagram (FDD) is a top-down representation of a function or process A business process model (BPM) represents one or more business processes A data flow diagram (DFD) can be used to show how the system stores, processes, and transforms data Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35 Representing Requirements (4 of 6) Figure 4-12 This FDD shows a library system with five top-level functions. The Library Operations function includes two additional levels of processes and subprocesses Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36  Representing Requirements (5 of 6) Models provide a more formal representation of system requirements The Unified Modeling Language (UML) is a widely used modeling technique for visualizing and documenting software systems design − SysML is dialect of UML and has become the standard for Model- Based Systems Engineering (MBSE) applications A use case diagram visually represents the interaction between users and the information system A sequence diagram shows the timing of interactions between objects as they occur Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37 Representing Requirements (6 of 6) Figure 4-16 This use case diagram shows a student records system. Figure 4-17 This sequence diagram shows a credit card validation process. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38  Validation and Verification (1 of 2) Requirements validation and verification (V&V) is concerned with demonstrating that the requirements define the system that the customer wants Requirements V&V focuses on answering two essential questions: − Validation: Are the correct requirements stated? − Verification: Are the requirements stated correctly? Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39  Validation and Verification (2 of 2) The following requirements attributes should be checked: − Validity, consistency, completeness, realism, verifiability, comprehensibility, traceability, and adaptability The following techniques can be used: − Requirements review − Prototyping − Test-case generation − Automated consistency analysis Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40  Tools (1 of 3) Productivity software can be used to record and document information elicited during the requirements gathering process Other useful tools include the following: − Microsoft Word, Microsoft Excel, database management software, presentation graphics software, collaboration software, and graphic modeling tools Traceability is the ability to follow a requirement backward to its origins and forward through the SDLC to link design documents, code fragments, and test artifacts Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41  Tools (2 of 3) Figure 4-18 Evernote offers a free version of its popular information management software for most computing platforms, including smartphones and the web Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42  Knowledge Check Activity 4-3 Why is traceability important in tool support for requirements engineering? Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44  Knowledge Check Activity 4-3: Answer Why is traceability important in tool support for requirements engineering? Answer: Traceability is the ability to follow a requirement backward to its origins and forward through the SDLC to link design documents, code fragments, and test artifacts. It is essential because it helps determine if the requirements are consistent and complete, thereby satisfying the users’ system needs. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 45  Summary (1 of 2) Now that the lesson has ended, you should be able to: 1. Explain system requirements and the challenges associated with the requirements engineering process. 2. Apply team-based requirements engineering techniques, including joint application development (JAD), rapid application development (RAD), and agile methods. 3. Develop a fact-finding plan for gathering requirements. 4. Conduct an interview to gather system requirements. Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47  Summary (2 of 2) Now that the lesson has ended, you should be able to (continued): 5. Use other requirements gathering techniques, including document review, observation, questionnaires and surveys, brainstorming, sampling, and research. 6. Explain how requirements are gathered in agile projects. 7. Utilize different requirements representation techniques, including natural language, diagrams, and models. 8. Explain how to validate and verify requirements. 9. Explain how tools can help with requirement engineering activities Scott Tilley, Systems Analysis and Design, 13th Edition. © 2025 Cengage. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48