Non-Functional Requirements Quiz
48 Questions
0 Views

Choose a study mode

Play Quiz
Study Flashcards
Spaced Repetition
Chat to lesson

Podcast

Play an AI-generated podcast conversation about this lesson

Questions and Answers

Which type of non-functional requirement specifies how the system must behave in terms of execution speed and reliability?

  • External requirements
  • Product requirements (correct)
  • Organizational requirements
  • Technical requirements

    • What is a characteristic of organizational requirements?

  • They are dictated by legislative needs.
  • They define system functionalities in detail.
  • They arise from external factors.
  • They result from organizational policies and procedures. (correct)

    • Which of the following statements represents a verifiable non-functional requirement?

  • Users shall feel comfortable using the system after training.
  • Medical staff shall be able to use all the system functions after four hours of training. (correct)
  • The system should be easy to use.
  • The system should prioritize user error reduction.

    • What type of requirement is generated by external factors, such as legislation?

    <p>External requirements</p> Signup and view all the answers

    Which metric is used to measure the speed of a system?

    <p>Processed transactions/second</p> Signup and view all the answers

    What aspect does robustness measure in a system?

    <p>Time to restart after failure</p> Signup and view all the answers

    Which statement best describes a goal in the context of non-functional requirements?

    <p>A general intention of the user.</p> Signup and view all the answers

    What is a potential outcome if domain requirements are not satisfied?

    <p>The system may be unworkable.</p> Signup and view all the answers

    How can performance requirements impact the design of a system?

    <p>They may necessitate minimizing communications between components.</p> Signup and view all the answers

    What is the main challenge related to non-functional requirements compared to functional requirements?

    <p>They can be difficult to state precisely and verify.</p> Signup and view all the answers

    Which requirement deals with the system's ability to function correctly under various conditions?

    <p>Functional requirements</p> Signup and view all the answers

    Which of the following describes non-functional requirements?

    <p>They define constraints on system operations.</p> Signup and view all the answers

    Which of the following is an example of an external requirement?

    <p>The system shall implement patient privacy provisions.</p> Signup and view all the answers

    What is a common issue with understandability in domain requirements?

    <p>They are expressed in the language of the application domain.</p> Signup and view all the answers

    Which statement is true regarding metrics for specifying non-functional requirements?

    <p>They include measures like the number of ROM chips.</p> Signup and view all the answers

    What is implicitness in the context of domain requirements problems?

    <p>Domain specialists fail to articulate requirements clearly due to their familiarity with the area.</p> Signup and view all the answers

    What is a key reason for writing requirements in natural language?

    <p>It is expressive, intuitive, and universal.</p> Signup and view all the answers

    What is the main purpose of the system requirements section in a requirements document?

    <p>To detail functional and nonfunctional requirements</p> Signup and view all the answers

    Which component should be highlighted in the system architecture overview?

    <p>Reused architectural components</p> Signup and view all the answers

    Which guideline should be followed when writing mandatory requirements?

    <p>Utilize 'shall' for mandatory requirements.</p> Signup and view all the answers

    What is the initial stage in the requirements elicitation and analysis process?

    <p>Requirements discovery</p> Signup and view all the answers

    What could be included in the system models section of a requirements document?

    <p>Graphical system models</p> Signup and view all the answers

    What problem arises from the use of natural language in requirement specifications?

    <p>Lack of clarity can occur.</p> Signup and view all the answers

    Which of the following is NOT a typical stage in the requirements elicitation and analysis process?

    <p>Requirements validation</p> Signup and view all the answers

    What is one potential issue with requirements amalgamation?

    <p>It allows several different requirements to be expressed together.</p> Signup and view all the answers

    Why is the system evolution section important for system designers?

    <p>It helps avoid design decisions that could constrain future changes</p> Signup and view all the answers

    What type of requirements should be defined in the hardware requirements section?

    <p>Minimal and optimal configurations for the system</p> Signup and view all the answers

    What is a common problem faced during requirements analysis?

    <p>Stakeholders express requirements in their own terms</p> Signup and view all the answers

    In structured specifications, what is restricted?

    <p>The freedom of the requirements writer.</p> Signup and view all the answers

    Which statement is true regarding the relationship between system architecture and requirements?

    <p>System architecture may be designed to structure requirements.</p> Signup and view all the answers

    Why might conflicting requirements occur among stakeholders?

    <p>Stakeholders have different goals and interests</p> Signup and view all the answers

    Which of the following elements is NOT typically found in an appendix of a requirements document?

    <p>Table of contents for the document</p> Signup and view all the answers

    What should be included in a requirement to explain its necessity?

    <p>An explanation or rationale.</p> Signup and view all the answers

    What might nonfunctional requirements include?

    <p>Performance standards and usability benchmarks</p> Signup and view all the answers

    During which process activity are requirements documented?

    <p>Requirements specification</p> Signup and view all the answers

    What is a key characteristic of the system interfaces section in a requirements document?

    <p>It should clearly define interfaces to other systems</p> Signup and view all the answers

    Which factor can influence system requirements during elicitation?

    <p>Organizational and political factors</p> Signup and view all the answers

    Why might a specific architecture be chosen for a system?

    <p>To satisfy regulatory requirements or domain needs.</p> Signup and view all the answers

    What may happen to requirements during the analysis process?

    <p>They change and evolve</p> Signup and view all the answers

    What is a major challenge in requirements elicitation concerning stakeholders?

    <p>New stakeholders may emerge unexpectedly</p> Signup and view all the answers

    What is a limitation of using interviews for gathering requirements?

    <p>They may not capture specific domain terminology.</p> Signup and view all the answers

    Which of the following elements is NOT a part of a scenario?

    <p>Information about the system architecture</p> Signup and view all the answers

    What do use cases help identify in an interaction?

    <p>Actors and the description of the interaction</p> Signup and view all the answers

    What is a primary focus of ethnographic studies?

    <p>Observing and analyzing actual work practices</p> Signup and view all the answers

    How does ethnography contribute to understanding requirements?

    <p>By observing cooperation among team members</p> Signup and view all the answers

    Which component enhances use cases by illustrating the sequence of events in a system?

    <p>Sequence diagrams</p> Signup and view all the answers

    One downside of using interviews is that people may assume certain knowledge about their work processes. This can lead to which challenge?

    <p>Inability to articulate necessary details</p> Signup and view all the answers

    What aspect of work does ethnography primarily reveal?

    <p>Work is often richer and more complex than simplified models suggest.</p> Signup and view all the answers

    Study Notes

    Login Page

    • The page displays a login form.
    • Users can sign in with Google or email.
    • The email field is marked with an asterisk (*).
    • The password field is marked with an asterisk (*).
    • Requires a minimum of 8 characters for password.
    • An option to remember the user is available.
    • A login button is provided.
    • An option to create an account for new users.
    • Copyright information for 2020.

    Rewards Page

    • Displays a rewards section with progress data.
    • Shows points, money amounts, dates for the rewards.
    • Total earnings are visible - $162,751.
    • Amount earned for August - $23,827
    • Amount earned for last year - $172,832

    Chapter 4 - Requirements Engineering

    • This is a chapter on requirements engineering.
    • The chapter focuses on functional and non-functional requirements

    Topics Covered

    • Functional and non-functional requirements
    • The software requirements document
    • Requirements specification
    • Requirements engineering processes
    • Requirements elicitation and analysis
    • Requirements validation
    • Requirements management

    Requirements Engineering

    • Establishing system services required from the system and constraints.
    • The detail descriptions of the system services and constraints are generated during this process.

    What is a Requirement?

    • Requirements may range from abstract statements to detailed specifications.
    • Requirements may be the basis of a bid or the contract itself.
    • Requirements need to be open to interpretation and defined in detail simultaneously.

    Types of Requirements

    • User requirements: Statements in natural language plus diagrams of system services and operational constraints. For customers.
    • System requirements: A structured document with detailed description of functions, services, and operational constraints. Defines implementation details. Part of the contract between client and contractor.

    User and System Requirements Definition

    • User requirement definition example 1: The MHC-PMS shall generate monthly management reports showing the cost of drugs prescribed by each clinic during that month.
    • System requirement example 1.1: A summary of the drugs prescribed, their costs, and prescribing clinics is generated on the last working day of each month.
    • System requirement example 1.2: The system automatically generates the report for printing after 17:30.
    • System requirement example 1.3: A report for each clinic lists individual drug names, total prescriptions, dose numbers, and total drug costs.
    • System requirement example 1.4: Separate reports are created for each drug dose unit.
    • System requirement example 1.5: Access to all cost reports is restricted to authorized users on a management access control list.

    Readers of Different Types of Requirements Specifications

    • Readers of User Requirements: Client managers, system end-users, client engineers, contractor managers, system architects
    • Readers of System Requirements: System end-users, client engineers, system architects, software developers

    Functional and Non-functional Requirements

    • Functional requirements: Statements describing system services, how the system reacts to inputs, and its behavior. May also state what the system should not do.
    • Non-functional requirements: Constraints on services/functions (e.g., timing constraints, development process constraints, standards). Often applicable to the entire system instead of individual features or services.
    • Domain requirements: Constraints on the system based on its operational domain.

    Functional Requirements

    • These describe the system functionality or services.
    • They depend on the software's type, expected users, and intended system usage.
    • High-level statements of actions the system should perform are functional user requirements.
    • Detailed descriptions of system services are functional system requirements.

    Functional Requirements for the MHC-PMS

    • Users can search for appointments across clinics.
    • The system generates daily appointment lists per clinic.
    • Staff members are uniquely identified with an 8-digit employee number.

    Requirements Imprecision

    • Problems arise when requirements aren't precisely stated.
    • Ambiguity in requirements may lead to different interpretations by developers and users.
    • Example: The term "search" is ambiguous - does it mean searching across all clinics or just one clinic?

    Requirements Completeness and Consistency

    • In theory, requirements should be both complete and consistent.
    • Complete requirements should describe all needed system facilities.
    • Consistent requirements should have no conflicts or contradictions.
    • In practice, perfect completeness and consistency in requirements documents isn't achievable.

    Non-functional Requirements

    • These describe system properties and constraints. Includes reliability, response time, storage requirements and I/O device capabilities.
    • Process requirements might necessitate the use of a certain IDE, programming language, or development methodology.
    • Non-functional requirements can be more crucial than functional requirements sometimes, as a faulty system is ultimately useless.

    Types of Non-functional Requirements

    • Hierarchical breakdown of non-functional requirements categorized by product, organizational, and external factors.

    Non-functional Requirements Implementation

    • Non-functional requirements can influence the overall system architecture rather than specifically impacting individual components.
    • A single non-functional requirement can necessitate multiple related functional requirements.
    • Existing requirements sometimes need modifying due to newly introduced non-functional requirements.

    Non-functional Classifications

    • Product requirements: Requirements detailing how the delivered product should act (execution speed, reliability).
    • Organizational requirements: Requirements arising from organizational policies or procedures (process standards).
    • External requirements: Requirements arising from outside factors affecting the system and its development (interoperability, legislation).

    Examples of Non-functional Requirements

    • Product requirement example: The MHC-PMS should be accessible in all clinics during normal working hours (Mon-Fri, 08:30-17:30), with no more than 5-second downtime in a single day.
    • Organizational requirement example: MHC-PMS users must log-in with their health authority ID card.
    • External requirement example: The system must follow Health Standard regulations from 2006.

    Goals and Requirements

    • Non-functional requirements can be difficult to precisely define and verify.
    • Goals are general user intentions (e.g., ease of use).
    • A verifiable non-functional requirement has an objective, testable measure, like a specific performance limit.

    Usability Requirements

    • System design should be user-friendly for medical staff.
    • Minimizing user errors during operations is also a design objective.
    • Expected rate of errors made by experienced medical staff after a 4-hour training period is no more than two per hour.

    Properties and Measures

    • Speed: Processed transactions/second, user/event response time, screen refresh time
    • Size: MB, number of ROM chips
    • Ease of use: Training time, number of help frames.
    • Reliability: Mean time to failure, probability of unavailability, rate of failure occurrence, availability
    • Robustness: Time to restart after failure, percentage of events causing failure, probability of data corruption, number of target systems
    • Portability: Percentage of target-dependent statements, number of target systems

    Domain Requirements

    • The domain of operation imposes system requirements.
    • Example: A train control system needs to address braking behaviors in varying weather conditions.
    • Requirements related to the existing, operational domain that need to be satisfied can include specific computations.
    • Failing to meet domain requirements can make the system unworkable.

    Domain Requirements Problems

    • Requirements may be expressed in terms of the application domain.
    • Domain expertise may not be adequately understood by engineering teams.
    • Specialists often consider their domain understanding implicit and don't see a need to explicitly state requirements.

    Key Points

    • Requirements define what a system should do and constrain its operations and implementation.
    • Functional requirements describe the services a system must provide or how computation is performed.
    • Non-functional requirements restrict the system to be developed; these relate to the overall system and not individual features, as they affect emergent properties.

    The Software Requirements Document

    • The official statement or description of requirements expected from system developers.
    • Document should include a user requirement definition and a system requirement specification.
    • Must specify WHAT the system should do; not HOW it should do it.

    Agile Methods and Requirements

    • Agile methods generally argue against formal requirements documents due to rapid changes in requirements, and thus, documents becoming outdated.
    • Agile methods, like XP, often utilize incremental requirements engineering, with requirements expressed as "user stories."
    • Strict pre-delivery analysis and development by multiple teams may benefit from a more traditional approach.

    Users of a Requirements Document

    • System Customers: Use the document to check that needs are met and to specify changes to the requirements.
    • Managers: Use the document to plan the system, bids, and development process.
    • System Engineers: Use the document to understand the specifications to be developed.
    • System Test Engineers: To develop validation tests based on the requirements.
    • System Maintenance Engineers: To understand the system, its components and the interrelationships between them.

    Requirements Document Variability

    • The content varies depending on the system type and development approach.
    • Systems developed incrementally usually have less detail in the document.
    • Formal standards, like IEEE standards, are applicable for large systems engineering projects.

    The Structure of a Requirements Document

    • Preface: Defines the document's target audience, version history and rational behind changes, updates.
    • Introduction: Describes the system's purpose and how it fits into a larger business or organizational context.
    • Glossary: Defines any technical terms used in the document. Stakeholder's experience level of terminology isn't a valid premise.
    • User requirements: Details of the system's services for the user. Nonfunctional requirements are also described here.
    • System architecture: Overview of the design for the anticipated system structure and reuse of modules and components.

    The Structure of a Requirements Document (Chapter Requirements)

    • System specification: Details on functional and non-functional requirements, and interfaces with other systems.
    • System models: Graphical models (object models, data flow models, or semantic models) showcasing relationships among components.
    • System evolution: Presents fundamental assumptions underpinning the system design and considers anticipated future changes and user needs.
    • Appendices: Detailed appendices about the operational details of the developed system, specifics about hardware and database usage.
    • Index : Indexes of diagrams, functions, and other helpful details.

    Requirements Specification

    • Process of creating a formal user and system requirement document.
    • User requirements need to be understandable, as users usually aren't technically skilled.
    • System requirements provide details and technical descriptions.
    • The requirements are important parts of a system's development contract.

    Ways of Writing a System Requirements Specification

    • Natural Language Specifications: Using numbered sentences in natural language, Each sentence expressing a single requirement.
    • Structured Language Specifications: Using structured language based on predefined templates in a form or document, provides information about the requirement aspects.
    • Design Language Specifications: Using a language akin to a programming language, but for specifying and creating an operations model for the system. This approach is less common today.
    • Graphical Notations: Supplemented by text annotations, UML use cases and sequence diagrams, commonly used for depicting functional requirements.
    • Mathematical Specifications: Based on formal mathematical concepts, like finite state models. Although unambiguous, they can be complex, making them sometimes difficult to interpret for customers.

    Requirements and Design

    • Requirements and design are closely linked but theoretically separate concepts.
    • Requirements describe what the system should do, and design describes how.
    • In reality, requirements and design elements are tightly interwoven.

    Natural Language Specification

    • Requirements are usually written using natural language sentences, supplemented by diagrams and tables.
    • Natural language offers expressiveness, intuitiveness, and universality for understanding among customers and users.

    Guidelines for Writing Requirements

    • Use a consistent standard format for all requirements.
    • Use consistent language, using “shall” for mandatory requirements and "should" for desirable ones.
    • Text highlighting and avoiding jargon in descriptions are also helpful guidelines.
    • Explain the rationale for each requirement.

    Problems with Natural Language

    • Clarity can be an issue if precision isn't meticulously balanced with readability.
    • Functional and non-functional requirements are frequently combined, increasing confusion.
    • Multiple independent requirements are sometimes intertwined, hindering interpretation.

    Example Requirements for the Insulin Pump Software System

    • Requirement 3.2: The system should measure blood sugar and deliver insulin every ten minutes, unless changes are occurring slowly.
    • Requirement 3.6: The system should conduct a self-test routine every minute to detect hardware or software errors, and promptly notify the user of any issues.

    Structured Specifications

    • This approach to writing requirements limits the writer's freedom by imposing a standard way of expressing the requirements.
    • Useful for embedded control systems, but less suitable for complex business systems.

    Form-based Specifications

    • Defines a system function or entity, inputs/sources, outputs/destinations.
    • Details related to processing, actions, pre-conditions and/or post-conditions, and/or side effects.
    • Used to provide structured documentation.

    A Structured Specification of a Requirement for an Insulin Pump

    • Function: Computing the insulin dose according to a safe sugar level.
    • Description: Insulin dose computations for safe sugar levels.
    • Input: Current sugar readings, and prior readings.
    • Output: The calculated insulin dose value(s).
    • Destination: Main control loop.

    Tabular Specifications

    • Supplement natural language descriptions.
    • Particularly useful when many alternative courses/actions need to be defined.
    • Used, for instance, in insulin pumps to compute insulin doses based on various blood sugar level rate of change conditions.

    Requirements Engineering Processes

    • Processes vary greatly based on domain, personnel, and the organizing structure of the requirement engineering team itself.
    • Processes often include requirements elicitation, requirements analysis, validation, and management.
    • These processes are typically iterative.

    Requirements Elicitation and Analysis

    • This phase focuses on discovering the requirements.
    • Specialists, clients, developers, and stakeholders are involved during elicitation and analysis activities.
    • Includes initial discovery, classification, structuring and organizing, prioritization and negotiation, and final requirements specification.

    Requirements Elicitation and Analysis (Process Activities)

    • Requirements discovery - gathering of initial information from customers and other relevant stakeholders -
    • Requirements classification and organization - grouping related requirements into coherent clusters of specifications,
    • Requirements prioritization and negotiation - assigning priorities and resolving any conflicts between stakeholders' requirements, and
    • Requirements specification - documenting all the essential requirements gathered through the system, these processes.

    Problems of Requirements Analysis

    • Stakeholders often misunderstand or don't fully articulate their needs or preferences.
    • Stakeholders may have conflicting requirements or priorities.
    • Company organization and/or political factors may affect the outcome of the requirements analysis.
    • There are frequent changes to the requirements based on new stakeholders or changing business contexts.

    Scenarios

    • Scenarios are used to describe the way different stakeholders might interact with the system.
    • Each scenario describes the initial conditions and expectations when the system is used, how users should interact in normal cases, and what might go wrong, and finally, results of the events.

    Scenario for Collecting Medical History in MHC-PMS

    • The description presents a scenario about retrieving a patient's medical history and record.
    • The normal use cases describe how records are fetched and edited and new records are created or existing patient information updates based on the different stakeholders (e.g., receptionists, nurses).
    • The abnormal or error use cases describe how a record retrieval process may fail or when it encounters a patient whose information isn't in the system and suggests what the user must do to get the proper information.

    Use Cases

    • Use cases are a technique for identifying actors (users, entities involved with the system) and their interactions with the system.
    • A set of use cases describes the various possible interactions.
    • High-level graphical models are commonly supplemented by more detailed tabular descriptions.
    • Sequence diagrams provide deeper insights into event processing flow.

    Use Cases for the MHC-PMS

    • Use cases are designed to define the interactions between different stakeholders and the system itself.
    • The different actors include Medical Receptioinists (patients' records, entry and modifications), Nurses (information processing), and Doctors (patient records display and modification).
    • In the diagram, a connection between the entities suggests an interrelationship or interaction between those two entities.

    Ethnography

    • Social scientists observe and analyze real-world work practices.
    • A detailed, deep investigation of an organizational domain which gives insight into the requirements, often showing that real-world work is more complex and nuanced than simple models suggest.
    • It focuses on how people actually work, rather than how they might work in a theoretical sense.

    Scope of Ethnography

    • Requirements derived directly from how people actually work, not from theoretical processes.
    • Requirements are generated based on relationships and cooperation between parties within the organization.
    • Ethnography focuses on understanding the current practices - not on generating completely new features that are not relevant or practically achievable.

    Focused Ethnography

    • A specific development approach for the systems which helps to gain an overall understanding of the system requirements, such as the Air Traffic Control process.

    Ethnography and Prototyping for Requirements Analysis

    • This is a description of a method for analyzing system requirements using the ethnographic approach.
    • The step-by-step methodology involves gathering requirements and performing the analysis and then producing a working prototype to finalize the product under development.

    Requirements Validation

    • Validating requirements entails ensuring that the identified requirements accurately reflect the system's actual needs, and in-depth testing is always essential.
    • Errors found late in the development cycle are much more expensive to fix than early errors.

    Requirements Checking

    • Validity: Checking if the system satisfies customer needs.
    • Consistency: Determining if requirements are not conflicting or contradictory.
    • Completeness: Verifying that all necessary functions have been identified.
    • Realism: Validating feasibility of requirements implementation with budget and resources.
    • Verifiability: Checking that requirements can be tested or verified.

    Requirements Validation Techniques

    • Requirements Reviews: Formal or informal reviews involving multiple stakeholders to validate requirements.
    • Prototyping: Using a working prototype to test and refine requirements
    • Test-case Generation: Developing tests for requirements to check testability

    Requirements Reviews

    • Reviews should occur frequently throughout the requirements definition phase.
    • Involve both customer and developer personnel.
    • Good communications between developers, customers, and users helps solve issues early on.

    Review Checks

    • Verifiability: Can the requirement be tested accurately?
    • Comprehensibility: Can the requirement be easily understood?
    • Traceability: Are the requirements origins clear and traceable?
    • Adaptability: Can the requirements be changed without significant impact on other aspects of the system?

    Requirements Management

    • Process of managing evolving requirements throughout the system development lifecycle.
    • Necessary to track and maintain individual requirements connections in case of future changes.

    Changing Requirements

    • System environments, business priorities, new hardware, and interfaces with other systems change after the system's initial deployment.
    • New regulations and requirements may emerge.
    • System customers and users may have varying/conflicting priorities regarding new or updated system features.

    Changing Requirements (Continued)

    • Large systems often serve diverse user communities and frequently have conflicting or contradictory user needs.
    • The resulting compromise of user requirements after analyzing feedback represents a new state of requirements.
    • Balancing user needs for different users, over time, is an ongoing process, not a finished product.

    Requirements Evolution

    • Requirements evolve over time as understanding of the problem and user needs change.
    • Early understanding and initial requirements will shift or change based on further analysis and new information obtained.

    Requirements Management Planning

    • Establish appropriate level of requirements management detail.
    • Define unique identifiers for each requirement.
    • Establish a change management process that assesses and addresses the impact and cost of changes.
    • Create traceability policies that document the relationships between requirements and system design.
    • Choose tools appropriate for managing scope requirements (spreadsheets, specialized requirements management systems, database systems).

    Requirements Change Management

    • Deciding whether to accept changes made to requirements.
    • Analyze the change request to ensure its validity.
    • Assess the impact and costs of the proposed change using traceability information and general knowledge of the overall system.
    • Implement necessary adjustments to the requirements document and system structure (design and implementation).
    • Ensure that changes are easily integrated into a working system.

    Key Points - Requirements Validation, Discovery, and Management

    • Requirements elicitation and validation are iterative; use techniques like interviews, scenarios, use cases, and ethnography.
    • Requirements should be clearly valid, consistent, complete, realistic, and verifiable.
    • Systems undergo changes due to evolving business and technological environments, hence, proper requirements management is crucial to control and manage these changes.

    Studying That Suits You

    Use AI to generate personalized quizzes and flashcards to suit your learning preferences.

    Quiz Team

    Related Documents

    Chapter 4 - Requirements Engineering PDF

    Description

    Test your knowledge on non-functional requirements related to system performance, reliability, and other characteristics. This quiz covers various aspects, including organizational and external requirements, robustness, and performance metrics. Challenge yourself to see how well you understand the importance of non-functional requirements in system design.

    More Like This

    Use Quizgecko on...
    Browser
    Open
    Browser
    Browser