Unit 1: Software Engineering Foundations & SDLC - Practice Quiz

The 'Software Crisis' was a term coined in the late 1960s to describe the difficulties in developing large, useful software. This crisis highlighted the need for a more disciplined, managed, and engineered approach to software development.

SDLC stands for Software Development Life Cycle, which is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software.

The Waterfall Model is the most traditional SDLC model. It is a sequential design process in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

Functional requirements define what a system is supposed to do. They describe the functions and services of the system. In this case, 'adding items to a cart' is a specific function of the software.

Non-functional requirements define how a system is supposed to be. They specify the quality attributes of a software system, such as performance, security, and usability. Handling a certain number of users is a performance requirement.

The Prototyping Model involves creating a working model of the system to get feedback from users. It's ideal for situations where requirements are unclear, as the prototype helps clarify what the users actually want.

The SDLC almost always begins with the Requirement Gathering and Analysis phase, where the needs of the stakeholders are collected and understood to define the scope and purpose of the project.

Interviews, surveys, brainstorming sessions, and workshops are all common techniques used during the requirement gathering phase to understand what the system needs to do from the perspective of its users and stakeholders.

The SRS document is the official statement of what the system developers should implement. It clearly and precisely describes all functionalities, features, and constraints of the system to be built.

The V-Model is an extension of the Waterfall Model. It demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. For every development phase, there is a corresponding testing phase.

The Spiral Model is a risk-driven model. Each loop or iteration in the spiral starts with identifying objectives and constraints, followed by risk analysis and the development of a prototype. This makes it suitable for large and complex projects.

Agile methodologies are built on the principles of iterative development. Work is done in small increments (iterations or sprints), allowing teams to adapt to changing requirements and deliver value to the customer faster.

Verification is the process of evaluating products of a development phase to find and correct defects. It answers the question, "Are we building the product right?" by checking against the specifications.

Validation is the process of checking if the final product meets the customer's expectations and requirements. It answers the question, "Are we building the right product?"

A Sprint is the basic unit of development in Scrum. It is a time-boxed iteration during which a specific, usable, and potentially releasable product increment is created.

Software engineering is the application of a systematic, disciplined, and quantifiable approach (i.e., engineering principles) to the development, operation, and maintenance of software.

After gathering and analyzing all the requirements, the findings are formally documented in the Software Requirements Specification (SRS), which becomes the guide for the subsequent phases of development.

Security is a non-functional requirement because it describes a quality or characteristic of the system (how it should be), rather than a specific function it performs (what it should do). User registration, payments, and report generation are all functions.

DevOps aims to bridge the gap between Development (Dev) and Operations (Ops) teams, fostering a culture of collaboration and automation to build, test, and release software faster and more reliably.

The IEEE Standard 830-1998 provides a recommended practice for writing Software Requirements Specifications. It offers a template and guidelines for creating a high-quality SRS document that is clear, complete, and unambiguous.

The Spiral Model is specifically designed for risk-driven projects. It combines elements of prototyping (addressing unclear requirements) and the Waterfall model (systematic approach) while explicitly focusing on risk analysis in each iteration. This makes it ideal for projects with high technical and requirement uncertainty.

This requirement does not describe a function the user performs (like 'transfer funds'). Instead, it specifies a quality attribute or constraint on the system's operation—how it must protect data. This falls under the category of non-functional requirements, specifically security.

For complex, tacit knowledge that users cannot easily verbalize, direct observation (shadowing) is a powerful technique. It allows analysts to understand the actual workflow, environmental factors, and implicit steps that might be missed in interviews or questionnaires.

The key feature of the V-Model is its V-shape, which illustrates the correspondence between the development activities on the left side (downward slope) and the testing activities on the right side (upward slope). For example, Acceptance Testing is planned during the Requirements phase, and System Testing is planned during the Architectural Design phase.

A requirement is verifiable if there exists some finite, cost-effective process to check that the software product meets the requirement. 'User-friendly' is subjective and cannot be objectively tested without further clarification (e.g., 'A new user must be able to complete task X in under 2 minutes').

A core principle of Scrum is that the Sprint Backlog is locked during the Sprint to allow the Development Team to focus on their commitment. Changes that disrupt the Sprint Goal are not allowed. The proper way to introduce new work is to add it to the Product Backlog for prioritization in a future sprint.

The Software Crisis, characterized by projects being over budget, behind schedule, and unreliable, highlighted the need for a more structured and disciplined approach. This led to the 1968 NATO conference that coined the term "Software Engineering" and established it as a formal engineering discipline.

While GDPR compliance will influence the design of many functions, the requirement itself is a high-level constraint imposed by an external legal body. It's a non-functional requirement because it defines a rule the system must adhere to, rather than a specific piece of functionality it must perform.

The Incremental Model is based on developing and delivering the product in functional parts, or 'increments'. This allows a core product to be delivered quickly, with more functionality added in later releases, which perfectly matches the scenario described.

Consistency means that no set of individual requirements within the SRS is in conflict with another. Contradictory requirements, as described in the example, are a direct violation of this principle.

The primary purpose of a 'throwaway' or 'rapid' prototype is to serve as a learning tool to clarify requirements. It is typically built quickly with little regard for quality, architecture, or maintainability. Therefore, once it has served its purpose, it is discarded to avoid building the final system on a poor foundation.

The Maintenance phase begins after the software has been deployed. It involves all activities required to keep the system operational and useful, including fixing bugs (corrective), adding new features (perfective), and adapting to new operating systems or regulations (adaptive).

JAD (or similar facilitated workshops like FAST) is a technique that brings together key stakeholders, users, and developers in a collaborative, structured meeting. Its primary goals are to resolve differences, build consensus, and define requirements collectively in a shorter period than individual interviews would allow.

Functional requirements define what the system should do—its features and functions. Adding an item to a cart is a specific action or function. The other options describe non-functional qualities: performance (loading time), availability (uptime), and constraints (branding).

Continuous Integration (CI) is a core DevOps practice where developers frequently integrate their work. Each integration is then automatically verified by a build and automated tests. This helps to detect integration errors as quickly as possible, improving software quality and development speed.

The Design phase is where the requirements specified in the SRS are translated into a blueprint for constructing the software. This involves creating models of the system's architecture, components, interfaces, and data, such as DFDs and database schemas.

The Waterfall model's sequential nature means that each phase must be fully completed before the next begins. This makes it very difficult and costly to go back and change requirements after the design or implementation phase has started, which is a major drawback for projects where requirements are likely to evolve.

Traceability is the quality that allows one to follow the life of a requirement. A traceability matrix is a tool used to demonstrate that each requirement has a source (backward traceability) and is being addressed in the system design and verified by a test case (forward traceability), ensuring no requirements are missed.

Statement 1 describes a core function of the system—what it does. This is a functional requirement. Statement 2 describes how well the system must perform that function under a specific load. This is a non-functional requirement related to performance and scalability.

During Sprint Planning, the Scrum Team collaborates to select a set of high-priority items from the Product Backlog and creates a plan for how to implement them. This selected set of items, along with the plan to deliver them, forms the Sprint Backlog for the upcoming Sprint.

The Spiral model is uniquely suited for projects with high-risk factors, both technical and requirement-related. Each loop of the spiral involves identifying risks, developing a prototype or model to resolve those risks, and evaluating the results. This allows the project to tackle the UI requirement uncertainty (via prototyping) and the algorithmic technical uncertainty (via analysis and modeling) within the same iterative risk-driven framework. Scrum prioritizes by business value, which may not directly address the highest technical risks first. The V-model and Waterfall are too rigid for evolving requirements and high technical uncertainty.

This is a hard question because the requirement itself is well-formed. However, Correctness in an SRS means that every requirement stated must be one that the software should meet, reflecting the actual needs. If a requirement contradicts a higher-level business goal or real-world fact, the SRS is not correct, even if the requirement itself is verifiable and traceable. It's a failure of validation ('building the right thing') rather than verification ('building the thing right').

This is a multi-faceted requirement. The core function is 'process payments', but the statement specifies how this must happen: via a third-party gateway. This makes it an external interface requirement, which is a type of functional requirement. However, the clause 'that is PCI-DSS compliant' imposes a non-functional constraint (specifically, a security and regulatory compliance constraint) on that interface. Therefore, this option is the most precise and complete classification.

The key innovation of the V-Model is not just that it shows testing phases, but that it explicitly links each development phase on the left side of the 'V' to a corresponding testing phase on the right side. For example, System Test plans are developed during the Requirements Analysis phase, and Acceptance Test plans are developed during the System Design phase. This parallel structure of 'Verification' and 'Validation' and the emphasis on designing tests early is its primary distinction from a simple Waterfall model where testing is often seen as a single phase that occurs only after all coding is done.

Tacit knowledge is knowledge that is difficult to transfer to another person by means of writing it down or verbalizing it. For complex, expert-driven domains like air traffic control, controllers often cannot articulate the 'why' behind all their actions. Ethnography (observing users in their natural environment) is the most effective technique to uncover these implicit workflows, heuristics, and environmental factors that are crucial for designing a successful replacement system. Interviews, analysis of the old system, and focus groups would likely miss this critical unspoken knowledge.

The philosophical shift from Agile/Scrum to DevOps is the extension of responsibility beyond 'potentially shippable' to 'successfully operating in production'. A true DevOps lifecycle completes the feedback loop. Therefore, the DoD is extended to include not just deployment to production (Continuous Deployment), but also the monitoring of that feature's health and performance post-release (Continuous Monitoring), ensuring it delivers actual value without causing harm.

While the statement is also ambiguous, its most critical flaw is the lack of verifiability. There is no objective, quantitative way to test if this requirement has been met. What constitutes 'fast'? A better, verifiable requirement would be: "For 95% of user queries under a load of 500 concurrent users, the system shall provide a response within 2 seconds." This can be tested and proven. The term 'fast' is subjective and therefore not verifiable.

This question requires synthesizing the principle with two different architectural styles. In a monolith, separation of concerns is about logical code organization within a single process. In microservices, the separation is physical. Each service is a separate deployment unit, often with its own database, and is organized around a specific business capability (e.g., 'Payment Service', 'User Profile Service'). This physical decoupling is the key architectural difference in how the principle is applied.

While overcommitment (A) could be a symptom, the root cause is the accumulation of technical debt and escaped defects. A robust 'Definition of Done' ensures that a feature is not considered complete until it meets a high-quality bar (e.g., extensive testing, passing all regression checks, meeting NFRs). A weak DoD allows low-quality work to be pushed out, which then creates a drag on future velocity as the team must constantly go back and fix old problems. This is the most direct cause of the described issue.

This question tests the nuance of the MoSCoW categories. 'Must Have' are non-negotiable for the current release. 'Could Have' are desirable but less important. 'Won't Have' are explicitly out. 'Should Have' occupies the critical middle ground: it is a high-priority item that is important to the solution's success, but it is not vital. A project can still be successful without it, making it a primary candidate for descoping if the project faces delays or budget cuts.

The NFR 'portability' is abstract. To be a good requirement, it must be made specific and verifiable. Option C provides concrete, measurable criteria: specific target platforms (Windows, RHEL), a quantifiable effort limit (4 person-hours), and a clear constraint (no source code changes). The other options are either too vague (A), a design decision rather than a requirement (B), or a good guideline but still not a verifiable requirement (D).

The key is the source of uncertainty. The problem states the technology is stable, but the requirements (user workflow) are uncertain. The primary goal of Throwaway Prototyping is requirements elicitation. A quick, potentially 'dirty' prototype is built to show users, get feedback, and solidify requirements. Once the requirements are understood, this prototype is discarded, and a high-quality system is built from scratch using a more formal process (like Waterfall or V-Model). Evolutionary Prototyping is better when both requirements and the technology are being refined together, as the prototype itself becomes the final system.

This is a classic but frequently confused distinction. Verification is the process of checking for internal consistency and quality of the artifact itself. For an SRS, this means checking if it is complete, consistent, unambiguous, traceable, etc. It's about the quality of the document. Validation is the process of checking the artifact against the actual, higher-level goals and stakeholder needs. For an SRS, this means confirming with users and stakeholders that the requirements, as written, will solve their business problem. It's about fitness for purpose.

The Spiral model is fundamentally risk-driven. The first step in each iteration is to identify the highest risks. In this scenario, the highest identified risk is technical integration. Therefore, the most logical first activity is to directly address that risk. A technical prototype or a 'spike' (a time-boxed investigation) focused on the riskiest interface would be the primary goal. This proves feasibility and provides crucial information before committing to full-scale development or detailed UI design.

This question requires analyzing the implementation consequences of an NFR. To guarantee 99.9% uptime (which allows for only ~8.76 hours of downtime per year), the system cannot rely on manual intervention to fix problems. It implies the existence of specific functions: the system must be able to monitor its own health, detect when a component has failed, and automatically switch to a redundant or backup system (failover) to maintain service. These are functional capabilities required to achieve the non-functional goal.

Kano analysis provides a nuanced view of requirements. 'Performance' attributes are the most straightforward: customers are more satisfied when they perform well and less satisfied when they perform poorly. Examples include things like gas mileage in a car, battery life on a phone, or query speed in a database. More is better, and less is worse, in a roughly linear fashion. This is distinct from 'Basic' attributes (must-haves) and 'Exciters' (delighters).

The key characteristics are: stable and clear requirements, and a strong need for correctness and validation (auditable). This is the ideal scenario for the V-Model. The rigid, sequential nature is not a drawback here because requirements are not expected to change. The V-Model's strength is its one-to-one mapping of development phases to testing phases, ensuring that the system is verified and validated against the well-defined requirements at every level of granularity, which is perfect for a system requiring high correctness and auditability. Agile/Scrum is less suitable when requirements are fixed and a high degree of upfront formal verification is needed.

This question highlights the primary weakness and rigidity of the pure Waterfall model. The model dictates that one phase must be complete before the next begins. A design flaw found in testing invalidates the 'Design' phase's output. The formal, correct process is to go back to the phase where the error was introduced, correct all artifacts from that phase (the design documents), and then re-execute all subsequent phases. This is why the cost of fixing defects grows exponentially in a Waterfall process. The other options represent deviations from the pure model.

The development team did their job: they built what was specified. The problem is that what was specified did not reflect the stakeholders' true needs. This is a classic failure of requirements analysis. The Product Owner is responsible for the Product Backlog and ensuring its items reflect the desired business value. The Backlog Refinement (or grooming) process, where the PO, dev team, and stakeholders collaborate to clarify and detail stories before a sprint begins, is the key process that failed here. It's the PO's role to bridge the gap between stakeholder needs and the specified user stories.

This is a cornerstone concept that drove the creation of structured methodologies like the Waterfall model. The 'Software Crisis' was characterized by projects that were late, over budget, and unreliable. Research by figures like Barry Boehm quantified the problem, showing that a defect costing $1 to fix in the requirements phase could cost $5-$10 in design, $100 in testing, and $1000 or more after release. This economic reality was the primary motivation for creating disciplined processes with heavy emphasis on getting the early stages (requirements and design) right.