Insulin Pump Systems Requirements Quiz

Identifying Needs & Capturing User Requirements

• This lecture covers requirement elicitation techniques, focusing on methods to understand user needs and translate them into functional requirements for software development.

Requirement Elicitation Techniques

• Interviews: Formal or informal conversations with stakeholders to gather information about their needs and expectations. Types include closed (pre-determined questions) and open (no predefined agenda). Effective interviews require open-mindedness, active listening, and using prompts (e.g., requirements proposal, working on a prototype) to encourage discussion.

• Scenarios: Real-life examples describing how users interact with the system, including normal flow, errors, and concurrent activities. Scenarios help illustrate expected behavior and potential issues.

• Prototypes: Early models or simulations of the system to help stakeholders visualize and understand functionalities.

• Facilitated Meetings: Meetings with stakeholders to guide them in identifying and defining their requirements.

• Task Analysis: A top-down breakdown of tasks performed by users and the system. This technique establishes a hierarchy of tasks and determines the knowledge needed for each.

• User Stories: Brief descriptions of how users interact with the system from their perspective, often used in Agile development.

• Introspection: The analyst's understanding of what users need based on experience with the domain. This is largely a first step, used as a starting point or when other methods are difficult to employ.

• Questionnaires: Used to collect information from multiple stakeholders quickly, typically employed early in the process. They may contain open-ended/closed questions to gain broad/focused feedback. Careful question design minimizes irrelevant data.

• Card Sorting: An elicitation technique involving stakeholders creating and organizing cards with system functionalities and ranking them to reveal priorities.

Scenario for Collecting Medical History in MHC-PMS

• Initial assumption: Patient has been seen by a receptionist and their details entered. A nurse is gathering medical history.
• Normal flow: Searching for patient by surname, first name, and date of birth. Entering consultation details (free text), medical conditions, medication, allergies and home life information to capture patient information details and issues impacting the user experience.
• Issues/Problem: Patient information may not be available in the database. The system must handle this situation and allow creating of new records as necessary.

Task Analysis (Pet Store Example)

• Task analysis breaks down complex tasks into smaller, manageable components.
• The example shows the hierarchy of tasks required for a pet store point-of-sale (POS) system, demonstrating how user and system interactions are documented. This creates a hierarchy of tasks and determines the knowledge required for those tasks.

Introspection

• This technique is used as a starting point in understanding users' needs and system design.
• It works best when the analyst is experienced with the domain.
• It should be used with caution when users are unfamiliar with software.

Card Sorting

• Using cards to identify and rank functionalities, this helps discover priorities; users also identify potential omissions/corrections and ranking helps prioritize features.

Laddering

• This technique involves asking customers short, prompting questions to investigate their use cases and system requirements, often showing how different features interact.

Ethnography

• This observational technique involves studying users in their natural environment to gain insights about how they complete tasks. The goal is to derive requirements for the system based on observations.

Requirement Analysis

• Detect and resolve conflicts between requirements.
• Explore the system's interaction with its environment
• Elaborate system requirements to determine software needs.
• Use different analysis methods to classify requirements

Software Requirements Specification

• Establishes agreements between customers and contractors/suppliers outlining software functionality, expected behavior, and limitations.
• Enables rigorous assessment before design and reduces later design changes.
• Can be used as a basis for verification/validation plans when testing the software.
• Supports the transfer of the software to different user groups/platforms.

Commitment and Prioritization

• The commitment level (must, will, should, would, could) reflects the obligation related to meeting the requirement.
• This is often coupled with an assigned priority level for each functional requirement to reflect relative importance during deployment.

Ways of Writing Requirements Specification

• Natural language: Detailed, numbered sentences in clear language that describe requirements.
• Structured natural language: Using a standard template to organize language around field-based criteria, e.g., Inputs, outputs, description, side-effects.
• Graphical notations: UML use cases and sequence diagrams are common, adding visual representation of functional requirements.
• Mathematical specifications: Formal methods using sets/formal logic to describe functional system properties, less user-friendly but unambiguous.

Types of Specifications (Structured Specifications, Tabular Specification)

• Structured Specifications: Detailed descriptions of functions, inputs, outputs, pre/post conditions and side effects.
• Tabular Specifications: Supplementary to natural language, lists various conditions and associated system responses to identify possible system states and their actions.

Software Requirements Quality

• Criteria like correctness, feasibility, necessity, prioritization, unambiguous statements, and verifiability ensure requirements accurately capture user needs and are technically achievable. Also include completeness (no omissions) and consistency (no contradictory requirements).

Requirements Validation

• Requirements validation is crucial for ensuring the system meets user needs fully, as fixes are exponentially more costly further down the software development lifecycle.
• Techniques used include:
  • Reviews: Team analysis for consistency and errors.
  • Prototyping: Testing the actual system and gathering real-world user feedback.
  • Test-case generation: Ensuring requirements lead to testable software.

Requirements Elicitation (Overview & Process)

• The process of eliciting (understanding and documenting) requirements involves identifying the origin of requirements and how users/stakeholders will be involved with the system.
• Includes analysis of stakeholders, understanding the application domain and related process and rules, documenting sources of requirements and selecting techniques and tools for the project.
  • Stakeholders: All parties involved in the system's development and deployment.
  • Sources: Individuals/departments with in-depth knowledge of the subject domain.

Types of Requirements

• User Requirements: High-level statements describing the desired outcomes/user experience with the software. This defines what the software should do.
• System Requirements: Formal, detailed specifications defining the software's functionality in detail. This specifies how the software should do what the user wants, including inputs, outputs, and expected workflows.

Functional Requirements

• Describe what the software should do. It could include steps such as 'adding a new account,' or how to access functionalities.

Non-functional Requirements

• Describe the qualities and limitations of the system, including constraints. This could include response time, reliability, or any constraints on how the software should be used.

Metrics for Specifying Non-Functional Requirements

• Measures to quantify non-functional requirements (reliability, performance, etc.) such as processed transactions/second, error rates, and user training times, which help in quantifying the effectiveness of the software.

Test your knowledge on the quality criteria and key characteristics of requirements in insulin pump systems. This quiz covers completeness, correctness, and verification of requirements essential for stakeholders. Understand how these criteria impact the functionality of insulin pumps.