Requirements Elicitation

  1. Define Operational Concept Description (OCD).
    The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used.
  2. CASE
    Computer-Aided Software Engineering
  3. CDRL
    Contract Data Requirements List
  4. CSCI
    Computer Software Configuration Item
  5. What is the purpose of Requirements Development (RD)?
    The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements
  6. What are the specific practices of Requirements Development (RD)?
    • Specific Practices by Goal
    • 1 Develop Customer Requirements
    • 1.1 Elicit Needs
    • 1.2 Transform Stakeholder Needs into Customer Requirements

    • 2 Develop Product Requirements
    • 2.1 Establish Product and Product Component Requirements
    • 2.2 Allocate Product Component Requirements
    • 2.3 Identify Interface Requirements

    • 3 Analyze and Validate Requirements
    • 3.1 Establish Operational Concepts and Scenarios
    • 3.2 Establish a Definition of Required Functionality and Quality Attributes
    • 3.3 Analyze Requirements
    • 3.4 Analyze Requirements to Achieve Balance
    • 3.5 Validate Requirements
  7. What is the purpose of Requirements Management (REQM)?
    The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.
  8. What is a product requirements document (PRD)?
    A product requirements document (PRD) is a document written by a company that defines a product they are making, or the requirements for one or more new features for an existing product.

    A PRD should generally define the problems that a product (or product feature) must solve, but should avoid defining the technical solution to those problems. This distinction allows engineers to use their expertise to provide the optimal solution to the requirements defined in the PRD.
  9. What types of requirements should be included in the PRD?
    Requirements, including:

    • functional requirements
    • usability requirements
    • technical requirements
    • environmental requirements
    • support requirements
    • interaction requirements
  10. What does SRS stand for?
    Software requirements specification (SRS)
  11. What is a Software requirements specification (SRS)?
    • A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints) .
    • The software requirements specification document enlists all
    • necessary requirements that are required for the project development.
    • To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer.
  12. What is requirements elicitation?
    In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering.
  13. In requirements elicitation, what indicates problems of scope?
    • The boundary of the system is ill-defined or
    • the customers/users specify unnecessary technical detail that may
    • confuse, rather than clarify, overall system objectives.
  14. What are Goldsmith's 6 steps of requirements elicitation?
    Identify the real problem, opportunity or challenge.

    Identify the current measure(s) which show that the problem is real.

    Identify the goal measure(s) to show the problem has been addressed and the value of meeting it.

    Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly.

    Define the business "whats" that must be delivered to meet the goal measure(s).

    Specify a product design how to satisfy the real business requirements
  15. What does IRS stand for?
    Interface Requirements Specifications
Card Set
Requirements Elicitation