Skip to content
CampusPrep
AD-403 · Software Engineering with Agile Methodology/Quick Revision Short Notes

Software Engineering with Agile Methodology (AD-403) - Unit 1 Short Notes

How unit 1 is examined

This unit covers life-cycle and process models, estimation and requirements; Spiral, Requirement Validation and COCOMO/estimation carry the marks.

Software Development Life Cycles

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>The SDLC is the structured sequence of phases (requirements, design, implementation, testing, deployment, maintenance) through which a software product is planned, built and kept alive.</mark>

Key points.

  1. Requirement analysis collects and documents what the user needs; its deliverable is the SRS.
  2. Design converts the SRS into architecture and detailed module design; the deliverable is the design document.
  3. Implementation writes the code module by module; the deliverable is tested source code.
  4. Testing checks the code against the SRS through unit, integration, system and acceptance tests; the deliverable is a test report.
  5. Deployment releases the product to the user site, with installation and training.
  6. Maintenance fixes faults, adapts to change and enhances the product after release.
  7. The SDLC is needed because a defined order gives control, measurable progress and quality.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-01" viewBox="0 0 596 80" width="596" height="80" role="img" aria-label="SDLC phases: Requirements, Design, Coding, Testing, Deployment, Maintenance"><style>#dsfig-u1-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-01 .t{fill:#16181D;font-weight:500}#dsfig-u1-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-01 .dot{fill:#16181D}#dsfig-u1-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-01 .ah{fill:#454C5A}#dsfig-u1-01 .ah.hi{fill:#2340B8}#dsfig-u1-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-01 .e{stroke:#B1B7C3}html.dark #dsfig-u1-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-01 .t{fill:#E6E8ED}html.dark #dsfig-u1-01 .t.inv{fill:#0F1115}html.dark #dsfig-u1-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-01 .dot{fill:#E6E8ED}html.dark #dsfig-u1-01 .ann{fill:#8FA3FF}html.dark #dsfig-u1-01 .lbl{fill:#858D9C}html.dark #dsfig-u1-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-01 .ah{fill:#B1B7C3}html.dark #dsfig-u1-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah1" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh1" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L122.2,40" marker-end="url(#ah1)"/><path class="e" d="M162.2,40 L225.4,40" marker-end="url(#ah1)"/><path class="e" d="M265.4,40 L328.6,40" marker-end="url(#ah1)"/><path class="e" d="M368.6,40 L431.8,40" marker-end="url(#ah1)"/><path class="e" d="M471.8,40 L535,40" marker-end="url(#ah1)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Req</text><circle class="n" cx="143.2" cy="40" r="18"/><text class="t" x="143.2" y="40" dy=".35em" text-anchor="middle">Des</text><circle class="n" cx="246.4" cy="40" r="18"/><text class="t" x="246.4" y="40" dy=".35em" text-anchor="middle">Cod</text><circle class="n" cx="349.6" cy="40" r="18"/><text class="t" x="349.6" y="40" dy=".35em" text-anchor="middle">Tst</text><circle class="n" cx="452.8" cy="40" r="18"/><text class="t" x="452.8" y="40" dy=".35em" text-anchor="middle">Dep</text><circle class="n" cx="556" cy="40" r="18"/><text class="t" x="556" y="40" dy=".35em" text-anchor="middle">Mnt</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">SDLC phases: Requirements, Design, Coding, Testing, Deployment, Maintenance</figcaption></figure> Answer frame. Open with the definition; draw the phase flow; develop points 1-6 with activity and deliverable each; close with the need (point 7).

Asked: [7 marks] (Jun 2025) Explain the phases of the Software Development Life Cycle (SDLC) in detail.

Waterfall

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The waterfall model is a linear model in which each phase must finish before the next starts, with no going back.</mark>

Key points.

  1. Phases run in fixed order: requirements, design, coding, testing, maintenance.
  2. Each phase ends with a reviewed document.
  3. It suits small projects with stable, well-understood requirements.
  4. Its weakness is that changes are costly and the customer sees the product only at the end.

V-Model

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The V-model is an extension of waterfall in which every development phase is paired with a testing phase (verification on the left, validation on the right).</mark>

Key points.

  1. Requirements pair with acceptance testing, system design with system testing, and module design with unit testing.
  2. Test plans are written early, alongside each development phase.
  3. It is disciplined and suits safety-critical work, but it is rigid like waterfall.

Prototype Model

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The prototype model builds a working mock-up of the system first so that users can give feedback and clarify requirements before the real system is built.</mark>

Key points.

  1. Steps: quick requirements, quick design, build prototype, user evaluation, refine, then the final product.
  2. It reduces requirement misunderstanding and is good when requirements are unclear.
  3. Risk: users may demand the throw-away prototype as the final product.

Incremental

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The incremental model divides the product into increments, each built through requirements, design, code and test, and delivered in turn.</mark>

Key points.

  1. The first increment is the core product; later ones add features.
  2. Early delivery gives usable software and feedback sooner.
  3. It needs good up-front architecture so increments integrate.

Evolutionary

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The evolutionary model develops an initial version, exposes it to the user, and refines it through several versions until the system is acceptable.</mark>

Key points.

  1. Requirements are allowed to change between versions.
  2. It suits large systems whose requirements are not fully known.
  3. Weakness: poor structure and hard-to-see progress.

RAD

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Rapid Application Development is a high-speed, incremental model that builds the system in 60-90 days using component reuse and parallel, team-wise development.</mark>

Key points.

  1. Business modelling defines the information flow between business functions.
  2. Data modelling refines this flow into data objects and relations.
  3. Process modelling turns data objects into functions that add, modify, delete or retrieve them.
  4. Application generation uses fourth-generation tools and reusable components.
  5. Testing and turnover is short because reused components are already tested.
  6. Each major function goes to a separate team working in parallel, so the system must be modular.
  7. Advantages are fast delivery and reuse; limitations are the need for many skilled people, a modular design and committed users; it suits well-scoped business systems.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-02" viewBox="0 0 561.6 252" width="561.6" height="252" role="img" aria-label="RAD: Business, Data, Process modelling, Application generation, Testing and turnover; T1 and T2 are parallel teams"><style>#dsfig-u1-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-02 .t{fill:#16181D;font-weight:500}#dsfig-u1-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-02 .dot{fill:#16181D}#dsfig-u1-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-02 .ah{fill:#454C5A}#dsfig-u1-02 .ah.hi{fill:#2340B8}#dsfig-u1-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-02 .e{stroke:#B1B7C3}html.dark #dsfig-u1-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-02 .t{fill:#E6E8ED}html.dark #dsfig-u1-02 .t.inv{fill:#0F1115}html.dark #dsfig-u1-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-02 .dot{fill:#E6E8ED}html.dark #dsfig-u1-02 .ann{fill:#8FA3FF}html.dark #dsfig-u1-02 .lbl{fill:#858D9C}html.dark #dsfig-u1-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-02 .ah{fill:#B1B7C3}html.dark #dsfig-u1-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah2" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh2" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,126 L139.4,126" marker-end="url(#ah2)"/><path class="e" d="M179.4,126 L259.8,126" marker-end="url(#ah2)"/><path class="e" d="M299.8,126 L380.2,126" marker-end="url(#ah2)"/><path class="e" d="M420.2,126 L500.6,126" marker-end="url(#ah2)"/><path class="e" d="M175.9,115 L263.7,52.2" marker-end="url(#ah2)"/><path class="e" d="M296.3,51 L384.1,113.8" marker-end="url(#ah2)"/><path class="e" d="M175.9,137 L263.7,199.8" marker-end="url(#ah2)"/><path class="e" d="M296.3,201 L384.1,138.2" marker-end="url(#ah2)"/><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">BM</text><circle class="n" cx="160.4" cy="126" r="18"/><text class="t" x="160.4" y="126" dy=".35em" text-anchor="middle">DM</text><circle class="n" cx="280.8" cy="126" r="18"/><text class="t" x="280.8" y="126" dy=".35em" text-anchor="middle">PM</text><circle class="n" cx="401.2" cy="126" r="18"/><text class="t" x="401.2" y="126" dy=".35em" text-anchor="middle">AG</text><circle class="n" cx="521.6" cy="126" r="18"/><text class="t" x="521.6" y="126" dy=".35em" text-anchor="middle">TT</text><circle class="n" cx="280.8" cy="40" r="18"/><text class="t" x="280.8" y="40" dy=".35em" text-anchor="middle">T1</text><circle class="n" cx="280.8" cy="212" r="18"/><text class="t" x="280.8" y="212" dy=".35em" text-anchor="middle">T2</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">RAD: Business, Data, Process modelling, Application generation, Testing and turnover; T1 and T2 are parallel teams</figcaption></figure>

Asked: [7 marks] (Jun 2024) Analyze the RAD Model with neat diagram.

Spiral

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>The spiral model is a risk-driven, iterative model in which each loop passes through four quadrants: planning, risk analysis, engineering and customer evaluation.</mark>

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-03" viewBox="0 0 345 252" width="345" height="252" role="img" aria-label="One loop of the spiral: Planning, Risk analysis (prototype), Engineering (waterfall steps), Evaluation; radius grows each loop"><style>#dsfig-u1-03 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-03 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-03 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-03 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-03 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-03 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-03 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-03 .t{fill:#16181D;font-weight:500}#dsfig-u1-03 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-03 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-03 .dot{fill:#16181D}#dsfig-u1-03 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-03 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-03 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-03 .ah{fill:#454C5A}#dsfig-u1-03 .ah.hi{fill:#2340B8}#dsfig-u1-03 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-03 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-03 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-03 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-03 .e{stroke:#B1B7C3}html.dark #dsfig-u1-03 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-03 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-03 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-03 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-03 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-03 .t{fill:#E6E8ED}html.dark #dsfig-u1-03 .t.inv{fill:#0F1115}html.dark #dsfig-u1-03 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-03 .dot{fill:#E6E8ED}html.dark #dsfig-u1-03 .ann{fill:#8FA3FF}html.dark #dsfig-u1-03 .lbl{fill:#858D9C}html.dark #dsfig-u1-03 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-03 .ah{fill:#B1B7C3}html.dark #dsfig-u1-03 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-03 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-03 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-03 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah3" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh3" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M66,40 L270,40" marker-end="url(#ah3)"/><path class="e" d="M298,66 L298,191" marker-end="url(#ah3)"/><path class="e" d="M279,212 L68,212" marker-end="url(#ah3)"/><path class="e" d="M40,186 L40,68" marker-end="url(#ah3)"/><rect class="n" x="15" y="25" width="50" height="30" rx="15"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Plan</text><rect class="n" x="273" y="25" width="50" height="30" rx="15"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Risk</text><circle class="n" cx="298" cy="212" r="18"/><text class="t" x="298" y="212" dy=".35em" text-anchor="middle">Eng</text><rect class="n" x="15" y="197" width="50" height="30" rx="15"/><text class="t" x="40" y="212" dy=".35em" text-anchor="middle">Eval</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">One loop of the spiral: Planning, Risk analysis (prototype), Engineering (waterfall steps), Evaluation; radius grows each loop</figcaption></figure> Key points.

  1. Planning (quadrant 1) fixes objectives, alternatives and constraints for the loop.
  2. Risk analysis (quadrant 2) identifies risks and resolves them, often by building a prototype.
  3. Engineering (quadrant 3) develops and tests the next level of the product.
  4. Evaluation (quadrant 4) has the customer review the result and the next loop is planned.
  5. Radius equals cost so far and angle equals progress; each loop produces a more complete version.
  6. Advantages: early risk handling, customer feedback every loop, and suitability for large, critical systems.
  7. Disadvantages: costly, complex to manage, and dependent on real risk-assessment expertise, so poor for small projects.
  8. Waterfall fits inside it: with clear requirements and low risk, the engineering quadrant runs the sequential design-code-test steps of a waterfall in one loop.
  9. Prototyping fits inside it: in early loops with unclear requirements, risk analysis builds a prototype to validate requirements and cut risk before real engineering starts.

Spiral versus Incremental.

Basis Spiral Incremental
Driver Risk analysis Feature slices
Risk handling Explicit each loop Not explicit
Flexibility High, requirements may change Moderate, plan fixed early
Cost Higher Lower
Delivery Refined versions of whole product Working increments added
Use Large, risky, new systems Well-known needs, early delivery

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-04" viewBox="0 0 467 80" width="467" height="80" role="img" aria-label="Incremental: Increment 1, 2, 3 (each requirements-design-code-test) build up the final Product"><style>#dsfig-u1-04 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-04 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-04 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-04 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-04 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-04 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-04 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-04 .t{fill:#16181D;font-weight:500}#dsfig-u1-04 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-04 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-04 .dot{fill:#16181D}#dsfig-u1-04 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-04 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-04 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-04 .ah{fill:#454C5A}#dsfig-u1-04 .ah.hi{fill:#2340B8}#dsfig-u1-04 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-04 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-04 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-04 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-04 .e{stroke:#B1B7C3}html.dark #dsfig-u1-04 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-04 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-04 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-04 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-04 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-04 .t{fill:#E6E8ED}html.dark #dsfig-u1-04 .t.inv{fill:#0F1115}html.dark #dsfig-u1-04 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-04 .dot{fill:#E6E8ED}html.dark #dsfig-u1-04 .ann{fill:#8FA3FF}html.dark #dsfig-u1-04 .lbl{fill:#858D9C}html.dark #dsfig-u1-04 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-04 .ah{fill:#B1B7C3}html.dark #dsfig-u1-04 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-04 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-04 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-04 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah4" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh4" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L148,40" marker-end="url(#ah4)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah4)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah4)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">I1</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">I2</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">I3</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">P</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Incremental: Increment 1, 2, 3 (each requirements-design-code-test) build up the final Product</figcaption></figure> Answer frame. For the 14-mark accommodation question: open with the definition; draw the spiral marking "Prototype" in quadrant 2 and "Waterfall steps" in quadrant 3; develop points 1-5, then 8 and 9; close that the spiral is a meta-model containing other models. For 7 marks: definition, diagram, points 1-7. For comparison: definition of each, both diagrams, the table, then conclude spiral suits risky projects and incremental suits stable ones.

Asked: [14 marks] (Jun 2023) Explain how both Waterfall model and Prototyping model can be accommodated in the Spiral Process Model. Asked: [7 marks] (Jun 2023) Explain Spiral model also write advantages and disadvantages of Spiral Model. Asked: [7 marks] (Jun 2025) Compare the Spiral and Incremental models with suitable diagrams.

Project Planning

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Project planning estimates size, effort, cost and schedule, then allocates resources and identifies risks before development starts.</mark>

Key points.

  1. Steps: estimate size, then effort and duration, then staffing and schedule.
  2. The output is the project plan, used for tracking.
  3. Plans are revised as facts change.

Metrics for Project Size Estimation

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Size metrics measure how big a project is; the two main ones are Lines of Code (LOC) and Function Points (FP).</mark>

Key points.

  1. LOC counts source lines (often in KLOC); it is simple but language-dependent and known only late.
  2. FP measures functionality from inputs, outputs, inquiries, files and interfaces, so it is language-independent and usable early.
  3. $FP = UFP \times VAF$, where UFP is the weighted count and $VAF = 0.65 + 0.01\sum F_i$.

Project Estimation Techniques

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Medium weight</span>

Definition. <mark>Project estimation predicts the size, effort, time and cost of a project; COCOMO (Boehm) is an empirical model that gives effort from size in KLOC.</mark>

Key points.

  1. Empirical techniques use past data: LOC/FP-based estimation, COCOMO and analogy (compare with a similar past project).
  2. Heuristic techniques use rules and judgement: expert judgement and the Delphi method, where anonymous experts revise estimates over rounds until they converge.
  3. COCOMO has three types: Basic (size only), Intermediate (adds 15 cost drivers) and Detailed (applies drivers phase-wise, per module).
  4. Organic projects are small teams, familiar work; Semidetached is mixed; Embedded has tight hardware and operational constraints.
  5. Merits: quick and repeatable; limitations: results depend on the accuracy of size and calibration.

Formula. Basic COCOMO: $E = a(KLOC)^b$ person-months, $D = c\,E^d$ months, people $= E/D$.

Mode a b c d
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Example. Organic, 32 KLOC: $E = 2.4 \times 32^{1.05} = 91.3$ PM; $D = 2.5 \times 91.3^{0.38} = 13.9$ months; staff $= 91.3/13.9 \approx 6.6$. Effort 91.3 PM, time 13.9 months, about 7 people.

Answer frame. Open with why estimation is needed; list techniques grouped as empirical and heuristic; for COCOMO give the three types, three modes, the table and the worked steps; close with merits and limitations.

Asked: [7 marks] (Jun 2023) Explain COCOMO Model in detail? Asked: [7 marks] (Jun 2025) Describe the various project estimation techniques used in software engineering.

Requirements Gathering and Analysis

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>It is the first phase, in which analysts collect user needs, check feasibility, and resolve anomalies, incompleteness and inconsistency.</mark>

Key points.

  1. Gathering uses interviews, observation and study of existing systems.
  2. Analysis removes contradictions and ambiguity.
  3. The result is documented in the SRS.

Software Requirements Specification (SRS)

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The SRS is the document that states, completely and unambiguously, what the software must do, and forms the contract between customer and developer.</mark>

Key points.

  1. IEEE 830 structure: introduction, overall description, specific requirements (functional, external interface, performance, constraints).
  2. A good SRS is correct, complete, consistent, unambiguous, verifiable and modifiable.
  3. It is the base for design, testing and acceptance.

Software Product and Process Characteristics

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A software product is the deliverable program with its documentation; a software process is the set of activities, methods and practices used to produce it.</mark>

Key points.

  1. Product characteristics are functionality, reliability, usability, efficiency, maintainability and portability.
  2. Process characteristics are understandability, visibility, supportability, reliability and rapidity.
  3. A good process gives predictable, repeatable quality, so it is the means; the product is the end the customer pays for.
  4. Conclusion: both matter, but process is more important because quality cannot be tested into a product; a mature process (for example CMM level 3+) consistently yields good products.

Answer frame. Define both; argue for process in two points and for product in one; close with the justified conclusion.

Asked: [7 marks] (Jun 2023) Which is more important- The Product or Process? Justify your answer.

Software Process Models

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>A software process model is an abstract description of the order of activities used to develop software.</mark>

Key points.

  1. Waterfall is linear and non-iterative: requirements, design, code, test, maintenance; best for stable requirements.
  2. Iterative develops the system in repeated cycles, each refining the last, so changes are absorbed.
  3. Spiral is iterative with risk analysis in every loop (see Spiral above).
  4. Waterfall is simple but inflexible; iterative is flexible but needs planning; spiral handles risk but costs more.

Diagram. <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-05" viewBox="0 0 596 320.8" width="596" height="320.8" role="img" aria-label="Waterfall: Requirements, Design, Coding, Testing, Maintenance"><style>#dsfig-u1-05 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-05 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-05 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-05 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-05 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-05 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-05 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-05 .t{fill:#16181D;font-weight:500}#dsfig-u1-05 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-05 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-05 .dot{fill:#16181D}#dsfig-u1-05 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-05 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-05 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-05 .ah{fill:#454C5A}#dsfig-u1-05 .ah.hi{fill:#2340B8}#dsfig-u1-05 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-05 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-05 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-05 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-05 .e{stroke:#B1B7C3}html.dark #dsfig-u1-05 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-05 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-05 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-05 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-05 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-05 .t{fill:#E6E8ED}html.dark #dsfig-u1-05 .t.inv{fill:#0F1115}html.dark #dsfig-u1-05 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-05 .dot{fill:#E6E8ED}html.dark #dsfig-u1-05 .ann{fill:#8FA3FF}html.dark #dsfig-u1-05 .lbl{fill:#858D9C}html.dark #dsfig-u1-05 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-05 .ah{fill:#B1B7C3}html.dark #dsfig-u1-05 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-05 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-05 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-05 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah5" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh5" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M57.2,48 L150,91.3" marker-end="url(#ah5)"/><path class="e" d="M186.2,108.2 L279,151.5" marker-end="url(#ah5)"/><path class="e" d="M315.2,168.4 L408,211.7" marker-end="url(#ah5)"/><path class="e" d="M444.2,228.6 L537,271.9" marker-end="url(#ah5)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Req</text><circle class="n" cx="169" cy="100.2" r="18"/><text class="t" x="169" y="100.2" dy=".35em" text-anchor="middle">Des</text><circle class="n" cx="298" cy="160.4" r="18"/><text class="t" x="298" y="160.4" dy=".35em" text-anchor="middle">Cod</text><circle class="n" cx="427" cy="220.6" r="18"/><text class="t" x="427" y="220.6" dy=".35em" text-anchor="middle">Tst</text><circle class="n" cx="556" cy="280.8" r="18"/><text class="t" x="556" y="280.8" dy=".35em" text-anchor="middle">Mnt</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Waterfall: Requirements, Design, Coding, Testing, Maintenance</figcaption></figure> <figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u1-06" viewBox="0 0 467 80" width="467" height="80" role="img" aria-label="Iterative: Plan, Design, Build, Test repeated, each cycle refining the product"><style>#dsfig-u1-06 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u1-06 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u1-06 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u1-06 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u1-06 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u1-06 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u1-06 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u1-06 .t{fill:#16181D;font-weight:500}#dsfig-u1-06 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u1-06 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u1-06 .dot{fill:#16181D}#dsfig-u1-06 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u1-06 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u1-06 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u1-06 .ah{fill:#454C5A}#dsfig-u1-06 .ah.hi{fill:#2340B8}#dsfig-u1-06 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u1-06 .wl .t{font-size:12px;font-weight:700}#dsfig-u1-06 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u1-06 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u1-06 .e{stroke:#B1B7C3}html.dark #dsfig-u1-06 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u1-06 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u1-06 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u1-06 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u1-06 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u1-06 .t{fill:#E6E8ED}html.dark #dsfig-u1-06 .t.inv{fill:#0F1115}html.dark #dsfig-u1-06 .kd{stroke:#E6E8ED}html.dark #dsfig-u1-06 .dot{fill:#E6E8ED}html.dark #dsfig-u1-06 .ann{fill:#8FA3FF}html.dark #dsfig-u1-06 .lbl{fill:#858D9C}html.dark #dsfig-u1-06 .ptr{fill:#8FA3FF}html.dark #dsfig-u1-06 .ah{fill:#B1B7C3}html.dark #dsfig-u1-06 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u1-06 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u1-06 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u1-06 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah6" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah" d="M0,1 L9,5 L0,9 z"/></marker><marker id="ahh6" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse"><path class="ah hi" d="M0,1 L9,5 L0,9 z"/></marker></defs><path class="e" d="M59,40 L148,40" marker-end="url(#ah6)"/><path class="e" d="M188,40 L277,40" marker-end="url(#ah6)"/><path class="e" d="M317,40 L406,40" marker-end="url(#ah6)"/><path class="e" d="M408,40 L61,40" marker-end="url(#ah6)"/><circle class="n" cx="40" cy="40" r="18"/><text class="t" x="40" y="40" dy=".35em" text-anchor="middle">Pln</text><circle class="n" cx="169" cy="40" r="18"/><text class="t" x="169" y="40" dy=".35em" text-anchor="middle">Dsn</text><circle class="n" cx="298" cy="40" r="18"/><text class="t" x="298" y="40" dy=".35em" text-anchor="middle">Bld</text><circle class="n" cx="427" cy="40" r="18"/><text class="t" x="427" y="40" dy=".35em" text-anchor="middle">Tst</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Iterative: Plan, Design, Build, Test repeated, each cycle refining the product</figcaption></figure> Answer frame. Define each model; draw waterfall, iterative and the spiral from above; give flow, then advantages and limitations of each; close with when to use each.

Asked: [7 marks] (Jun 2024) With neat sketches, explain iterative, waterfall and spiral models.

Evolutionary Process Models and Agile processes

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Evolutionary process models produce software in progressively more complete versions, accepting that requirements evolve; Agile processes add short iterations with continuous customer collaboration.</mark>

Key points.

  1. Prototyping is evolutionary: a prototype is refined through user feedback into the final system.
  2. Spiral is evolutionary: each loop adds functionality with risk analysis.
  3. Incremental delivery releases working parts in stages so users benefit early.
  4. Advantages are handling changing requirements and early feedback; they suit large, unclear systems.
  5. Agile methods such as Scrum and XP use short sprints and adapt to change.

Asked: [7 marks] (Jun 2024) Explain briefly about evolutionary process models.

Software Process customization and improvement

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Process customization tailors a standard process to a project; process improvement measures the process and upgrades it continuously.</mark>

Key points.

  1. Tailoring drops or adds activities according to project size and risk.
  2. Improvement follows measure, analyse, change and re-measure.
  3. CMM and ISO 9001 are common improvement frameworks.

CMM

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>The Capability Maturity Model rates an organisation's software process on five maturity levels.</mark>

Key points.

  1. Level 1 Initial: ad hoc and chaotic.
  2. Level 2 Repeatable: basic project management.
  3. Level 3 Defined: a standard documented process.
  4. Level 4 Managed: quantitative measurement and control.
  5. Level 5 Optimizing: continuous improvement.

Product and Process Metrics

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Product metrics measure the software itself (size, complexity, defects); process metrics measure how it is built (effort, defect removal, cycle time).</mark>

Key points.

  1. Product examples: LOC, function points, cyclomatic complexity.
  2. Process examples: defect removal efficiency and time per phase.
  3. Metrics support estimation, control and improvement.

Functional and Non-functional requirements

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Low weight</span>

Definition. <mark>Functional requirements state what the system must do; non-functional requirements state how well it must do it, as quality attributes and constraints.</mark>

Key points.

  1. Functional examples: a library system must issue and return books; an ATM must dispense cash after PIN check.
  2. Non-functional examples: response time under 2 seconds, 99.9% availability, security, usability, portability.
  3. Functional requirements are checked by feature tests; non-functional ones by measurement against limits.
  4. Failing a non-functional requirement can make the whole system unusable even if all functions work.
  5. Both go into the SRS, functional in the specific-requirements section, non-functional under performance and constraints.

Asked: [7 marks] (Jun 2025) What are functional and non-functional requirements? Give examples.

Requirement Sources and Elicitation Techniques

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Elicitation is the activity of discovering requirements from sources such as users, documents and existing systems.</mark>

Key points.

  1. Techniques: interviews, questionnaires, observation, brainstorming, prototyping and document analysis.
  2. Sources are stakeholders, domain experts, standards and legacy systems.
  3. Use several techniques to reduce omissions.

Analysis Modeling for Function-oriented and Object-oriented software development

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Analysis modelling represents requirements in diagrams before design.</mark>

Key points.

  1. Function-oriented analysis uses data flow diagrams (DFD), data dictionary and ER diagrams.
  2. Object-oriented analysis uses class, use case and sequence diagrams.
  3. DFD shows processes, data stores, flows and external entities.

Use case Modeling

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A use case model describes system functions from the user's view as interactions between actors and the system.</mark>

Key points.

  1. Actors are outside users or systems; use cases are ovals inside the system boundary.
  2. Relations are association, include and extend.
  3. Each use case has a main flow and alternate flows.

System and Software Requirement Specifications

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>A system specification covers hardware, software and people at the whole-system level; the software specification refines only the software part of it.</mark>

Key points.

  1. The system specification comes first, from the customer's view.
  2. The software specification is the SRS derived from it.
  3. Both must be consistent.

Requirement Validation

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">High weight</span>

Definition. <mark>Requirement validation checks that the documented requirements are complete, consistent, correct and really what the customer wants, before design begins.</mark>

Key points.

  1. The purpose is to find errors early, since a requirement fault costs far more to fix after coding.
  2. Checks are validity, consistency, completeness, realism (can it be built within budget) and verifiability (can it be tested).
  3. Requirements reviews: a team of analysts, users and developers reads the SRS line by line and logs issues.
  4. Prototyping lets users try a model to confirm the requirements.
  5. Test-case generation writes tests from requirements; a requirement that cannot be tested is flagged for change.
  6. Automated consistency analysis checks a formal model for conflicts.
  7. Output is a validated, baselined SRS and a list of changes.
  8. Traceability supports validation: every requirement is linked to its source and to design, code and tests, so gaps and the impact of change are visible.

Traceability. A requirements traceability matrix (RTM) is a table linking each requirement ID to its source, design element, code module and test case; it shows forward and backward links and confirms every requirement is implemented and tested.

Answer frame. For a short note: define the term, list the checks and techniques (review, prototype, test cases), state traceability with the RTM, and close with the importance of early error removal.

Asked: [14 marks] (Jun 2024) Write short notes on any two of the following: a) Requirement validation and traceability, b) Testing levels and test techniques, c) Project plan and project metrics, d) Agile estimation and planning. (Attempt (a) using this unit; (b) is Unit 2, (c) is Unit 3 and (d) is Unit 5.)

Traceability

<span style="display:inline-block;padding:.16em .6em;border:1.5px solid currentColor;border-radius:999px;font-size:.68em;font-weight:700;letter-spacing:.06em;text-transform:uppercase;opacity:.75">Not asked since 2022</span>

Definition. <mark>Traceability is the ability to follow a requirement forward to design, code and tests, and backward to its source.</mark>

Key points.

  1. It is recorded in the requirements traceability matrix.
  2. It shows the impact of a change and proves full coverage.
  3. Forward traceability goes from requirement to implementation; backward goes the other way.

Last-minute revision

  • SDLC phases: requirements, design, coding, testing, deployment, maintenance.
  • Waterfall is linear with no going back; V-model pairs each development phase with a test phase.
  • Prototype clarifies requirements; incremental delivers in parts; evolutionary refines versions.
  • RAD builds in 60-90 days with parallel teams and reuse; its phases are business, data, process modelling, application generation and turnover.
  • Spiral has four quadrants (plan, risk analysis, engineering, evaluate) and is risk-driven.
  • Basic COCOMO: $E = a(KLOC)^b$, $D = cE^d$; organic 2.4/1.05, semidetached 3.0/1.12, embedded 3.6/1.20.
  • 32 KLOC organic gives 91.3 PM and 13.9 months.
  • $FP = UFP \times VAF$, $VAF = 0.65 + 0.01\sum F_i$.
  • CMM levels: Initial, Repeatable, Defined, Managed, Optimizing.
  • Functional says what; non-functional says how well.
  • Requirement validation checks validity, consistency, completeness, realism, verifiability.
  • Traceability matrix links requirement to design, code and test.

Memory hooks

  • Spiral quadrants: "Please Rescue Every Elephant" (Plan, Risk, Engineer, Evaluate).
  • CMM: "I Really DoMa Op" (Initial, Repeatable, Defined, Managed, Optimizing).
  • COCOMO modes by size of a: 2.4, 3.0, 3.6 rising as constraints rise.
  • V-model: left side builds, right side tests, each level matched.
  • RAD: Business, Data, Process, Application, Testing, in that order.

Coverage checklist

  • Software Development Life Cycles: Jun 2025 SDLC phases.
  • SDLC Models: Waterfall: covered.
  • V-Model: covered.
  • Prototype Model: covered.
  • Incremental: covered; used in the Spiral versus Incremental comparison.
  • Evolutionary: covered.
  • RAD: Jun 2024 RAD with diagram.
  • Spiral: Jun 2023 (14 and 7 marks), Jun 2025 comparison.
  • Project Planning: covered.
  • Metrics for Project Size Estimation: covered.
  • Project Estimation Techniques: Jun 2023 COCOMO, Jun 2025 techniques.
  • Requirements Gathering and Analysis: covered.
  • Software Requirements Specification (SRS): covered.
  • Software Product and Process Characteristics: Jun 2023 product versus process.
  • Software Process Models: Jun 2024 iterative, waterfall, spiral.
  • Evolutionary Process Models and Agile processes: Jun 2024 evolutionary models.
  • Software Process customization and improvement: covered.
  • CMM: covered.
  • Product and Process Metrics: covered.
  • Functional and Non-functional requirements: Jun 2025.
  • Requirement Sources and Elicitation Techniques: covered.
  • Analysis Modeling for Function-oriented and Object-oriented software development: covered.
  • Use case Modeling: covered.
  • System and Software Requirement Specifications: covered.
  • Requirement Validation: Jun 2024 short notes (a).
  • Traceability: covered; also in the Jun 2024 short note.
Go to where you left off?

Quick Add to Notes

Save questions, your own notes and screenshots into notes filed by unit. It takes a free account.

Create free account

Have an account? Log in