Software Requirements Gathering Quiz
91 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

What is the purpose of Section 2?

  • To provide detailed technical specifications.
  • To analyze system performance metrics.
  • To inform non-technical stakeholders about the general characteristics of the software system. (correct)
  • To outline coding standards and practices.

    • Section 3 is aimed at non-technical stakeholders.

    False

    Who are the primary audiences for Section 2?

    Non-technical stakeholders such as customers and management personnel.

    Section 3 is targeted towards stakeholders who are __________ and require a complete low-level understanding of the software system.

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

    Match the section with its target audience:

    <p>Section 2 = Non-technical stakeholders Section 3 = Technical stakeholders</p> Signup and view all the answers

    What is crucial for a successful project?

    <p>Interacting and listening to the customer</p> Signup and view all the answers

    Poorly documented requirements can contribute to project failures.

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

    What does IEEE 830-1998 Specification help with?

    <p>Documenting requirements properly</p> Signup and view all the answers

    To ensure project success, it is important to _______ customer requirements precisely.

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

    Match the roles with their respective responsibilities in a project:

    <p>Business Analyst = Understands customer needs Architect = Designs the system Developer = Implements the design Operations = Installs the solution</p> Signup and view all the answers

    What should project participants focus on after gathering requirements?

    <p>Accurately documenting requirements</p> Signup and view all the answers

    Listening to the customer is optional for gathering requirements.

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

    Name one common consequence of inadequate requirements gathering.

    <p>Project failure</p> Signup and view all the answers

    Successful projects require many _______ and roles to be effective.

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

    Which of the following is NOT a characteristic of good requirements?

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

    Which organizational model focuses on the different classes of users interacting with the software?

    <p>User class</p> Signup and view all the answers

    All software systems should be organized using the functional hierarchy model.

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

    Name one way that specific requirements can be organized based on stimulus.

    <p>By describing the requirements on a per stimulus (input) basis.</p> Signup and view all the answers

    In a Patient Monitoring System, the software interacts with different objects such as patients, sensors, and __________.

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

    Match each organizational model with its description:

    <p>System Mode = Different modes of operation within the software Stimulus = Requirements organized per input Functional hierarchy = Organized by functional areas of the software Response = Requirements organized per output</p> Signup and view all the answers

    Which characteristic of a good SRS ensures it can easily be understood by the end-user?

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

    A requirements specification should be prescriptive to guide design decisions.

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

    What is one benefit of using prototypes during the requirements gathering phase?

    <p>Prototypes help customers visualize the system and provide feedback.</p> Signup and view all the answers

    An effective SRS should be __________ to allow for modifications in the future.

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

    Match the following SRS characteristics with their definitions:

    <p>Understandable = Can be easily interpreted by stakeholders Precise = Contains exact specifications with no ambiguity Verifiable = Can be confirmed through testing methods Consistent = Does not contain conflicting information</p> Signup and view all the answers

    What section is NOT typically included in the structure of an SRS?

    <p>User Manual</p> Signup and view all the answers

    Every requirement in an SRS can restrict design choices.

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

    What is a potential outcome if an SRS is based on a prototype?

    <p>It tends to undergo less change during development.</p> Signup and view all the answers

    What is the primary purpose of the SRS?

    <p>To define the purpose and scope of the software system</p> Signup and view all the answers

    The intended audience for an SRS includes only software developers.

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

    What should Section 1.2 of the SRS include?

    <p>It should identify the product to be produced by name and include a brief explanation of what the product will and will not do.</p> Signup and view all the answers

    The SRS is usually the _____ section in the entire document.

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

    Match the following sections with their focus:

    <p>Section 1 - Introduction = About the SRS itself Section 1.1 - Purpose = Defines the purpose of the SRS Section 1.2 - Scope = Identifies the product to be produced Section 1.3 - Definitions = Clarifies terms and acronyms used</p> Signup and view all the answers

    Which of the following is NOT included in the specific requirements of the SRS?

    <p>User Characteristics</p> Signup and view all the answers

    The scope of the SRS should include detailed specifications about the software features.

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

    Who are the intended readers of an SRS?

    <p>Executives, customers, product managers, developers, etc.</p> Signup and view all the answers

    What does 'apportioning' refer to in the context of SRS?

    <p>Putting off certain requirements until future versions</p> Signup and view all the answers

    An SRS can contain TBD items as long as they are documented appropriately.

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

    What is the main purpose of the Specific Requirements section in the SRS?

    <p>To provide all requirements at a level of detail sufficient for designers and testers.</p> Signup and view all the answers

    All requirements in an SRS should be uniquely __________.

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

    Match the key terms with their definitions:

    <p>TBD = To Be Determined SRS = Software Requirements Specification Apportioning = Postponing certain requirements Traceability = Ability to track requirements throughout the development process</p> Signup and view all the answers

    Which of the following is NOT a guideline for documenting requirements?

    <p>Include as many TBDs as possible</p> Signup and view all the answers

    It is acceptable to mention apportioned requirements in multiple sections of the SRS.

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

    What should be done if a requirement is known to be delayed at the time of writing the SRS?

    <p>It should be documented as an apportioned requirement.</p> Signup and view all the answers

    What is one crucial step to ensure project success?

    <p>Accurate documentation of customer requirements</p> Signup and view all the answers

    Interacting with the customer is optional during the requirements gathering process.

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

    Name a role that is involved in ensuring the success of a software project.

    <p>Business Analyst</p> Signup and view all the answers

    To properly document customer requirements, you need to be __________ and accurate.

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

    Match the roles to their descriptions:

    <p>Business Analyst = Gathers requirements from the customer Developer = Implements the design in code Architect = Designs the software architecture Project Manager = Oversees project progress and deadlines</p> Signup and view all the answers

    What does IEEE 830-1998 Specification aim to improve?

    <p>Documentation of requirements</p> Signup and view all the answers

    Successful projects require many _______ and roles.

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

    Match the following document sections with their focuses:

    <p>Introduction = Purpose and scope of the document Specific Requirements = Details about the software functionalities Appendices = Supplementary information and references Glossary = Definitions of terms used within the document</p> Signup and view all the answers

    What should Section 1.1 of the SRS specify?

    <p>The intended audience for the SRS</p> Signup and view all the answers

    The scope of the SRS should include a detailed breakdown of specific features.

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

    What is the primary focus of the Specific Requirements section in the SRS?

    <p>To outline the detailed requirements for the software system.</p> Signup and view all the answers

    The entire section including sub-sections in the SRS describes the __________ itself.

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

    Match each section of the SRS with its focus:

    <p>Section 1 = Introduction and purpose Section 2 = Product characteristics Section 3 = Specific requirements Appendices = Additional supporting information</p> Signup and view all the answers

    What should the product scope briefly explain?

    <p>What the product will and will not do</p> Signup and view all the answers

    Section 1 is typically the largest section in the SRS document.

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

    Name one characteristic that a good requirements specification should have.

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

    Which type of interface describes how the software interacts with external systems?

    <p>System Interfaces</p> Signup and view all the answers

    A user interface should only be described in words without UI mock-ups.

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

    What is a block diagram also known as?

    <p>context diagram</p> Signup and view all the answers

    The software must describe how it interfaces with __________ to provide functionality.

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

    Which of the following aspects is NOT typically included in section 2.1?

    <p>Database Design</p> Signup and view all the answers

    Match the following types of interfaces with their descriptions:

    <p>System Interfaces = Interaction with other external systems User Interfaces = Interaction between the user and the software Hardware Interfaces = Direct interaction with hardware components Software Interfaces = Interaction with other software applications</p> Signup and view all the answers

    Communications interfaces detail the logical characteristics of each UI between the software and the user.

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

    What must be specified when describing software interfaces?

    <p>name, version, source, documentation</p> Signup and view all the answers

    What does the acronym IPO stand for in the context of requirements specification?

    <p>Input / Process / Output</p> Signup and view all the answers

    External Interfaces in the requirements specification do not need to detail the inputs and outputs.

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

    What section of the SRS contains a major portion of the software's requirements?

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

    The section describes how the system interacts with other systems, underlying hardware, and software.

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

    Match the following subsections of Specific Requirements with their descriptions:

    <p>3.1 = External Interfaces 3.2 = Functions 3.3 = Performance Requirements 3.4 = Logical Database Requirements</p> Signup and view all the answers

    Which of the following is NOT a required subsection under the Specific Requirements?

    <p>System Design Features</p> Signup and view all the answers

    The purpose of specifying the format of input/output is optional in the interface description.

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

    What is a major aspect to consider when documenting External Interfaces?

    <p>Input/output names, descriptions, sources, formats, and relationships.</p> Signup and view all the answers

    What is specified by the functional requirements of software?

    <p>The actions that must take place in processing inputs and generating outputs</p> Signup and view all the answers

    Functional requirements can include responses to abnormal situations.

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

    What should be documented in measurable terms within performance requirements?

    <p>Static and dynamic numerical requirements</p> Signup and view all the answers

    The performance requirements include the number of users and the amount of ______.

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

    Match the following types of requirements with their examples:

    <p>Static requirements = Number of users Dynamic requirements = Transactions processed in given time Functional requirements = Validity checks on inputs Database requirements = Data organization specifications</p> Signup and view all the answers

    From whom should performance requirements be gathered?

    <p>The customer who describes the system's behavior</p> Signup and view all the answers

    What should not be done when specifying requirements for software?

    <p>Make up requirements</p> Signup and view all the answers

    Every system has data that needs to be retained and manipulated.

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

    What must be ensured in an SRS according to the IEEE Specification?

    <p>There must not be any TBDs in the document.</p> Signup and view all the answers

    Each requirment in the SRS should be documented in multiple sections.

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

    What does the term 'apportioning' refer to in the context of an SRS?

    <p>The putting off of requirements until future versions.</p> Signup and view all the answers

    An SRS must ensure that all requirements are uniquely __________.

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

    Which of the following is NOT a principle to consider when documenting requirements?

    <p>Requirements should describe outputs only.</p> Signup and view all the answers

    What should be documented if there are unknowns at the time of writing the SRS?

    <p>The TBD items</p> Signup and view all the answers

    It's acceptable to document a requirement that is apportioned in multiple sections of the SRS.

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

    Study Notes

    IEEE Software Requirements Specification (SRS)

    • The IEEE developed a standard document for software requirements (SRS) in the late 1990s to standardize how requirements for software are documented.
    • The SRS is structured into 3 main sections (Section 1 – Introduction, Section 2 - Overall Description, and Section 3 - Specific Requirements).
    • Each section has a number of sub-sections, tailored to specific purposes in communicating system requirements.

    Section 1: Introduction

    • This section details aspects of the SRS itself.
    • This section includes the purpose of the SRS, who should read it, how to understand it, the research and sources to create it, and defines the terms and acronyms used (acronyms and terms are not universally known - so need definition).
    • As a result, Section 1 is typically the smallest section.
    • Includes a Table of Contents, giving a roadmap of the document.

    Section 1.1: Purpose

    • Outlines the purpose of the SRS document.
    • Explains why the document is being written and what specific system or product the document describes.
    • Identifies the intended audience for the SRS (executives, customers, product managers, developers).
    • Key: Why is the document being created; what is it describing; who is it for?

    Section 1.2: Scope

    • Clearly identifies the product being developed/produced via its name.
    • Briefly describes what the product does (and potentially what it won't).
    • Details the benefits, objectives, and goals.
    • Maintains consistency with higher-level specifications.
    • Keep the description general and avoid too much detail; aim for a concise summary that would suit a marketing brief.

    Section 1.3: Definitions, Acronyms, and Abbreviations

    • Defines all terms, acronyms, and abbreviations in the SRS.
    • The expectation is that not all members of the audience will be familiar with the technical nomenclature.

    Section 1.4: References

    • Includes a complete list of documents referenced within the SRS.
    • Provides titles, report numbers, dates, and publishing organizations for referenced documents.
    • Follows the APA standards.
    • Specifies the source of each referenced document.

    Section 1.5: Overview

    • Details the contents of the rest of the SRS.
    • Gives details on the organization of the SRS.
    • The document aims to inform the intended audience how to read and understand the SRS.

    Section 2: Overall Description

    • This section provides a general overview (a summary version) of the software functionality.
    • This section highlights the factors that affect the product (and its requirements).
    • Avoid deep technical descriptions; focus on the what instead of the how.
    • This section does not contain specific requirements.
    • This section provides context and background for requirements detailed in Section 3.
    • Conveys a holistic understanding for stakeholders who are not technical.
    • Includes a high-level overview or context diagram.

    Section 2.1: Product Perspective

    • Describes the software product in the bigger picture, within the context of other systems/products.
    • Explains whether the software is a standalone product or if it's part of a larger system.
    • Provides references to supporting documentation.
    • Includes diagrams of system components (context diagram) and their connections.

    (All subsections under section 2.1 are listed and described appropriately)

    Section 2.2: Product Functions

    • Provides a high-level summary of the software's features and functionality.
    • Identifies the major functions of the software without going into detailed specifics.
    • Highlights the system's capabilities; what does it do?

    Section 2.3: User Characteristics

    • Describes the characteristics of the users.

    Section 2.4: Constraints

    • Details any limitations to the software, such as regulatory policies, hardware restrictions, or interfacing constraints.
    • Identifies anything that could affect the options for software architects and developers.

    Section 2.5: Assumptions and Dependencies

    • Outlines assumptions about other systems or external dependencies that may affect the software's requirements.
    • Risks that relate to the successful implementation.

    Section 2.6: Apportioning of Requirements

    • Outlines requirements that may be delayed to future software versions.
    • Specifies the placement of the requirement within the document to highlight the requirement.

    Section 3: Specific Requirements

    • This section details the software's functional requirements in detail in multiple subsections.

    (All subsections under section 3 are listed and described appropriately)

    Studying That Suits You

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

    Quiz Team

    Related Documents

    IEEE 830-1998 Software Requirements Specification PDF

    Description

    Test your knowledge on the principles and practices of requirements gathering in software projects. This quiz covers key concepts, roles, and the importance of precise documentation in ensuring project success. Perfect for project managers and team members alike.

    More Like This

    Use Quizgecko on...
    Browser
    Open
    Browser
    Browser