1. What is the Spiral Model?
The Spiral Model is an iterative approach to software development that combines elements of the Waterfall Model and prototyping, with one thing added on top: a systematic focus on risk analysis at every step.
+----------------------+
| PLANNING |
| Objectives, |
| alternatives, |
| constraints |
+----------+-----------+
|
v
+----------------------+
| RISK ANALYSIS |
| Identify risks, |
| evaluate impact, |
| build prototypes |
+----------+-----------+
|
v
+----------------------+
| ENGINEERING |
| Design, build, |
| test the product |
+----------+-----------+
|
v
+----------------------+
| CUSTOMER EVALUATION |
| Review result and |
| decide next loop |
+----------+-----------+
|
v
NEXT ITERATION
|
+-------> back to PLANNING
Spiral Model = repeated risk-driven iterationsThe model is drawn as a spiral, and each loop of that spiral is one iteration of the project. Every loop passes through the same four phases. First, planning — the team defines the objectives for this iteration, lists the alternatives, and notes the constraints. Second, risk analysis — the team identifies what could go wrong, evaluates the likelihood and impact of each risk, and builds prototypes where a risk needs testing cheaply. Third, engineering — the product for this iteration is designed, built, and tested. Fourth, customer evaluation — the customer reviews the result and decides whether to take another loop around the spiral.
The following shows the repeated nature of the model:
CUSTOMER
|
v
+----------------+
| Evaluation |
+-------+--------+
|
v
+----------------+
| Engineering |
+-------+--------+
|
v
+----------------+
| Risk Analysis |
+-------+--------+
|
v
+----------------+
| Planning |
+-------+--------+
|
v
NEXT LOOP
|
+--------------------+
|
v
+------------------------+
| Planning -> Risk -> |
| Engineering -> Review |
+------------------------+
|
v
NEXT LOOP...What makes the model distinctive is not the phases themselves but the order and emphasis. Because risk analysis comes second in every loop, risks are examined and handled long before they can sink the project. In Waterfall, a project can run for months and then fail because nobody looked at the risks; the Spiral Model looks at them on every single pass.
This makes the model expensive — every loop involves analysis, review, and customer sign-off, plus a lot of documentation. But for large, complex, high-risk projects, where a late failure would be catastrophic, that cost is justified. The Spiral Model is the classic answer for safety-critical systems in defense, aerospace, and enterprise environments.
2. Explain the V-Model.
The V-Model is a development model in which every development phase has a directly corresponding testing phase, forming a V shape. Its central idea is that testing should be planned from the very beginning, alongside development, instead of being added only after coding.
DEVELOPMENT TESTING
PHASES PHASES
Requirement Analysis -----------------> Acceptance Testing
\ /
\ /
\ /
v v
System Design ----------------> System Testing
\ /
\ /
v v
High-Level Design --------> Integration Testing
\ /
\ /
v v
Low-Level Design --> Unit Testing
\ /
\ /
v v
\ /
\ /
\ /
Coding
|
v
Bottom of VThe left side of the V goes downward through the development phases: requirement analysis, system design, high-level design, low-level design, and finally coding at the bottom. The right side goes upward through the testing phases: unit testing, integration testing, system testing, and acceptance testing.
The correspondence between the two sides is the heart of the model:
| Development phase | Corresponding test phase |
|---|---|
| Requirement Analysis | Acceptance Testing |
| System Design | System Testing |
| High-Level Design | Integration Testing |
| Low-Level Design | Unit Testing |
Requirement Analysis
|
| plans
v
Acceptance Testing
System Design
|
| plans
v
System Testing
High-Level Design
|
| plans
v
Integration Testing
Low-Level Design
|
| plans
v
Unit TestingWhile the team is still writing requirements, it is also planning the acceptance tests. While it designs the system, it plans the system tests. By the time coding is done, every test plan is already written and waiting, so testing can begin immediately.
Each test level verifies the output of its matching development level. Unit testing confirms each individual module works. Integration testing confirms modules work together correctly. System testing confirms the whole system meets its requirements. Acceptance testing confirms the product meets the customer’s actual needs.
The advantage over Waterfall is that test planning starts early, so defects are caught closer to where they were introduced and cost less to fix. The disadvantage is shared with Waterfall: the model is sequential and rigid, so it suits projects with stable, well-defined requirements and struggles when requirements change.
3. What is the Prototype Model?
The Prototype Model builds a quick, simplified, working version of the system so stakeholders can see it, use it, and refine the requirements before full-scale development begins. The prototype is a communication tool, not the final product.
Rough Requirements
|
v
+-------------------+
| Build Prototype |
+---------+---------+
|
v
+-------------------+
| Users Try It |
+---------+---------+
|
v
+-------------------+
| Gather Feedback |
+---------+---------+
|
v
+-------------------+
| Revise Prototype |
+---------+---------+
|
+--------------------+
|
v
Requirements Clear?
/ \
No Yes
| |
+-----> loop v
+----------------+
| Build Full |
| System |
+----------------+The model exists because many customers cannot describe what they want in the abstract — they only know what they want once they see something. A prototype turns a vague idea into something concrete that users can click, explore, and give feedback on.
The process is a loop. First, the team gathers a rough idea of the requirements. Second, it builds a quick prototype covering the key screens and flows. Third, users try it and react: this is wrong, that is missing, this flow is confusing. Fourth, the team revises the prototype based on the feedback. Steps three and four repeat until the requirements settle down, and only then is the full system built properly.
Two kinds of prototypes exist. A throwaway prototype is built quickly, evaluated, and discarded — it exists purely to discover requirements. An evolutionary prototype is refined again and again until it gradually becomes the actual product.
PROTOTYPE TYPES
|
+---------+---------+
| |
v v
Throwaway Prototype Evolutionary Prototype
| |
v v
Build quickly Build and refine
| |
v v
Evaluate Improve
| |
v v
Discard Becomes final productThe strengths are significant. Requirements end up clearer and more accurate because they are based on something concrete. Misunderstandings are caught early, when they are cheap to fix. And because users are involved throughout, they tend to accept the final product more readily.
The weaknesses are real too. Users may mistake the prototype for the finished product and be disappointed when the real version takes longer. Without discipline, the revision loop never ends and the project stalls. And because prototypes focus on look and flow, they can hide performance and security issues that only surface at full scale. The model is the right choice when requirements are unclear, when there is no existing system to reference, or when the customer cannot articulate what they need.
4. What is the Incremental Model?
The Incremental Model builds a system in small, functional pieces called increments. Each increment is a usable slice of the system that adds features, and the full system is complete only when all increments are done.
FULL SYSTEM
|
+--------------+--------------+
| | |
v v v
Increment 1 Increment 2 Increment 3 Increment 4
| | | |
v v v v
Feature Set 1 Feature Set 2 Feature Set 3 Feature Set 4
| | | |
+--------------+--------------+--------------+
|
v
Complete SystemThe idea is to avoid the “big bang” delivery where nothing exists until everything is finished. Instead, the system is broken into natural slices, and each slice is designed, built, tested, and delivered on its own. Users get working software after the first increment, not after months of waiting.
Consider a shopping site. Increment 1 might deliver product browsing — you can search and view products. Increment 2 adds the shopping cart. Increment 3 adds checkout and payment. Increment 4 adds user accounts and order history. Each increment is a real, usable piece of the site, and value grows with every delivery.
Increment 1
+----------------------+
| Product Browsing |
+----------------------+
|
v
Increment 2
+----------------------+
| Product Browsing |
| + Shopping Cart |
+----------------------+
|
v
Increment 3
+----------------------+
| Browsing |
| + Cart |
| + Checkout/Payment |
+----------------------+
|
v
Increment 4
+----------------------+
| Browsing |
| + Cart |
| + Checkout/Payment |
| + Accounts/History |
+----------------------+The strengths follow directly. Value and feedback arrive early, because each increment is usable. Risk is spread out — if the project must stop early, a partial but working product still exists instead of nothing. And requirements can be refined between increments, because each one is planned and delivered separately.
The model has its own requirements to work well. The system must be divisible into natural increments, which is not always obvious. And because increments are built one at a time, a system built incrementally can take longer overall than one built in parallel — though it delivers value far sooner.
The Incremental Model is often paired with the Iterative Model, but they are distinct: incremental delivers more features per slice, while iterative refines the same features through cycles. Many real projects use both together.
5. What is the Iterative Model?
The Iterative Model builds a system through repeated cycles, refining and improving the product on every pass. Each cycle produces a fuller, better version of the same overall system.
+------------------+
| Initial Idea |
+--------+---------+
|
v
+------------------+
| Iteration 1 |
| Build -> Test |
+--------+---------+
|
v
+------------------+
| Iteration 2 |
| Refine -> Test |
+--------+---------+
|
v
+------------------+
| Iteration 3 |
| Improve -> Test |
+--------+---------+
|
v
+------------------+
| Better Product |
+------------------+The difference from the Incremental Model is subtle but important. Incremental delivery adds new features in slices — more of the system exists after each step. Iterative development refines the whole system — the same features get better and more polished with each cycle.
INCREMENTAL ITERATIVE
Add more features Improve existing features
Version 1: A Version 1: A (rough)
Version 2: A + B Version 2: A (better)
Version 3: A + B + C Version 3: A (better still)
Version 4: A + B + C + D Version 4: A (polished)A simple way to think of it: an iterative process works like a writer revising a draft. Draft one is complete but rough. Draft two has the same chapters, now better written. Draft three improves them further. The book exists from the start; it just gets better with each revision.
In software, each iteration produces a working version of the system, which the team reviews, tests, and improves based on feedback. Quality improves with every pass, and because parts of the system are visible from early on, risks surface early rather than at the end. It suits complex projects where the full picture is not clear at the start and where feedback must shape the result.
The cost is that iterative development is not the fastest route to a finished product — repeated cycles take time. But for projects where requirements are fuzzy or the customer learns by seeing, that cost buys a much better final result than building once in the dark.
6. What is the Rapid Application Development (RAD) Model?
The Rapid Application Development (RAD) Model emphasizes building working prototypes quickly and refining them with continuous user feedback, with minimal upfront planning. Its goal is speed: get usable software into users’ hands as fast as possible.
+----------------------+
| Requirements |
| Planning |
+----------+-----------+
|
v
+----------------------+
| User Design |
| Prototype + Feedback |
+----------+-----------+
|
v
+----------------------+
| Construction |
| Build + Test |
+----------+-----------+
|
v
+----------------------+
| Cutover |
| Deploy + Train |
+----------------------+
|
v
SYSTEMRAD works through four phases. Requirements planning is a short, intense workshop where stakeholders and developers agree on the high-level scope — deliberately fast, not exhaustive. User design is the heart of RAD: users work alongside developers to refine working prototypes iteratively, so the design is driven by what users actually say. Construction builds and tests the real components, using the prototypes from the previous phase as the blueprint. Cutover deploys the system and trains users.
Requirements Planning
|
v
User Design
|
+------+
| |
v |
Prototype |
| |
v |
Feedback |
| |
+------+
|
v
Construction
|
v
CutoverThe model achieves speed in two ways. First, it reuses existing components wherever possible instead of building everything from scratch. Second, it keeps the customer in the loop constantly, which means fewer wrong turns and less rework. Because users steer the design, what is built is what they actually wanted.
RAD works well when the team is small, requirements are reasonably clear, and speed matters more than perfect documentation. It fails in the opposite conditions: when the project is large and needs strict coordination, when the team must be big, or when requirements are so complex that a rapid cycle cannot capture them. The model’s own requirements — heavy user involvement and component reuse — are not always available.
In short, RAD trades thorough upfront planning for speed and user collaboration. When it fits, it delivers working software far faster than the traditional models.
7. What is the Big Bang Model?
The Big Bang Model is the SDLC model with almost no process at all. The team writes code without a structured plan, without formal phases, and without much documentation, and then brings everything together at the end. It is the “just start coding and see what happens” approach.
Requirements
|
v
Start Coding
|
v
Keep Building
|
v
Keep Building
|
v
+-------------+
| Integrate |
| Everything |
+------+------+
|
v
Final System
Little planning
Little documentation
Late testing
High uncertaintyIn a Big Bang project, requirements are gathered informally, often as they occur to people. Development proceeds without the discipline of defined phases. There is little design before coding, and testing is mostly a late, informal activity. All the pieces are finally integrated at the end, in one big push — hence the name.
The risks are severe. Because there is no structured testing or design, errors accumulate silently until the end. Because integration happens all at once, when things break — and they usually do — it is hard to tell which piece caused the problem. And because there is no early feedback, a fundamentally wrong direction is discovered only when it is far too late to change cheaply.
Structured Models Big Bang Model
Plan Code
| |
Design Code
| |
Build Code
| |
Test Code
| |
Release Integrate
|
v
TestThe model is therefore suitable only for very small, experimental projects where failure is cheap. A student project, a quick personal utility, or a throwaway experiment can tolerate the chaos. Even then, it works only when the developer has a clear idea of what to build and the code stays small.
The Big Bang Model’s value is mostly as a cautionary tale. It illustrates why the other models exist — the phases, the testing, the documentation, and the feedback loops are all designed to prevent the silent accumulation of problems that the Big Bang approach guarantees.
8. What are the advantages and disadvantages of the Waterfall Model?
The Waterfall Model is the linear, sequential approach to software development where each phase must be completed before the next begins, and the work never flows backward. Its advantages are clarity and discipline; its disadvantages are rigidity and late feedback.
Requirements
|
v
Design
|
v
Implementation
|
v
Testing
|
v
Deployment
|
v
Maintenance
|
| One direction
vThe advantages follow from the model’s structure. Because each phase has a defined deliverable, progress is always measurable — a manager can say exactly which phase the project is in. The model is simple to understand, even for non-technical stakeholders. Documentation is thorough, because every phase is formal, which helps when new team members join or when the project must be audited. And because testing happens on a complete, well-defined product, the testing effort is easy to plan.
The disadvantages follow equally from the same structure. The model is rigid — a change discovered late means redoing completed earlier phases, which is slow and expensive. The customer sees nothing working until the very end, so a fundamental misunderstanding is discovered at the worst possible moment. And the model handles uncertainty poorly; projects with unclear or evolving requirements are a poor fit.
WATERFALL vs AGILE
WATERFALL AGILE
--------- -----
Plan all Plan
requirements |
| v
v Build
Design |
| v
v Test
Build |
| v
v Feedback
Test |
| +----> Next Sprint
v
ReleaseA comparison helps put it in perspective:
| Waterfall | Agile | |
|---|---|---|
| Planning | All up front | Continuous |
| Requirement changes | Resisted | Welcomed |
| Customer sees working software | At the end | Every sprint |
| Documentation | Heavy | Light |
The model works best when requirements are stable, complete, and well understood from the start, and the technology is familiar. Government contracts and safety-critical systems, where a fixed specification is essential, are classic fits. For exploratory projects where requirements will change, a more flexible model is better.
9. When should you choose the Agile Model?
Choose the Agile Model when requirements are expected to evolve, when the customer can give regular feedback, and when the team needs to deliver working software quickly and continuously.
Agile Development Cycle
+-------------------+
| Plan Sprint |
+---------+---------+
|
v
+-------------------+
| Develop |
+---------+---------+
|
v
+-------------------+
| Test |
+---------+---------+
|
v
+-------------------+
| Demo |
+---------+---------+
|
v
+-------------------+
| Feedback |
+---------+---------+
|
+--------------------+
|
v
Next SprintThe strongest signal is uncertain or changing requirements. Agile is built around short sprints, so the plan is only ever fixed for a few weeks at a time. When priorities shift, the change simply becomes a new item for the next sprint. This makes Agile the natural choice for products where the market, and therefore the requirements, move fast.
The second signal is customer availability. Agile depends on the customer reviewing working software every sprint and giving feedback. If the customer is willing and able to be that involved, Agile works beautifully. If they cannot, the model loses one of its core engines.
The third signal is team structure. Agile suits small, self-organizing, cross-functional teams — teams that can plan their own work, make their own decisions, and contain all the skills needed to ship. It struggles with very large teams that need heavy coordination, though frameworks like Scrum of Scrums exist to scale it.
+----------------------+--------------------------+
| Project Characteristic| Agile Fit |
+----------------------+--------------------------+
| Changing requirements| HIGH |
| Customer feedback | HIGH |
| Small skilled team | HIGH |
| Continuous delivery | HIGH |
| Fixed requirements | LOW |
| Heavy upfront rules | LOW |
+----------------------+--------------------------+A few warning signs point away from Agile. If requirements are fixed and fully known up front, and change is genuinely unlikely, a plan-driven model is more efficient. If the project sits in a heavily regulated industry that demands detailed, up-front documentation and approval, the light-documentation philosophy of Agile can conflict with the rules. And if the customer cannot commit to regular involvement, Agile loses its feedback engine.
The best way to think about it is as a match: Agile is the right choice when the project’s nature — evolving requirements, involved customer, small skilled team — matches what Agile needs to thrive.
10. How do you choose the right SDLC model for a project?
There is no single best SDLC model; the right choice depends on the project’s size, complexity, risk, stakeholder involvement, and how likely requirements are to change. Choosing a model is a matching exercise, not a search for the “correct” answer.
PROJECT
|
+------------+------------+
| | |
v v v
Requirements Risk Project Size
Clarity
| | |
+------------+------------+
|
v
SDLC Model Choice
|
+------+------+------+------+------+
| | | | | |
v v v v v v
Waterfall Agile Spiral Prototype RAD IncrementalThe most important factor is requirements clarity. If requirements are stable and fully understood, plan-driven models like Waterfall or the V-Model work well. If requirements are fuzzy and likely to change, iterative models — Agile, Prototype, Incremental — are the better fit.
The second factor is risk. High-risk projects, where a failure is expensive or dangerous, favor the Spiral Model because it analyzes risk at every iteration. Low-risk projects do not need that machinery and would find it wasteful.
The third factor is size and complexity. Large, complex systems need structure and documentation to stay manageable — Spiral, V-Model, or RUP-style approaches. Small, simple systems can get away with lighter models like Incremental, or even Big Bang for tiny experiments.
The fourth factor is stakeholder involvement. Agile and RAD require the customer to participate continuously. If the customer can do that, these models shine; if not, a model that works from a fixed specification is more practical.
A quick decision guide:
| Situation | Good choices |
|---|---|
| Stable, clear requirements | Waterfall, V-Model |
| Changing requirements, involved customer | Agile |
| Very high risk | Spiral |
| Unclear requirements | Prototype, Iterative |
| Small project, fast delivery needed | RAD, Incremental |
Stable Requirements
|
v
Waterfall / V-Model
Changing Requirements
|
v
Agile
Very High Risk
|
v
Spiral
Unclear Requirements
|
v
Prototype / Iterative
Small + Fast Delivery
|
v
RAD / IncrementalNo model is universally right, and many real projects blend models — Agile inside with careful up-front risk analysis, for instance. The skill is understanding what each model assumes and checking which project’s reality matches those assumptions.
11. What is a Functional Requirement Specification (FRS)?
A Functional Requirement Specification (FRS) is a document that describes what a system must do, from the user’s perspective, in precise and testable terms. It is the “what” of the system, distinct from the “how” of the design.
BUSINESS NEED
|
v
BRD
Business Requirements
|
v
SRS
System Requirements
|
v
FRS
Functional Requirements
|
v
SYSTEM DESIGN
|
v
CODE
|
v
TESTSAn FRS focuses on behavior. It describes the functions the system must perform, the inputs it accepts, the outputs it produces, and the business rules it must enforce. Each requirement is written so that a tester can verify it — the requirement “the system must let a user reset a password” is only complete when it also states what the user does and what the system does in response.
A typical FRS contains functional requirements, business rules and workflows, and the data the system must handle. For example: “When a user submits the forgot-password form with a registered email, the system sends a password reset link to that email within one minute. If the email is not registered, the system shows an error message but does not reveal whether the email exists.”
The FRS is related to but distinct from the SRS. The SRS (Software Requirement Specification) covers the whole system, both functional and non-functional requirements. The FRS focuses specifically on functional behavior. In many organizations the FRS is the functional section of the SRS, or a document that feeds into it.
The FRS matters because it is the contract between the user and the developers. Developers code against it, testers write test cases against it, and the customer accepts the system against it. A good FRS is unambiguous, testable, and complete — and a bad one guarantees arguments later about whether something was “really” required.
12. What is a Business Requirement Document (BRD)?
A Business Requirement Document (BRD) is a high-level document that explains why a project exists and what it is meant to achieve from the business’s point of view. It describes the business objectives, the high-level requirements, and the expected outcomes — in business language, not technical language.
BUSINESS PROBLEM
|
v
+-------------+
| BRD |
| WHY? |
+------+------+
|
v
Business Goals
|
v
High-Level Needs
|
v
Success CriteriaA BRD typically answers a few questions. Why are we doing this project? What business problem or opportunity is driving it? What outcomes do we expect — more sales, lower costs, better customer retention? Who are the stakeholders, and what do they need? And how will we know the project succeeded — what are the success criteria?
Consider a company deciding to build an online ordering system. The BRD would say: “The business goal is to increase sales by 20% by letting customers order online. The expected outcome is higher revenue and fewer phone orders. Success will be measured by the number of online orders and average order value.” It would not specify the database schema or the API design — that comes later, in the technical documents.
The BRD sits at the top of the requirements hierarchy. Below it come the SRS and FRS, which translate the business goals into system behavior. The BRD says “increase online sales”; the FRS says “users can add items to a cart and check out with a credit card.”
BRD
|
| "Why?"
v
Business Objectives
|
v
SRS
|
| "What?"
v
System Requirements
|
v
FRS
|
| "What behavior?"
v
Functional BehaviorThe BRD matters because it connects the project to actual business value. It is the document that answers “why are we spending money on this?” and it keeps the whole team pointed at the real goal rather than getting lost in technical detail.
13. What is a Use Case?
A Use Case is a description of how an actor interacts with a system to achieve a goal. It captures behavior from the user’s point of view, in terms of the steps the user takes and what the system does in response.
+----------------+
| ACTOR |
| Customer |
+-------+--------+
|
| interacts
v
+----------------+
| SYSTEM |
| |
| Login |
| Validate |
| Open Account |
+----------------+
|
v
GOAL
Access AccountA use case has a few standard parts. The actor is the person or external system that initiates the interaction. The goal is what the actor is trying to accomplish. The main flow is the happy path — the normal sequence of steps where everything goes well. The alternate flows are the exceptions — wrong password, canceled action, system error — and how the system handles each.
Consider a “Login” use case for a banking app:
- Actor: registered customer.
- Goal: access the account.
- Main flow: the customer enters their username and password, clicks login, and the system validates the credentials and opens the account.
- Alternate flows: the password is wrong, so the system shows an error; the account is locked, so the system shows a lock notice.
LOGIN USE CASE
Customer
|
v
Enter Username
|
v
Enter Password
|
v
Click Login
|
v
Validate Credentials
|
+-------------------+
| |
Valid Invalid
| |
v v
Open Account Show ErrorUse cases are written from the actor’s perspective, in plain language, which makes them easy for business people and developers to discuss and agree on. They drive both design and testing — the main and alternate flows become the scenarios that testers verify.
Use cases are often confused with user stories, but they are different tools. A user story is a brief, one-line reminder of a need (“as a customer, I want to see my balance so I can track spending”). A use case is a detailed, step-by-step description of an interaction. Both capture requirements; they sit at different levels of detail.
14. What is a User Story?
A User Story is a short, simple description of a feature written from the user’s perspective, usually following the format “As a role, I want a goal, so that a benefit.” It is the Agile way of capturing requirements.
+----------------------+
| USER STORY |
+----------------------+
|
v
+----------------+
| As a ROLE |
+-------+--------+
|
v
+----------------+
| I want GOAL |
+-------+--------+
|
v
+----------------+
| So that |
| BENEFIT |
+----------------+The standard format has three parts. The role says who needs the feature — the user whose need is being addressed. The goal says what they want to do. The benefit says why it matters to them. For example: “As a customer, I want to track my order, so that I know when it will arrive.”
That one-line format does important work. It keeps the focus on user value, because the benefit clause forces someone to justify why the feature matters. It keeps requirements lightweight — a story is easy to write, read, and rearrange. And it deliberately leaves details out. The story is not a full specification; it is a placeholder for a conversation.
Agile teams use stories as the unit of planning. Stories sit in the product backlog, ordered by priority. They are discussed in planning sessions, where acceptance criteria — the specific conditions that make the story “done” — are added. A story is only considered done when those criteria are met.
USER STORY
|
v
Product Backlog
|
v
Prioritized
|
v
Sprint Planning
|
v
Acceptance Criteria
|
v
Development
|
v
DoneThe contrast with a use case is worth remembering. A use case is a detailed, multi-step description of an interaction. A user story is a brief reminder of a need, refined through conversation. Stories are lighter and faster to produce, which is why they suit the fast-moving rhythm of Agile, while use cases suit projects that need more formal, detailed requirement documents.
USE CASE vs USER STORY
USE CASE USER STORY
-------- ----------
Detailed interaction Brief requirement
| |
v v
Actor Role
| |
v v
Goal Goal
| |
v v
Main Flow Benefit
| |
v v
Alternate Flows Conversation
| |
v v
Testing Scenarios Acceptance CriteriaPremium Content
Unlock Top 50 Placement Questions - Part 1 and all premium lessons with a subscription.
From ₹199.99/year — See plans