Chapter 4.pdf

Week 4 | Chapter 4: Requirements Engineering 4.1 System Requirements ❖ System Requirements Overview System Requirement: a characteristic or feature that must be included in an information system to satisfy business requirements and be acceptab...

Week 4 | Chapter 4: Requirements Engineering 4.1 System Requirements ❖ System Requirements Overview System Requirement: a characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users. Purpose: serve as benchmarks to measure the overall acceptability of the finished system; it is critical to get requirements right from the start of the Systems Development Life Cycle (SDLC) to avoid the rippling effect. ○ Poor requirements engineering is a leading cause of failed projects. Key Activities in Requirements Engineering: ○ Gathering requirements—understanding the problem. ○ Representing requirements—describing the problem. ○ Validating & verifying requirements—agreeing on the problem. 4.1.1 Types of Requirements ❖ Classifications: (Requirements) Definitions: for the system user. (Requirements) Specifications: for the engineering team. ❖ Categories: Functional Requirement: a statement of the services a system provides ○ Examples: → "The website shall report online volume statistics every four hours and hourly during peak periods." → "Each input form must include date, time, product code, customer number, and quantity." Non-Functional Requirements (Quality Attributes): a statement of operational system constraints. ○ Examples: → "The system must support 25 users online simultaneously." → "Response time must not exceed 4 seconds." ❖ Note: non-functional requirements may be more critical than functional requirements; if the former are not satisfied, the system is useless. 4.1.2 Requirements Challenges: ❖ Imprecision Natural language used in requirements can lead to misunderstandings and misinterpretations. Some requirements need to be flexible for bids but precise for contracts. ❖ Agreement Getting stakeholders to agree on the exact meaning of requirements is challenging. Requirements should be complete (include all facilities) and consistent (no conflicts). ❖ Creep (Feature Creep) Requirements tend to evolve due to business changes or project duration. Agile methods address changing requirements better than traditional models. 4.1.3 Additional Considerations: ❖ Scalability: a system’s ability to handle increased business volume and transactions in the future.  Because it will have a longer useful life, a scalable system offers a better return on the initial investment. Consider projections for inputs, outputs, and transaction volumes for future hardware and software requirements. ❖ Security Security is no longer a non-functional add-on, but a core functional requirement. Security conflicts with other user requirements (e.g., ease of access vs. security). ❖ Total Cost of Ownership (TCO): includes both direct and indirect costs, like user support and downtime. Lower initial costs may not account for hidden future expenses. 4.2 Team-Based Techniques ❖ Team-Based Techniques Overview Goal: deliver the best possible information system at the lowest cost, in the shortest time. User Involvement: users are seen as partners, resulting in better communication, faster development, and more satisfied users. Popular Methods: Joint Application Development (JAD), Rapid Application Development (RAD), and Agile Methods. 4.2.1 Joint Application Development (JAD) ❖ Joint Application Development (JAD): a fact-finding technique involving users as active participants in the development process. ❖ Users, managers, and IT professionals work together to gather information, discuss needs, and define system requirements. ❖ Typical JAD Participants and Roles: 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 Staff Members: provide technical assistance and resources for JAD team members on issues such as 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. ❖ Figure 4-3—Typical Agenda For A JAD Session  ❖ Advantages: Increases user ownership and system support. Provides more accurate system requirements through collaboration. ❖ Disadvantages: Can be more expensive and cumbersome if the group is too large. 4.2.2 Rapid Application Development (RAD) ❖ Rapid Application Development (RAD): a team-based approach that speeds up system development through user involvement and prototyping. ❖ Phases of RAD: Requirements Planning Phase: users, managers, and IT agree on business needs, project scope, and systems requirements; obtain approval to continue. User Design Phase: users interact with developers to develop models and prototypes; conduct intensive JAD-type sessions. Construction Phase: development of the system continues with user input; coding; unit, integration, and system testing. Cutover Phase: final implementation including data conversion, full-scale testing, system changeover and user training. ❖ Objectives: Reduce development time and cost. Involve users at every stage of development. Allow continuous modification based on user feedback. ❖ Advantages: Faster development with cost savings. High user involvement ensures the system meets user needs. ❖ Disadvantages:  May not align with long-term business goals. Accelerated timeline might compromise quality and standards. 4.2.3 Agile Methods ❖ Agile Methods: incremental development using continuous feedback, frequent prototypes, and adjustments to user requirements. ❖ Key Features: Continuous revision and extension of earlier versions. Emphasizes team interaction, flexibility, and rapid responses to change. Frequent deliverables that validate the project and reduce risk. ❖ Scrum Approach The name comes from the rugby term scrum, where team members lunge at each other to achieve their objectives. Intense, team-based sessions where roles like "pigs" (committed members) and "chickens" (contributors) are assigned. Team interaction in time blocks, with deliverable software as the end goal. ❖ Advantages: Highly flexible and responsive to change. Promotes teamwork and produces frequent deliverables. ❖ Disadvantages: Requires high technical and interpersonal skills. Lack of structure and documentation can introduce risks. Continuous evolving user requirements can lead to scope changes. 4.3 Gathering Requirements ❖ Overview Requirements Elicitation/Fact-Finding/Collecting Information: the first step in the requirements engineering process; the systems analyst will use various techniques, including interviews, document review, observation, surveys and questionnaires, sampling, and research to gather and understand the needs for a new or updated information system. ❖ Techniques for Gathering Requirements: Interviews: speak directly with stakeholders to understand their needs. Document Review: analyze existing system documentation and reports. Observation: watch current processes in action to understand workflows. Surveys/Questionnaires: collect structured data from users and stakeholders. Sampling: analyze a representative portion of data or transactions. Research: investigate similar systems or industry standards. ❖ Key Questions for Requirements Gathering: What business functions are supported by the current system? What strategic objectives and business needs must the new system support? What are the benefits and total cost of ownership (TCO) of the new system? What transactions will the system handle? What information do users and managers need? Must the new system interface with legacy systems? What processes can be eliminated through business process reengineering? What are the security requirements?  What risks are acceptable? What are the budget and timeline constraints? ❖ Fact-Finding Plan: answer the following key questions, using the 5Ws and 1H approach—Who, What, Where, When, How, and Why. Who performs each procedure? ○ Consider: are the right people doing the task? Could others do it better? What procedures are being followed? ○ Consider: are the current procedures necessary, and why are they being done? Where are operations taking place? ○ Consider: could the operations be performed more efficiently elsewhere? When are the procedures performed? ○ Consider: is this the best time for them to occur? How are the procedures being performed? ○ Consider: can they be done more efficiently or at a lower cost? ❖ Understanding Current vs. Future Needs Current Needs: understand the existing system and processes first. Future Needs: once the current processes are clear, focus on what improvements or changes should be made for the new system. 4.4 Gathering Requirements Through Interviews ❖ Overview Purpose: interviews are a key technique for gathering requirements during systems analysis. Skills Needed: planning, conducting, documenting, and evaluating interviews. ❖ The Interview Process + Step-by-Step Breakdown: Determine People to Interview ○ Scope: interview people from all levels of the organization, and potentially external stakeholders. ○ Consider: both formal (organization chart) and informal structures. → Informal Structures usually are based on interpersonal relationships and can develop from previous work assignments, physical proximity, unofficial procedures, or personal relationships; in an informal structure, some people have more influence or knowledge than appears on an organization chart. ○ Group Interviews: can save time but may limit individual responses. Establish Interview Objectives ○ Tailor objectives based on the interviewee’s role (e.g., upper managers give big picture, frontline staff provide details). ○ Start broad and refine objectives as the analysis continues. ○ Keep interviews as brief as possible while meeting objectives. Develop Interview Questions ○ Types of Questions: → Open-Ended Questions: encourages spontaneous and unstructured responses; useful to understand a larger process or draw out the interviewee’s opinions, attitudes, or suggestions (e.g., "What are users saying about the new system?").  → Closed-ended Questions: limits or restricts the response; used when information that is more specific is needed or when facts must be verified (e.g., "Do you review the reports before they are sent out?"). → Range-of-Response Questions: closed-ended questions that ask the person to evaluate something by providing limited answers to specific responses or on a numeric scale; this makes it easier to tabulate the answers and interpret the results (e.g., "On a scale of 1-10, how effective was your training?"). ○ Avoid Leading Questions: suggests or favors a particular reply (e.g., ask "Do you see any advantages in the proposed system?" instead of "What advantages do you see in the proposed system?"). Prepare For The Interview ○ Schedule the interview with a clear time and date, and notify department managers. ○ Send Prep Material: provide the interviewee with an agenda and any specific questions beforehand. ○ Location: choose between the interviewee’s office (for comfort) or a neutral location (to avoid interruptions). Conduct The Interview ○ Opening: begin with introductions and explain the project and interview objectives. ○ Engaged Listening: focus on what is said and be aware of nonverbal cues (because analysts sometimes hear only what they expect to hear); avoid interrupting the flow. ○ Follow-ups: ask logical follow-up questions when needed. ○ Closing: summarize key points, explain next steps, and thank the interviewee. Document The Interview ○ Take Minimal Notes: focus on key points to avoid distractions. ○ Record Info Quickly: summarize the meeting right after to avoid losing details. ○ Recording Devices: only use with interviewee’s consent and ensure privacy. ○ Follow-Up Memo: send a memo after the interview summarizing key points. Evaluate The Interview ○ Bias Detection: be aware of any biases or incomplete answers (for example, interviewees might protect their department or distort facts). ○ Unproductive Interviews: if the interview isn’t yielding useful information, tactfully end it and seek alternatives (e.g., inform supervisors or reassign the interview). ❖ Interview Success Tips: Build rapport to make the interviewee feel comfortable and open. Be patient: allow interviewees time to think and respond. Adapt: switch to closed-ended questions if open-ended questions aren't producing detailed answers. Summarize and confirm the interviewee's responses to ensure accuracy. 4.5 Gathering Requirements Using Other Techniques ❖ Document Review Purpose: understand the current system’s structure and functionality. Approach: obtain copies of actual forms, documents, and samples currently in use. Considerations: ○ Forms and procedures may be outdated or modified. ○ Ensure you gather real, updated documents. ○ Review software documentation if applicable. ❖ Observation Purpose: gain insight by watching the system in action. Advantages: ○ Verify if the system works as described. ○ Identify unspoken or undocumented procedures (e.g., exceptions). ○ Build stronger relationships with system users. Planning Observations: prepare a checklist in advance to focus on specific tasks. Considerations: ○ Be mindful of the Hawthorne Effect (people change behavior when observed). ○ Communicate with supervisors and observed staff to explain the purpose. ❖ Questionnaires, Fill-in Forms, and Surveys Purpose: collect input from a large number of people efficiently. Advantages: ○ Wide range of data can be gathered (e.g., workloads, transaction volumes). ○ People can answer anonymously, promoting honesty. Design Considerations: ○ Keep it brief, clear, and user-friendly. ○ Structure questions logically, from simple to complex. ○ Use minimal open-ended questions. ○ Include general comment sections and test the questionnaire with a small group before rollout. ○ Use online tools like Google Forms or SurveyMonkey to streamline distribution and collection. ❖ Interviews vs. Questionnaires Interviews: ○ Best for: in-depth, detailed information from a few individuals. ○ Advantages: personal, immediate clarification, and more candid responses. ○ Challenges: time-consuming, costly, and requires follow-up. Questionnaires: ○ Best for: gathering input from many people quickly. ○ Advantages: less expensive, anonymous responses. ○ Challenges: questions may be misunderstood without immediate clarification. ❖ Brainstorming Purpose: encourage idea generation from small group discussions on a specific issue. Types: ○ Structured Brainstorming: each person speaks in turn. ○ Unstructured Brainstorming: anyone speaks at any time.  Outcome: ideas are recorded and become part of the documentation. ❖ Sampling Purpose: use a representative sample of documents to study a system. Techniques: ○ Systematic Sampling: select every nth record. ○ Stratified Sampling: ensure balance (e.g., 5 from each region). ○ Random Sampling: select random records. Considerations: ○ Make sure the sample accurately reflects the population. ○ Avoid using unusual time periods (e.g., end-of-month spikes). ○ Use sampling for interviews and questionnaires to save time and resources. ❖ Research Purpose: gather background information, industry trends, and technical insights. Sources: ○ Internet (e.g., government websites, professional forums, IT publications like TechCrunch, Ars Technica). ○ Books, magazines, seminars, and IT community discussions. Additional Methods: ○ Site Visits: observe similar systems in use at other companies. ○ Preparation: treat site visits like interviews (schedule, questions, and observations). 4.6 Gathering Requirements in Agile Projects ❖ Features (Epics): high-level, simple statements of requirements. Components: ○ Descriptive name. ○ Size estimate (based on the number of derived requirements or user stories). ○ Priority (set by stakeholders). Source: collected through initial stakeholder interviews. Purpose: features are broken down into more specific user stories. ❖ User Stories: fine-grained requirements that collectively form a feature. Format: "As a [user role], I want [action] so that [goal]." ○ User role: type of stakeholder or system user. ○ Action: task or interaction. ○ Goal: desired outcome. Optional: condition of satisfaction to determine if the product meets the requirement. Tools: often written on a 3” × 5” index card or using software tools. Purpose: provides specific, actionable requirements in user-centric language. ❖ Scenarios/Use Case: real-world examples describing how users will interact with the system. Purpose: ○ Describes the specific steps or events in the use of the system. ○ Helps refine system requirements based on actual usage patterns. ❖ Storyboards: a graphic organizer to visualize the status and flow of the project. Format: ○ Can be as simple as sticky notes on a wall.  ○ Software tools can be used to enhance and manage storyboards. Purpose: visualize the project's progress and the relationship between features, user stories, and scenarios. ❖ Agile Iteration Process Flow: ○ Features are collected from stakeholders. ○ Features are broken down into smaller, more detailed user stories. ○ User stories are refined into scenarios. Purpose: refines and adapts requirements as the project progresses. Best for: projects with frequently changing or evolving requirements. 4.7 Representing Requirements ❖ Principles for Documenting Requirements—properly managing requirements over a project's lifetime is key to success. Record promptly: document information as soon as it’s obtained. Keep it simple: use the simplest method possible. Ensure clarity: findings should be understandable to others. Organize logically: related material should be easy to locate. 4.7.1 Natural Language ❖ Unstructured Natural Language Definition: plain text (e.g., English) commonly used for writing requirements. Advantages: easy to create. Challenges: prone to imprecision and misunderstandings. Storage: ○ Simple files, databases, or spreadsheets. ○ Excel is a popular tool for storing requirements. ❖ Structured Natural Language Definition: tags parts of the requirement (similar to XML) for better processing. Tool: can be stored on index cards (e.g., Volere shell on 3” x 5” cards). Advantages: easier automation, but less user-friendly. 4.7.2 Diagrams ❖ Overview Why Diagrams?: visual representations aid understanding for users, managers, and IT professionals.  Process: build diagrams from fact-finding, review them, and refine requirements accordingly. ❖ Functional Decomposition Diagrams (FDDs): top-down representation of business functions broken down into lower-level processes. Use Case: translate business processes into program modules during application development. Example: FDD for a library system, showing how processes translate into software modules. ❖ Business Process Diagrams: diagrams that model business processes using Business Process Modeling Notation (BPMN) (BPMN includes various shapes and symbols to represent events, processes, and workflows). Key Features: ○ Pool: represents the overall diagram. ○ Swim Lanes: areas designated for different user roles or departments. Example: using the Visible Analyst CASE tool, an analyst can create a business process diagram. The overall diagram is called a pool, and the two separate customer  areas are called swim lanes. Benefits: faster results, fewer errors, reduced costs when integrated into CASE tools. ❖ Data Flow Diagrams (DFDs): show how the system stores, processes, and transforms data. Usage: derived from FDDs to depict data inputs, outputs, and transformations. Example: this Visible Analyst DFD shows how books are added and removed in a library system. 4.7.3 Models ❖ Purpose: formal representations using semantics, allowing automatic analysis by CASE tools. ❖ Unified Modeling Language (UML): standard for visualizing and documenting software systems design. Use: independent of programming languages, useful for business process representation.  Example: SysML is a UML dialect used for Model-Based Systems Engineering (MBSE). ❖ Key UML Tools: Use Case Diagrams: visualize user interactions with the system. ○ Components: actors (users) and system functions (use cases). ○ Example: a sales system use case for credit card validation. This Visible Analyst use case diagram shows a sales system, where the actor is a customer and the use case is a credit card validation. Sequence Diagrams: show timing of interactions between objects in a system. ○ Components: vertical timeline with horizontal arrows indicating messages. ○ Example: sequence diagram for credit card validation. This Visible Analyst sequence diagram shows a credit card validation process. 4.8 Validating and Verifying Requirements ❖ Purpose of Validation and Verification Requirements Validation and Verification ensure that: ○ Validation: the correct requirements are stated (i.e., customer wants). ○ Verification: the requirements are stated correctly (i.e., properly written).  Importance: fixing errors during requirements engineering is much cheaper than fixing them later in the Software Development Life Cycle (SDLC). ❖ Key Requirements Attributes—when conducting validation and verification, the following attributes should be checked: Validity: does the system fulfill the customer’s needs? Consistency: are there any conflicting requirements? Completeness: are all customer-required functions included? Realism: can the requirements be implemented with the available budget, time, and technology? Verifiability: can the requirements be tested or checked? Comprehensibility: are the requirements clearly understood by stakeholders? Traceability: can the origin of the requirement be traced? Adaptability: can the requirement be changed without major impact on other requirements? ❖ Techniques for Validation and Verification Requirements Reviews: a systematic manual review of the requirements. ○ Purpose: ensure accuracy and resolve issues early. ○ Type: can be formal (documented) or informal. ○ Participants: systems analyst, customer, and key stakeholders. Prototyping: creating an executable model or prototype to check if the requirements align with customer needs. Test-Case Generation: developing test cases from requirements to check their testability and correctness. Automated Consistency Analysis: using automated tools to check for consistency in structured or formal requirements descriptions. ❖ Importance of Communication: effective communication between systems analysts, customers, and stakeholders during requirements reviews is crucial to resolve problems early. This helps avoid costly errors later in the project. 4.9 Tools ❖ Productivity Software: helps record and document information during the requirements gathering process. Types: ○ Automation tools ○ Word processing (e.g., Microsoft Word) → Create reports, tables, forms, and more. → Organizes presentations with templates, bookmarks, revision control. → Use for creating fill-in forms for surveys/questionnaires. ○ Spreadsheet (e.g., Microsoft Excel) → Tracks and manages numeric/financial data and requirements. → Generate graphs and charts to show data patterns. → Create statistical analysis for questionnaire data. → Histograms (a common tool for showing the distribution of questionnaire or sampling results is a vertical bar chart) and other charts display data and highlight trends (e.g., in quality control analysis).  ○ Database management (e.g., Microsoft Access) → Documents and organizes findings (e.g., events, observations, data samples). → Create queries and generate custom reports for specific information needs. ○ Presentation graphics (e.g., Microsoft PowerPoint) → Develops formal presentations for requirements findings. → Create organization charts for use in investigations and requirements engineering. → Incorporates charts into written reports and management presentations. ○ Collaboration software (e.g., Microsoft Office 365, Google Docs) → Enables real-time collaboration and file sharing in virtual workplaces. → Cloud computing facilitates interaction without traditional face-to-face limitations. ○ Diagramming Tools (e.g., Microsoft Visio) → Creates various visual models (e.g., flowcharts, business processes, network diagrams). → Drag-and-drop feature simplifies diagram creation using templates and shapes. ○ Formal Modeling Tools (e.g., IBM Rational DOORS) → Special-purpose tool for modeling system requirements using UML and SysML. → Supports traceability: links requirements to design, code, and test cases in the SDLC. ❖ Personal Information Management (PIM) Software: includes a personal calendar, a to-do list with priorities and the capability to check off completed items, and powerful contact management features. Microsoft Outlook: Manages emails, calendars, tasks, and collaboration; Suitable for day-to-day activities but not ideal for large-scale information organization. Microsoft OneNote: Handles various inputs (text, images, videos, notes); Ideal for organizing large volumes of information. Evernote: Multimedia support, free-form notes, and project templates; Cross-device synchronization and available as a free and premium version.