Classic Waterfall Model Quiz

Software Development Models

• Classic Waterfall Model: Sequential phases including Requirements, Design, Code & Unit Test, Integration, Test, Deployment, and Maintenance; produces documents at each stage such as the Software Requirements Specification (SRS) and Software Architecture Document (SAD).

• V-Shaped Model: Introduced by Paul Rook in the 1980s; emphasizes testing throughout each phase; requires completion of a phase before moving to the next; visual representation shows upward bending process steps.

• Spiral Model: Developed by Barry Boehm in 1986; consists of four stages evaluated in a cyclic manner: Objectives identification, Risk evaluation and resolution, Product development, and Verification of the next product level.

Requirement Engineering Activities

• Requirements Inception: Gathering requirements through user and stakeholder engagement.
• Requirements Identification: Recognizing and documenting new requirements.
• Requirements Analysis and Negotiation: Reviewing requirements and resolving stakeholder differences.
• Requirements Definition: Detailing both functional and non-functional requirements.
• Requirements Specification: Creating a formal requirements document.
• Requirements Validation: Ensuring that documented requirements align with stakeholder needs.
• Requirements Verification: Confirming that the final product meets the specified requirements.
• Requirements Management: Overseeing changes in requirements during development and after deployment.

Traits of Good Requirements

• Clarity and Simplicity: Requirements should be clear, concise, and comprehensible to non-technical stakeholders; ideally should be single-phrased with no more than 30-50 words.

• Completeness: All necessary information must be included, leaving no ambiguity regarding system functions or measurement units.

• Consistency: Requirements must not contradict one another; they should agree on specific details like compliance standards (e.g., TCP/IPv6).

• Avoidance of Ambiguity: Requirements should not involve vague terms; each requirement must be precise and measurable to avoid multiple interpretations.

Examples of Good vs. Bad Requirements

• Good Requirement: "The system shall cease automatic steering upon receipt of a State Change Message indicating 'Off.'"
• Bad Requirement: "All screens shall appear on the monitor quickly." (This is vague and non-specific about timing.)

CSU System Architecture Layers

• The CSU System comprises multiple layers: Computer, Communication, Mobile, and Facilities.
• Under each layer, different types of design items are categorized, including Hardware Design Items and Software Design Items.
• Configuration items are represented as DP, VPS, VTC, AVS, HWCIs (Hardware Configuration Items), CSCIs (Software Configuration Items), and SIs (Support Items).
• Subsystems include components like CSU1, CSU2, LMS (Logistics Management System), TRN (Training Management System), and EDE.

Traits of Good Requirements

• Requirements must be traceable upward to the original specifications and downward to design, implementation, and testing.
• Traceability matrices are essential in tracking relationships between child and parent requirements.
• Each requirement should also detail its integrations and corresponding testing procedures, ensuring all components meet specified standards.

Concept of Operations (ConOps) Document

• The ConOps document outlines how customers or users plan to utilize the product without detailing how it operates or setting requirements.
• It guides the engineering team by providing insights into user needs and expectations, establishing a clear rationale for the requirements.
• ConOps ensures consistency in customer expectations over time.

Trace Tables

• Trace tables document each requirement alongside its parent requirement(s), outlining test procedures and proposed test methods.
• Test methods include demonstration (D), analysis (A), testing (T), and inspection (I).
• Test levels indicate the type of evaluation, such as Factory Acceptance Test (FAT), Software Functional Qualification Test (CSCI), and System Test.

System Requirements Flowdown

• A-level system requirements flow down to B-level subsystems and configuration items, helping maintain a clear hierarchical structure of requirements.
• This flowdown ensures that every subsystem and configuration item aligns with overarching system goals and specifications.

Test your understanding of the Classic Waterfall Model and its phases, including how the Software Requirements Specification (SRS) flows into the architecture discipline. This quiz covers the key products and work involved at each phase of the model.