Requirements Engineering Overview
48 Questions
2 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

Why might non-functional requirements be difficult to verify?

  • They are usually straightforward.
  • They tend to be too specific.
  • They are often not measurable. (correct)
  • They can be easily quantified.

    • What is an example of a general goal for non-functional requirements?

  • Reduce system errors by 50%.
  • The system should support 200 simultaneous users.
  • The system should minimize user errors. (correct)
  • Increase the speed of transaction processing.

    • Which of the following is a measure of the 'Ease of use' property in non-functional requirements?

  • Mean time to failure
  • Processed transactions/second
  • User/event response time
  • Number of help frames (correct)

    • What should a verifiable non-functional requirement include?

    <p>A measurable statement.</p> Signup and view all the answers

    What is one metric used to specify the 'Reliability' of a system?

    <p>Mean time to failure</p> Signup and view all the answers

    How can 'Robustness' be measured in non-functional requirements?

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

    What is an appropriate non-functional requirement for training time?

    <p>Medical staff shall require four hours of training.</p> Signup and view all the answers

    Which of the following is NOT a property for specifying non-functional requirements?

    <p>Functionality</p> Signup and view all the answers

    What is a potential outcome of a security non-functional requirement?

    <p>It may generate additional functional requirements.</p> Signup and view all the answers

    Which of the following best describes product requirements?

    <p>Constraints on the runtime behavior of the software.</p> Signup and view all the answers

    An organizational requirement is influenced by which of the following factors?

    <p>Organizational policies and procedures.</p> Signup and view all the answers

    What is an example of an external requirement?

    <p>The system must adhere to legislative privacy provisions.</p> Signup and view all the answers

    In the Mentcare system, what does the product requirement specify regarding downtime?

    <p>Downtime within normal working hours shall not exceed five seconds in a day.</p> Signup and view all the answers

    Which of the following categories do non-functional requirements NOT belong to?

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

    What is a key characteristic of non-functional requirements?

    <p>They often relate to system services and restrictions.</p> Signup and view all the answers

    Which of the following statements about non-functional requirements is accurate?

    <p>They can dictate both system performance and user operations.</p> Signup and view all the answers

    What is the primary reason disputes between customers and developers arise?

    <p>Delays in system delivery and increased costs</p> Signup and view all the answers

    How should requirements be described to ensure completeness?

    <p>They should cover all necessary facilities required</p> Signup and view all the answers

    What is a common challenge in producing a requirements document for large systems?

    <p>The complexity of the system and diverse stakeholders</p> Signup and view all the answers

    Why might non-functional requirements be more critical than functional requirements?

    <p>Failure to meet them may render the system useless</p> Signup and view all the answers

    What do non-functional requirements NOT encompass?

    <p>Specific algorithms used in development</p> Signup and view all the answers

    How can non-functional requirements impact system architecture?

    <p>They require organizational changes to minimize component communication</p> Signup and view all the answers

    What should be avoided in order to maintain consistency in requirements?

    <p>Conflicts or contradictions in descriptions</p> Signup and view all the answers

    What is a potential issue caused by stakeholders expressing requirements in their own terms?

    <p>Unrealistic demands may arise.</p> Signup and view all the answers

    What constitutes a non-functional requirement?

    <p>The security protocols for user data</p> Signup and view all the answers

    Which activity in the requirements engineering process involves prioritizing conflicting requirements?

    <p>Prioritization and negotiation</p> Signup and view all the answers

    What can influence the system requirements apart from the actual needs of stakeholders?

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

    What is the purpose of the requirements discovery phase?

    <p>To gather information about user and system requirements</p> Signup and view all the answers

    What method involves observing people in their work environment to collect requirements?

    <p>Ethnography</p> Signup and view all the answers

    What may happen to requirements as new stakeholders emerge during the analysis process?

    <p>They may change due to new inputs.</p> Signup and view all the answers

    What is one of the key goals of requirements classification and organization?

    <p>To group related requirements into coherent clusters</p> Signup and view all the answers

    What is a characteristic of informal interviews in requirements engineering?

    <p>They allow for flexibility and natural discussion.</p> Signup and view all the answers

    What is the primary focus of requirements validation?

    <p>Ensuring that the requirements define what the customer wants</p> Signup and view all the answers

    What is a potential consequence of fixing a requirements error after delivery?

    <p>It can cost up to 100 times more than fixing implementation errors</p> Signup and view all the answers

    Which of the following checks for potential conflicts in requirements?

    <p>Consistency</p> Signup and view all the answers

    What is the main purpose of requirements in system design?

    <p>To specify what the system should do</p> Signup and view all the answers

    What does the completeness check ensure in requirements validation?

    <p>Every necessary function requested by the customer is included</p> Signup and view all the answers

    What is a potential challenge of using natural language for writing requirements?

    <p>It can lead to ambiguity and lack of clarity</p> Signup and view all the answers

    What role does prototyping serve in requirements validation?

    <p>It helps check the requirements by using an executable model</p> Signup and view all the answers

    Why is test-case generation important in requirements validation?

    <p>It develops tests that ensure requirements are implementable</p> Signup and view all the answers

    Which statement best describes the relationship between requirements and design?

    <p>Requirements may influence design decisions.</p> Signup and view all the answers

    Which characteristic of requirements ensures that they can be checked and validated?

    <p>Verifiability</p> Signup and view all the answers

    What is one of the suggested guidelines for writing requirements?

    <p>Invent a standard format and use it consistently.</p> Signup and view all the answers

    Which method is NOT a technique for requirements validation?

    <p>Agile development</p> Signup and view all the answers

    What can influence the design requirements of a system?

    <p>Inter-operation with other systems</p> Signup and view all the answers

    What issue arises from requirements amalgamation?

    <p>It can create complex and confused requirements.</p> Signup and view all the answers

    How can regulatory requirements impact system design?

    <p>They may specify the use of an already certified architectural design.</p> Signup and view all the answers

    Which of the following is a benefit of using natural language for writing requirements?

    <p>It is expressive and intuitive for users.</p> Signup and view all the answers

    Study Notes

    Requirements Engineering

    • Functional and non-functional requirements are crucial aspects
    • Requirements elicitation, specification, validation, and change are key processes in requirements engineering
    • Requirements are descriptions of services and constraints on a system's operation and implementation
    • Requirements range from high-level statements of service or system constraints to detailed mathematical specifications
    • Requirements can serve dual roles: as a basis for contract bids (open to interpretation) or contracts themselves (detailed)
    • User requirements are natural language statements and diagrams of system services and operational constraints, written for customers
    • System requirements are structured documents with detailed descriptions of system functions, services, and operational constraints, intended as a client and contractor contact.

    Types of Requirements

    • User requirements are written in natural language and diagrams to explain system functionalities and operational constraints
    • System requirements are detailed documents specifying how the system should function, including its operational aspects.

    User and System Requirements Definition

    • Example of user requirement: The system should generate monthly reports on drug costs prescribed per clinic.
    • An example of a system requirement: Provide monthly summaries of drugs, cost and clinics (by 17:30).
    • Examples of requirements: Specific drug names, total prescriptions, dose numbers, and total costs for each clinic

    Readers of Requirements Specifications

    • Readers of user requirements include client managers, system end-users, client engineers, contractors and system architects
    • Readers of system requirements include system end-users, client engineers, system architects, and software developers

    System Stakeholders

    • Stakeholders are any person or organization affected by a system, having a legitimate interest.
    • Stakeholder types include end-users, system managers, system owners, and external stakeholders
    • Examples of stakeholders in a healthcare system: patients, doctors, nurses, medical receptionists, IT staff, medical ethics managers, health care managers, and medical records staff

    Agile Methods and Requirements

    • Agile methods often argue that detailed system requirements are a waste of time due to rapid changes in requirements
    • Agile methods prefer incremental requirements expressed as "user stories." This approach is practical for business systems but may be troublesome for systems needing pre-delivery analysis (e.g. critical systems) or developed by multiple teams

    Functional and Non-functional Requirements

    • Functional requirements define the services a system should provide/how it reacts to inputs, how it behaves in different situations, and what it should not do
    • Non-functional requirements specify constraints on services/functions, including timing constraints, development process constraints, and standards. These can be critical for functionality

    Functional Requirements

    • Describe system functionality or services in detail and state requirements with high-level statements
    • Examples: User should be able to search appointment lists, system generates a list of patients for each clinic, staff identification by 8-digit employee number

    Requirements Imprecision

    • Ambiguous requirements may be interpreted differently by users and developers
    • Precision in requirements is crucial; its lack can lead to disputes, delays, and increased costs
    • An example is the word "search" in a requirement—it can mean different things across varying clinics

    Requirements Completeness and Consistency

    • Requirements should be complete and consistent
    • Complete requirements include all necessary components/features
    • Consistent requirements have no conflicts or contradictions

    Non-Functional Requirements Implementation

    • Non-functional requirements influence system architecture, rather than individual components
    • Examples: performance requirements may necessitate system components to minimize communication (between components), a security requirement can create related functional requirements

    Non-functional Classifications

    • Product requirements describe constraints in runtime behavior
    • Organizational requirements follow from organizational policies
    • External requirements arise from external factors, for example interoperability or legislative requirements.

    Types of Non-Functional Requirements

    • A diagram shows a hierarchical breakdown of different categories of non-functional requirements

    Examples of Non-Functional Requirements in Mentcare

    • Product requirement: availability of system within working hours (08:30-17:30)
    • Organizational requirement: user authentication using health IDs
    • External requirement: compliance with privacy regulations (e.g., HStan-03-2006-priv)

    Goals and Requirements

    • Non-functional requirements can be hard to state precisely and verify
    • Stakeholders often propose goals, such as ease of use or minimizing errors
    • Requirements should be presented as verifiable quantifiable facts, for instance, "medical staff should accomplish all functions after four hours of training and not exceed 2 errors per hour"

    Metrics for Specifying Nonfunctional Requirements

    • A list of properties and their associated measures required for non- functional requirements—in terms of speed, size, ease of use, reliability, robustness, and portability

    Requirements Engineering Processes

    • Requirements engineering processes vary widely based on application scope, involved parties, and organization design but share common generic activities
    • Activities include elicitation, analysis, validation, and management
    • RE is an iterative process, meaning these processes often overlap

    Requirements Elicitation and Analysis

    • Elicitation and analysis (or discovery) aims to understand stakeholder work and to identify new ways a system can support their work.
    • May involve end-users, managers, maintainance engineers, domain experts, trade unions, etc. (called stakeholders)
    • Stakeholders offer insights into application domains, services, operational constraints (including system performance and hardware constraints), and other systems.

    Problems with Requirements Elicitation

    • Potential problems: Stakeholders might not know their true needs, conflicting requirements, changing requirements during analysis, emerging stakeholders, and changing business circumstances.

    Process Activities

    • Requirements discovery: interaction with stakeholders, also identifying domain requirements, followed by classifying requirements and organizing them into clusters.
    • Prioritization and negotiation: Prioritize and resolve conflicting requirements.
    • Requirements specification: documenting final requirements and inputting into the next spiral iteration.

    Requirements Discovery

    • Gathering information regarding required/existing systems and distilling user/system requirements from this information
    • Interaction is needed across stakeholders (from managers to regulators)
    • Discovery methodologies involve interviewing and ethnography

    Interviewing

    • Used in both formal and informal ways with stakeholders.
    • Interview types include closed (pre-determined question lists/open (open-ended explorations of issues)).
    • Effective interviewing requires mixed question types, openness, and good listening to stakeholders.
    • Common problems include overly technical language and issues with articulating known domain requirements

    Ethnography

    • An observational technique to understand operational processes and derive supporting requirements for processes.
    • Helps identify implicit system requirements reflecting how people work, and requirements derived from work cooperation and awareness of other people's work (and awareness).

    Stories and Scenarios

    • Scenarios/user stories are real-life illustrations of system use
    • Stories describe how a system is used for specific tasks, allowing stakeholders to relate to practical situations and comment on the story.
    • Stories can be used in interviews to elicit further requirements details and scenarios describe specific actions, conditions, interactions, and consequences.

    Photo Sharing in the Classroom (iLearn) Story

    • This is a use-case example highlighting how a photo-sharing system enables pupils' gathering and sharing of stories about the fishing industry in a Scottish village.

    Scenarios

    • Structure of user story for use cases to describe the big picture
    • Scenarios can detail specific use cases, including the beginning, the normal action sequence, what can go wrong, other concurrent activities, and the end state

    Uploading Photos (iLearn)- Scenario

    • Assumptions: User uploads digital photos, logged into a photo sharing platform (KidsTakePics), and has access to the required system.
    • Normal conditions show the steps for selecting images, naming, and storing photos and provide automatic notification for moderation requirements.
    • Problems/errors are addressed if a selected moderator doesn't exist, when users upload photos with similar names, or additional actions/activities involving uploading approvals.

    Scenario for Collecting Medical History in MentCare

    • Assumptions: there is a patient record, user is a nurse.
    • Normal conditions show searching patients, adding medical histories, and following prompts to enter details.
    • Problems/errors addressed such as missing patient records, improper input, or unwillingness of patient to provide information

    The Software Requirements Document

    • The official document that defines the system's requirements for developers
    • Should contain: definition of user requirements and specification of system requirements
    • Is not a design document and aims to clarify "what" the system needs to do, rather than "how" it should do it

    Users of a Requirements Document

    • The users of the requirements document include system customers, managers, and system engineers; each user has different needs when interacting with the requirements document

    Requirements Document Variability

    • The complexity in communicating and specifying requirements is balanced by user and customer requirements, which are often different from each other in focus.
    • Level of detail depends on the nature of the system.
    • Outsourcing projects frequently rely on a highly detailed document

    The Structure of a Requirements Document (Based on IEEE Standard)

    • The structure covers various aspects of a requirement document: preface, introduction, glossary, user requirements, system architecture description, system evolution, and appendices.

    Requirements Validation

    • This aspect of requirements engineering aims to show that the user requirements correctly reflect the customers needs.
    • Overlaps with analysis, as it's about problems in the requirements and requires validation at crucial times.

    Validation checks include validity, consistency, completeness, realism, and verifiability for accurate and detailed requirements.

    Requirements Validation Techniques

    • Requirements reviews use systematic analysis techniques, also prototyping provides an executable system representation to check requirements, and test-case generation aims to ensure requirements are testable

    Requirements Reviews

    • Regular reviews are essential during requirement definition
    • This includes reviews done by clients, contractors, developers, customers, and users. Useful for early problem identification and resolution, both formally (using written documents) and informally

    Review Checks

    • Verifiability: are the requirements testable?
    • Comprehensibility: are the requirements understandable?
    • Traceability: is the origin of requirements clear?
    • Adaptability: can requirements change with minimal impact on other areas?

    Requirements Change

    • Business and technical environments change in multiple ways and impact systems after implementation.
    • Users often have different needs and conflicting requirements.
    • System needs adaptation and frequent changes

    Requirements Evolution

    • Requirements evolving over time needs to be anticipated in system development
    • The initial understanding of a problem changes over time, leading to changes in requirements

    Requirements Management

    • Managing evolving and changing user requirements is part of requirements engineering
    • Tracking individual requirements and their relationships is crucial to assess the impact of changes, and establishing processes/procedures for managing future changes

    Requirements Management Planning

    • Determining the level of requirement management detail is needed
    • Establishing criteria of identification, change management processes, and traceability policies
    • Specifying how requirements are linked within the system and how changes affect each other

    Requirements Change Management

    • Includes stages of analyzing, specifying, and implementing change
    • Traceability/general system knowledge/cost analysis are used.
    • System documents and design are modified, aiming for smooth implementation.

    Studying That Suits You

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

    Quiz Team

    Related Documents

    Requirements Engineering (CSE 322) PDF

    Description

    This quiz explores the crucial aspects of requirements engineering, including functional and non-functional requirements. It covers key processes such as elicitation, specification, validation, and the dual roles of user and system requirements. Test your understanding of how requirements serve as both foundational elements for contracts and detailed specifications.

    More Like This

    Use Quizgecko on...
    Browser
    Open
    Browser
    Browser