Skip to content
CampusPrep
AL-403 · Software Engineering/Quick Revision Short Notes

Software Engineering (AL-403) - Unit 2 Short Notes

How unit 2 is examined

This unit covers how requirements are gathered, modelled, written down and checked; functional vs non-functional requirements, elicitation, DFD and use cases, the SRS and validation carry almost all the marks.

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">High weight</span>

Definition. <mark>A software requirement is a statement of a service the system must provide or a constraint under which it must operate; functional requirements state what the system does, and non-functional requirements state how well it does it.</mark>

Key points.

  1. Requirements are written at two levels: user requirements are high-level statements in the customer's language, and system requirements are the detailed technical description of the same services.
  2. A functional requirement describes a function, input-output behaviour or service, for example "the system shall let a registered user log in with an ID and password" or "the system shall calculate the monthly interest".
  3. A non-functional requirement is a quality or constraint on the whole system, for example "the system shall respond to a search within 2 seconds" or "passwords shall be stored encrypted".
  4. Non-functional requirements fall in three families: product requirements (performance, security, usability, reliability), organisational requirements (standards, delivery), and external requirements (legal, ethical, interoperability).
  5. Functional requirements are checked by functional (black-box) testing of each feature, while non-functional ones need measurable criteria such as load, response time or a usability survey.
  6. A functional failure means a feature is missing, but a non-functional failure can make the whole system useless even when every function works.
  7. Good requirements are clear, unambiguous, complete, consistent, testable, feasible and traceable, and requirements engineering exists to produce them before design begins.
  8. A functional specification must be complete, meaning every service and input situation is described, and consistent, meaning no two requirements contradict each other.
Basis Functional Non-functional
Purpose What the system does How well it does it, under what constraints
Concerns Features, services, data processing Performance, security, usability, reliability
Scope Individual functions System as a whole
Example Login, generate report Report in under 3 s, 99.9% uptime
Testing Functional testing Performance, security, usability testing
Source User needs and use cases Standards, environment, quality goals

Example (complete and consistent). Incomplete: "The library system shall issue a book" gives no rule for a member with unpaid fines. Inconsistent: R1 "a member may borrow 5 books" and R2 "a member may borrow at most 3 books". Gaps cause features to be missed; conflicts cause rework, so reviews and prototyping catch both.

Answer frame. Open with the definition of requirements; draw the comparison table; develop the two definitions with examples, then non-functional categories, then testing; close with "functional requirements define behaviour, non-functional define quality, and both are needed." For "complete and consistent", give the two definitions, the examples above and validation by review.

Pitfall: Writing vague non-functional requirements such as "the system shall be fast" instead of a measurable figure.

Asked: [7 marks] (Jun 2024, Jun 2025, Jun 2026) Explain Functional Requirements and Non-functional Requirements with suitable examples. Asked: [7 marks] (Jun 2024, Jun 2025) Differentiate between functional and Non Functional requirements with suitable examples / Describe functional and non-functional requirements with examples. Asked: [7 marks] (Jun 2023) "The functional requirements specification of a system should be both complete and consistent". Substantiate this statement with relevant examples. Asked: [7 marks] (Jun 2026) Define Software Requirements in detail.

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">High weight</span>

Definition. <mark>Requirements elicitation is the process of discovering, from stakeholders and other sources, what the system must do and the constraints it must meet.</mark>

Key points.

  1. Requirements engineering is the systematic process of eliciting, analysing, specifying and validating requirements; its use is to build the right system and avoid costly rework.
  2. Sources of requirements are stakeholders (customers, end users, managers), existing documents and manuals, the current system, domain experts, regulations and competing products.
  3. Interviews are structured (fixed questions) or open (free discussion); they give rich detail but depend on the interviewee's articulation and take time.
  4. Questionnaires reach many users cheaply, but answers are shallow and cannot be probed further.
  5. Workshops and brainstorming (JAD) bring stakeholders together to agree quickly and resolve conflicts, but need a skilled facilitator.
  6. Observation (ethnography) watches users at work and reveals tacit needs users forget to state, but it is slow.
  7. Prototyping shows a working mock-up so users can react, which clarifies unclear requirements, though it costs effort.
  8. Use cases and scenarios describe interactions between users and the system, and document analysis mines existing forms and reports.
  9. Technique choice depends on the number of users, the risk of misunderstanding, time and cost.

Activities of elicitation and analysis (spiral).

Step 1: Discovery - gather requirements from stakeholders and sources.
Step 2: Classification and organisation - group related requirements into clusters.
Step 3: Prioritisation and negotiation - rank them and resolve conflicts.
Step 4: Specification - document them formally, then repeat as needed.

Problems in formulating requirements. Stakeholders do not know what they want or express it in their own terms; different stakeholders conflict; requirements change during the project (volatility); ambiguity and hidden assumptions creep in; and political and organisational factors distort priorities.

Answer frame. Open with the definition; list sources; explain any two techniques (interview and prototyping) with steps, merit and limit; close with the choice criteria. For "use of requirement engineering", give the four activities then the problems. For activities, use the four-step algo.

Asked: [7 marks] (May 2019, Jun 2022, Jun 2025) Explain the ways and means for collecting the software requirements / What are the elicitation techniques used in the software requirements? Asked: [7 marks] (Jun 2020) What is the use of requirement engineering? What are the problems in formulation of Requirements? Asked: [7 marks] (Jun 2024) What are the activities of requirement elicitation and Analysis? Explain. Asked: [7 marks] (Jun 2025) What are the major requirement elicitation techniques? Discuss any two in detail.

Analysis Modeling for Function-oriented and Object-oriented 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">High weight</span>

Definition. <mark>Analysis modelling represents the requirements as models before design: function-oriented modelling shows what processes transform data (DFD), while object-oriented modelling shows the system as interacting objects and classes (UML).</mark>

Data flow diagram (functional model). A DFD shows how data moves through processes.

Key points.

  1. A DFD has four symbols: a process (circle or rounded box) transforms data, a data flow (arrow) carries data, a data store (open rectangle) holds data at rest, and an external entity (rectangle) is a source or sink outside the system.
  2. Level 0, the context diagram, shows the whole system as a single process with its external entities and flows.
  3. Level 1 splits that process into its main sub-processes with data stores; Level 2 splits a Level 1 process further, until each process is simple.
  4. Balancing means the inputs and outputs of a parent process must equal those of its child diagram.
  5. Rules: every process needs at least one input and one output, data cannot flow directly between two stores or two entities, and every flow is named.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-01" viewBox="0 0 389.6 252" width="389.6" height="252" role="img" aria-label="Level 0 idea of library system. Stu = Student (external entity), Lib = Library process, Bk = Books store, Iss = Issue log"><style>#dsfig-u2-01 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-01 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-01 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-01 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-01 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-01 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-01 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-01 .t{fill:#16181D;font-weight:500}#dsfig-u2-01 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-01 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-01 .dot{fill:#16181D}#dsfig-u2-01 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-01 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-01 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-01 .ah{fill:#454C5A}#dsfig-u2-01 .ah.hi{fill:#2340B8}#dsfig-u2-01 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-01 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-01 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-01 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-01 .e{stroke:#B1B7C3}html.dark #dsfig-u2-01 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-01 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-01 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-01 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-01 .t{fill:#E6E8ED}html.dark #dsfig-u2-01 .t.inv{fill:#0F1115}html.dark #dsfig-u2-01 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-01 .dot{fill:#E6E8ED}html.dark #dsfig-u2-01 .ann{fill:#8FA3FF}html.dark #dsfig-u2-01 .lbl{fill:#858D9C}html.dark #dsfig-u2-01 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-01 .ah{fill:#B1B7C3}html.dark #dsfig-u2-01 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-01 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-01 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-01 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah8" 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="ahh8" 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.6,133.3 Q117.4,158 175.4,134" marker-end="url(#ah8)"/><path class="e" d="M177.2,118.7 Q117.4,94 59.4,118" marker-end="url(#ah8)"/><path class="e" d="M213.2,115.8 L331.2,50.2" marker-end="url(#ah8)" marker-start="url(#ah8)"/><path class="e" d="M211.4,135.2 L331.2,201.8" marker-end="url(#ah8)"/><g class="wl"><rect x="86.2" y="136.8" width="61.5" height="18" rx="9"/><text class="t" x="116.9" y="145.8" dy=".35em" text-anchor="middle">request</text></g><g class="wl"><rect x="87.1" y="97.2" width="61.5" height="18" rx="9"/><text class="t" x="117.9" y="106.2" dy=".35em" text-anchor="middle">receipt</text></g><g class="wl"><rect x="245.1" y="74" width="54.3" height="18" rx="9"/><text class="t" x="272.2" y="83" dy=".35em" text-anchor="middle">record</text></g><g class="wl"><rect x="248.7" y="160" width="47.1" height="18" rx="9"/><text class="t" x="272.2" y="169" dy=".35em" text-anchor="middle">issue</text></g><circle class="n" cx="40" cy="126" r="18"/><text class="t" x="40" y="126" dy=".35em" text-anchor="middle">Stu</text><circle class="n" cx="194.8" cy="126" r="18"/><text class="t" x="194.8" y="126" dy=".35em" text-anchor="middle">Lib</text><circle class="n" cx="349.6" cy="40" r="18"/><text class="t" x="349.6" y="40" dy=".35em" text-anchor="middle">Bk</text><circle class="n" cx="349.6" cy="212" r="18"/><text class="t" x="349.6" y="212" dy=".35em" text-anchor="middle">Iss</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">Level 0 idea of library system. Stu = Student (external entity), Lib = Library process, Bk = Books store, Iss = Issue log</figcaption></figure>

Basis Function-oriented Object-oriented
Decomposition Into functions and sub-functions Into objects and classes
Focus Processes and data flow Data and behaviour together
Data Shared, global, separate from functions Encapsulated inside objects
Notation DFD, data dictionary, structure chart UML: use case, class, sequence
Reuse Low, functions are tied to the system High, through classes and inheritance
Maintenance A change ripples across functions Changes are localised in classes
Suits Data-processing, well-defined systems Complex, evolving, interactive systems

Answer frame. For comparison: open by defining both approaches; draw the table; close with suitability (structured for data processing, OO for large changing systems). For DFD: define, draw Level 0 and Level 1, list symbols, then balancing rules.

Asked: [7 marks] (Dec 2020, Jun 2020, Nov 2023, Jun 2026) What is difference between function oriented and object oriented Modeling? Explain in detail / Compare two approaches used in analysis and modeling. Asked: [7 marks] (Jun 2020) Explain the concept of functional modeling with an illustrative example. Asked: [7 marks] (Jun 2022) Explain in detail about the DFD and its levels.

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">High weight</span>

Definition. <mark>A use case model describes the functional requirements of a system as the interactions between external actors and the system's use cases, drawn as a UML use case diagram.</mark>

Key points.

  1. The four basic parts are actors, use cases, relationships and the system boundary.
  2. An actor is a person or external system that interacts with the system, drawn as a stick figure.
  3. A use case is one complete function that gives value to an actor, drawn as an oval inside the boundary.
  4. Relationships are association (actor to use case), include (a mandatory shared sub-step) and extend (an optional or exceptional addition); generalisation relates specialised actors or use cases.
  5. The system boundary is a rectangle enclosing the use cases, separating the system from its environment.
  6. Its benefits are that users and developers share one simple view, and each use case seeds test cases.

Steps to make it.

Step 1: Identify the system boundary and its actors.
Step 2: Identify the goals of each actor as use cases.
Step 3: Draw associations between actors and use cases.
Step 4: Add include and extend relations between use cases.
Step 5: Write the scenario of each use case and review with users.

<figure class="ds-fig" style="margin:1.4rem 0;overflow-x:auto"><svg xmlns="http://www.w3.org/2000/svg" id="dsfig-u2-02" viewBox="0 0 553 252" width="553" height="252" role="img" aria-label="ATM use case diagram. Cus = Customer, Bnk = Bank (actor), Log = Login, Wdr = Withdraw cash, Bal = Balance enquiry, Pin = Verify PIN. Draw the boundary rectangle around Log, Wdr, Bal, Pin"><style>#dsfig-u2-02 .e{stroke:#454C5A;stroke-width:1.4;fill:none}#dsfig-u2-02 .e.hi{stroke:#2340B8;stroke-width:2.6}#dsfig-u2-02 .n{fill:#FFFFFF;stroke:#16181D;stroke-width:1.4}#dsfig-u2-02 .n.hi{fill:#E3E9FC;stroke:#2340B8;stroke-width:2.2}#dsfig-u2-02 .n.rb-b{fill:#16181D;stroke:#16181D}#dsfig-u2-02 .n.rb-r{fill:#BD3227;stroke:#BD3227}#dsfig-u2-02 text{font-family:"JetBrains Mono",ui-monospace,Menlo,Consolas,monospace;font-size:13px}#dsfig-u2-02 .t{fill:#16181D;font-weight:500}#dsfig-u2-02 .t.inv{fill:#FFFFFF;font-weight:700}#dsfig-u2-02 .kd{stroke:#16181D;stroke-width:1.2}#dsfig-u2-02 .dot{fill:#16181D}#dsfig-u2-02 .ann{fill:#2340B8;font-size:11px;font-weight:700}#dsfig-u2-02 .lbl{fill:#6F7787;font-family:system-ui,-apple-system,sans-serif;font-size:12px;font-weight:700}#dsfig-u2-02 .ptr{fill:#2340B8;font-size:12px;font-weight:700}#dsfig-u2-02 .ah{fill:#454C5A}#dsfig-u2-02 .ah.hi{fill:#2340B8}#dsfig-u2-02 .wl rect{fill:#FFFFFF;stroke:#DCE0E7}#dsfig-u2-02 .wl .t{font-size:12px;font-weight:700}#dsfig-u2-02 .wl.hi rect{fill:#2340B8;stroke:#2340B8}#dsfig-u2-02 .wl.hi .t{fill:#FFFFFF}html.dark #dsfig-u2-02 .e{stroke:#B1B7C3}html.dark #dsfig-u2-02 .e.hi{stroke:#8FA3FF}html.dark #dsfig-u2-02 .n{fill:#161920;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.hi{fill:#1E2748;stroke:#8FA3FF}html.dark #dsfig-u2-02 .n.rb-b{fill:#E6E8ED;stroke:#E6E8ED}html.dark #dsfig-u2-02 .n.rb-r{fill:#FF7E71;stroke:#FF7E71}html.dark #dsfig-u2-02 .t{fill:#E6E8ED}html.dark #dsfig-u2-02 .t.inv{fill:#0F1115}html.dark #dsfig-u2-02 .kd{stroke:#E6E8ED}html.dark #dsfig-u2-02 .dot{fill:#E6E8ED}html.dark #dsfig-u2-02 .ann{fill:#8FA3FF}html.dark #dsfig-u2-02 .lbl{fill:#858D9C}html.dark #dsfig-u2-02 .ptr{fill:#8FA3FF}html.dark #dsfig-u2-02 .ah{fill:#B1B7C3}html.dark #dsfig-u2-02 .ah.hi{fill:#8FA3FF}html.dark #dsfig-u2-02 .wl rect{fill:#161920;stroke:#2A2E37}html.dark #dsfig-u2-02 .wl.hi rect{fill:#8FA3FF;stroke:#8FA3FF}html.dark #dsfig-u2-02 .wl.hi .t{fill:#0F1115}</style><defs><marker id="ah9" 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="ahh9" 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="M55.2,157.6 L196.8,51.4"/><path class="e" d="M58.4,164.4 L193.6,130.6"/><path class="e" d="M58.4,173.6 L193.6,207.4"/><path class="e" d="M230.4,121.4 L363.6,88.1" marker-end="url(#ah9)"/><path class="e" d="M230.4,44.6 L363.6,77.9" marker-end="url(#ah9)"/><path class="e" d="M494.2,166.3 L230.8,128.7"/><g class="wl"><rect x="267.3" y="95.5" width="61.5" height="18" rx="9"/><text class="t" x="298" y="104.5" dy=".35em" text-anchor="middle">include</text></g><g class="wl"><rect x="267.3" y="52.5" width="61.5" height="18" rx="9"/><text class="t" x="298" y="61.5" dy=".35em" text-anchor="middle">include</text></g><circle class="n" cx="40" cy="169" r="18"/><text class="t" x="40" y="169" dy=".35em" text-anchor="middle">Cus</text><circle class="n" cx="212" cy="40" r="18"/><text class="t" x="212" y="40" dy=".35em" text-anchor="middle">Log</text><circle class="n" cx="212" cy="126" r="18"/><text class="t" x="212" y="126" dy=".35em" text-anchor="middle">Wdr</text><circle class="n" cx="212" cy="212" r="18"/><text class="t" x="212" y="212" dy=".35em" text-anchor="middle">Bal</text><circle class="n" cx="384" cy="83" r="18"/><text class="t" x="384" y="83" dy=".35em" text-anchor="middle">Pin</text><circle class="n" cx="513" cy="169" r="18"/><text class="t" x="513" y="169" dy=".35em" text-anchor="middle">Bnk</text></svg><figcaption style="font-size:.82em;opacity:.72;margin-top:.45rem">ATM use case diagram. Cus = Customer, Bnk = Bank (actor), Log = Login, Wdr = Withdraw cash, Bal = Balance enquiry, Pin = Verify PIN. Draw the boundary rectangle around Log, Wdr, Bal, Pin</figcaption></figure>

For a ticket reservation system, the actors are Customer and Payment Gateway; use cases are Search, Book Ticket, Pay (included by Book Ticket), Cancel and Check Status; Print Ticket extends Book Ticket.

Answer frame. Open with the definition; draw the diagram inside a system boundary with labelled ovals; explain the four parts, then the steps, then include/extend; close with benefits. For "ATM" or "ticket booking", state actors first, then use cases, then the diagram.

Pitfall: Drawing the actor inside the boundary or using include and extend the wrong way round.

Asked: [7 marks] (May 2019) Explain the use case diagram of ATM machine with neat diagram. Asked: [7 marks] (Jun 2020) Draw a use case diagram for booking a ticket in a reservation system. Asked: [7 marks] (Jun 2023, Dec 2024, Jun 2025) What is the use-case model and how to make it? Discuss the four basic parts of a use-case model. Asked: [7 marks] (Dec 2024, Jun 2025) Discuss briefly about Use case Model with neat sketch? / Explain use case modeling with the help of an example.

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">High weight</span>

Definition. <mark>The Software Requirements Specification (SRS) is a formal document that states completely and unambiguously what the software shall do, serving as the agreement between customer and developer.</mark>

Key points.

  1. System requirements describe the services of the whole system, including hardware and people, while software requirements describe only the software part in more detail.
  2. The SRS is the contract between customer and developer, so it settles what counts as a delivered product.
  3. Developers use it as the basis of design and coding, testers derive test cases from it, and managers use it for estimation and planning.
  4. Characteristics of a good SRS: correct, complete, consistent, unambiguous, verifiable, modifiable, traceable and ranked for importance.
  5. IEEE 830 structure has an Introduction (purpose, scope, definitions), an Overall Description (product perspective, functions, users, constraints), Specific Requirements and Appendices.
  6. Specific Requirements hold the functional requirements, external interface requirements, performance requirements, design constraints and quality attributes.
  7. An SRS should state what the system does, never how it is designed.

Answer frame. Open with the definition; list the uses (contract, design, testing), then characteristics, then the IEEE contents; close that a good SRS reduces cost of change. For SRS and validation, add a short validation section (see next topic).

Asked: [7 marks] (Jun 2024, Jun 2025) Discuss the components of a software requirement specification document? / What are the key contents of an SRS document? Asked: [7 marks] (Jun 2022) How software requirements specifications are used in the development of the software? Write the characteristics for the SRS. Asked: [7 marks] (Nov 2023) Discuss about system and software requirement specifications. Asked: [7 marks] (Jun 2026) Explain the Software Requirement Specification (SRS) and Requirement Validation.

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 is the process of checking that the requirements define the system the customer really wants, and that they are complete, consistent and realistic.</mark>

Key points.

  1. Validity check: does each requirement really serve a stakeholder need, and do all stakeholders agree?
  2. Consistency check: no requirements conflict with each other.
  3. Completeness check: all functions and constraints the user intended are included.
  4. Realism check: the requirements can be implemented within the budget, time and technology.
  5. Verifiability check: each requirement can be tested, so it must be written measurably.
  6. Techniques: requirements reviews by a team, prototyping to let users try the system, and test-case generation, where an untestable requirement shows a flaw.
  7. Fixing an error at this stage costs far less than fixing it after coding.

Short notes (Jun 2022).

  • Dynamic analysis is the examination of a program by executing it with test data, to observe behaviour, failures, performance and coverage; it complements static analysis, which inspects code without running it.
  • Software quality assurance (SQA) is the set of planned activities such as standards, reviews, audits, testing and process monitoring that ensure the product and process meet quality requirements.

Answer frame. Open with the purpose; list the five checks with one line each; then the techniques; close with the cost argument.

Asked: [14 marks] (Jun 2022) Write short notes on: a) Requirement validation b) Dynamic analysis c) Software quality assurance Asked: [7 marks] (Dec 2024) Describe different checks to be carried out during requirement validation process?

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>Requirements traceability is the ability to follow a requirement forward to design, code and tests, and backward to its source.</mark>

Key points.

  1. A traceability matrix is a table with requirements as rows and design elements, code modules and test cases as columns, marked where linked.
  2. Forward traceability maps each requirement to its implementation and tests, so no requirement is left unbuilt.
  3. Backward traceability maps each design element or test to a requirement, so no unnecessary work is done.
  4. It supports impact analysis of change: the matrix shows which parts a changed requirement affects.

Last-minute revision

  • A requirement is a service the system must provide or a constraint on it; functional means what, non-functional means how well.
  • Non-functional families: product, organisational, external.
  • Complete means nothing missing; consistent means nothing conflicting.
  • Elicitation techniques: interview, questionnaire, workshop, observation, prototyping, use cases.
  • Elicitation and analysis activities: discovery, classification, prioritisation, negotiation.
  • DFD symbols: process, flow, store, external entity; Level 0 is the context diagram.
  • Balancing: a child DFD has the same inputs and outputs as its parent process.
  • Use case model parts: actors, use cases, relationships, system boundary.
  • SRS follows IEEE 830: Introduction, Overall Description, Specific Requirements, Appendices.
  • Validation checks: validity, consistency, completeness, realism, verifiability.
  • Traceability matrix links requirement to design, code and test.

Memory hooks

  • "What vs How well": functional vs non-functional.
  • "IQWOP": Interview, Questionnaire, Workshop, Observation, Prototype.
  • "CCRVV": Completeness, Consistency, Realism, Validity, Verifiability checks.
  • "APRS": Actor, Process, Relationship, System boundary.
  • "DCPN": Discovery, Classification, Prioritisation, Negotiation.

Coverage checklist

  • Functional and Non-functional requirements: Jun 2024/2025/2026 explain, Jun 2024/2025 differentiate, Jun 2023 complete and consistent, Jun 2026 define software requirements.
  • Requirement Sources and Elicitation Techniques: ways of collecting requirements, use of requirement engineering and problems, elicitation and analysis activities, major techniques.
  • Analysis Modeling for Function-oriented and Object-oriented software development: function vs object oriented (four sessions), functional modelling, DFD and levels.
  • Use case Modeling: ATM diagram, ticket reservation diagram, use-case model and four parts, use case model with sketch.
  • System and Software Requirement Specifications: SRS components, SRS use and characteristics, system and software requirements, SRS and validation.
  • Requirement Validation: short notes (validation, dynamic analysis, SQA), validation checks.
  • Traceability: definition, matrix, forward and backward tracing.
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