Requirements Analysis and Project Planning

Introduction

A software project rarely fails because programmers cannot write code. More often, failure begins earlier: the team builds the wrong product, misunderstands stakeholder expectations, underestimates the work, or discovers important constraints too late. Requirements analysis and project planning provide the disciplined bridge between an idea and a deliverable Java or Python system.

Requirements analysis determines what a system must do, how well it must perform, and what limits govern its development. Project planning determines how the work will be organised, estimated, scheduled, monitored, and controlled. These activities are not purely administrative. They influence architecture, database design, testing, security, maintainability, cost, and user satisfaction.

This chapter presents practical techniques for eliciting and documenting requirements through user stories, use cases, acceptance criteria, and scope statements. It also introduces risk registers, estimation methods, scheduling, prioritisation, traceability, and change control. The examples use a small software project suitable for implementation in either Java or Python.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish functional requirements from non-functional requirements.
2. Identify stakeholders and select appropriate elicitation techniques.
3. Write clear user stories, use cases, and acceptance criteria.
4. Define project scope, assumptions, constraints, deliverables, and exclusions.
5. Identify, assess, and respond to project risks.
6. Estimate effort and construct a realistic project schedule.
7. Apply prioritisation, dependency analysis, traceability, and change control.
8. Evaluate the quality and limitations of a requirements and planning document.

1. The Role of Requirements in Software Development

A requirement is a documented need, capability, condition, or constraint that a system, service, or project must satisfy. Requirements may originate from customers, end users, managers, regulators, technical staff, or the development team.

Requirements are often classified into four related categories:

A requirement should be sufficiently clear that developers can implement it and testers can verify it. Statements such as “the system should be user-friendly” are important intentions but are too vague to test. A stronger version might be: “A first-time user can complete a book search without training, using no more than four screens.” Even this statement should be validated with stakeholders and refined into an appropriate measurable criterion.

Requirements are not necessarily permanent. They evolve as stakeholders learn more about the problem, technical constraints become visible, or laws and business priorities change. Consequently, requirements analysis is an iterative activity rather than a single meeting at the beginning of a project.

2. Stakeholders and Elicitation

A stakeholder is any person or organisation that can affect, be affected by, or have an interest in the project. Typical stakeholders include:

• sponsors who provide funding or authority;
• customers who commission the product;
• end users who operate it;
• domain experts who understand business rules;
• developers, testers, and support staff;
• security, legal, and compliance representatives; and
• external service or infrastructure providers.

A stakeholder register records stakeholder identity, role, influence, interests, communication needs, and involvement. It prevents the team from designing exclusively for the loudest or most accessible participant.

Elicitation techniques

No single technique reveals every requirement. Effective analysts combine methods.

Interviews provide depth and allow follow-up questions. They are useful for understanding work practices and exceptions, but answers may reflect personal preferences rather than organisational policy.

Workshops bring several stakeholders together to resolve differences and agree on priorities. They require skilled facilitation because dominant participants can suppress minority views.

Observation reveals actual behaviour, workarounds, and environmental constraints that users may not mention. It is particularly valuable where staff perform repetitive or safety-critical processes.

Questionnaires reach many people efficiently, but generally provide less context and allow limited exploration.

Document analysis examines policies, forms, reports, existing software, contracts, and regulations. It is important where the new system must preserve established rules.

Prototyping uses sketches, wireframes, or a limited working model to obtain feedback. A prototype clarifies interaction requirements, but stakeholders may mistakenly assume that a visually polished prototype is nearly complete.

User stories and use cases organise requirements around goals and interactions. They are discussed in detail below.

Elicitation should also identify exceptions, alternative workflows, data ownership, privacy expectations, accessibility needs, integration points, and success measures. The analyst should record unresolved questions rather than silently converting assumptions into requirements.

3. Functional and Non-Functional Requirements

Functional requirements

A functional requirement describes a service, transformation, rule, or response. Examples include:

• The system shall allow a registered member to borrow an available book.
• The system shall reject a loan when the member has reached the borrowing limit.
• The system shall send an email when a reserved book becomes available.
• The system shall export monthly circulation data as a CSV file.

A useful functional requirement identifies an actor, an action, relevant data, and a result. Where necessary, it also states business rules and exceptions.

Non-functional requirements

Non-functional requirements describe qualities or constraints rather than individual business functions. Common categories include:

Non-functional requirements must be measurable where possible. “The system must be secure” is a goal; “after five unsuccessful login attempts within 15 minutes, the account is temporarily locked and the event is logged” is more testable. Non-functional requirements can constrain the entire architecture. For example, a strict response-time requirement may influence database indexing, caching, network design, and monitoring.

A common error is to treat non-functional requirements as optional enhancements. A system that produces correct results but exposes private information or cannot be used by its intended audience is not a successful system.

4. User Stories

A user story is a brief statement of a user-valued capability, commonly written as:

As a [role], I want [capability], so that [benefit].

For example:

As a library member, I want to renew an eligible loan online so that I do not need to visit the library.

The format encourages the team to focus on user value rather than prematurely prescribing a technical solution. A story is not a complete specification. It is a prompt for conversation and must be supported by acceptance criteria, design discussion, and tests.

A useful story should be:

• Independent, as far as practical;
• Negotiable, allowing discussion of implementation;
• Valuable, providing a recognisable benefit;
• Estimable, containing enough information for effort assessment;
• Small, so that it can be completed within an iteration; and
• Testable, with observable completion conditions.

These properties are often summarised by the acronym INVEST. They are guidelines rather than absolute laws. For example, technical dependencies may make complete independence impossible.

Story decomposition

A large story such as “As an administrator, I want to manage all library operations” is not estimable or testable. It can be decomposed into smaller stories:

• create a member record;
• update a member’s contact details;
• suspend a member account;
• record a book loan; and
• produce a circulation report.

Stories should describe outcomes, not implementation tasks. “As a developer, I want to create a LoanService class” may be a legitimate technical task, but it is not normally a user story because it does not express user value. Such work can appear as a technical task linked to one or more stories.

5. Use Cases

A use case describes a goal-oriented interaction between an actor and a system. It is especially useful when a process has several steps, alternative paths, or important exceptions.

A use-case specification commonly contains:

• use-case name and identifier;
• primary actor and supporting actors;
• goal and brief description;
• trigger and preconditions;
• main success scenario;
• alternative and exception flows;
• postconditions;
• business rules and special requirements.

Example: Record a loan

Identifier: UC-03 Record loan

Primary actor: Librarian

Goal: Record the issue of an available book to an eligible member.

Preconditions: The librarian is authenticated; the member and book exist.

Trigger: The librarian selects “Issue book”.

Main success scenario:

1. The librarian enters or scans the member identifier.
2. The system displays the member’s status and current loans.
3. The librarian enters or scans the book identifier.
4. The system verifies that the book is available and that the member is eligible.
5. The system creates a loan with a due date.
6. The system marks the book as unavailable.
7. The system displays confirmation and the due date.

Alternative flows:

• If the member has reached the borrowing limit, the system refuses the loan and explains the reason.
• If the book is reserved for another member, the system refuses the loan.
• If the book identifier is invalid, the system requests correction.

Postconditions: For a successful transaction, one loan is recorded and the book status is updated consistently.

A use case complements, rather than replaces, user stories. The story expresses why the capability matters; the use case explains how interaction and exceptions are handled.

6. Acceptance Criteria and Requirement Quality

Acceptance criteria define the conditions under which a story or requirement is accepted by the customer or product owner. They form a bridge between analysis, implementation, and testing.

For the renewal story, criteria might include:

1. A logged-in member can renew a loan that has no outstanding reservation.
2. The system extends the due date by the configured renewal period.
3. The system refuses renewal when the renewal limit has been reached.
4. The system displays a clear reason when renewal is refused.
5. A successful renewal is recorded in the loan history.

The Given–When–Then style is useful for expressing behaviour:

Given a member has an eligible loan and no reservation exists,

When the member selects Renew,

Then the system updates the due date and displays confirmation.

Acceptance criteria should be observable, unambiguous, consistent, feasible, and testable. They should cover normal behaviour, validation, security-relevant conditions, and important exceptions. Criteria are not the same as test scripts: a criterion states what must be true, while a test specifies how evidence will be collected.

Quality checklist

A well-formed requirement is generally:

• Correct: it reflects a genuine stakeholder need;
• Complete: necessary conditions and exceptions are included;
• Consistent: it does not contradict another requirement;
• Unambiguous: it has one reasonable interpretation;
• Feasible: it can be delivered within known constraints;
• Verifiable: evidence can show whether it is satisfied;
• Traceable: its origin and related tests are identifiable; and
• Prioritised: its relative importance is understood.

Traceability can be represented as a chain from business objective to requirement, design element, implementation task, and test. It is particularly valuable when a requirement changes or when compliance evidence is required.

7. Scope, Assumptions, Constraints, and Deliverables

A scope statement establishes the boundaries of the project. It should identify the problem, intended users, product boundary, major capabilities, deliverables, exclusions, assumptions, constraints, and success measures.

For example, the scope of a small library system might include member registration, catalogue search, loans, returns, renewals, and a basic report. It might explicitly exclude online payments, inter-library loans, a mobile application, and integration with national library systems.

The distinction between scope elements is important:

• In scope: work the project promises to deliver;
• Out of scope: related work deliberately excluded;
• Assumption: a condition treated as true for planning purposes;
• Constraint: a restriction imposed on the project; and
• Deliverable: a tangible product, document, or result submitted or released.

Examples of assumptions include access to a test database and availability of a domain expert for two hours each week. Constraints might include a fixed academic submission date, an approved Java or Python version, limited hosting resources, or a requirement to use institutional authentication.

Scope creep occurs when work is added without corresponding evaluation of time, cost, resources, or risk. A change is not automatically bad; uncontrolled change is the problem. Every proposed change should be assessed for value, impact, dependencies, and approval authority.

8. Prioritisation and the Minimum Viable Product

Prioritisation helps a team deliver the highest-value capabilities first. The MoSCoW method categorises requirements as:

• Must have: essential for a viable release;
• Should have: important but a temporary workaround exists;
• Could have: desirable if resources permit; and
• Won’t have this release: deliberately deferred.

Priorities should be justified by user value, risk, legal obligation, dependency, and effort—not merely by the personal preference of one stakeholder. A minimum viable product (MVP) is the smallest product that can provide meaningful value and generate learning. It is not a careless or defective version; essential security, data integrity, accessibility, and legal obligations remain essential even in an MVP.

A prioritisation workshop can use a simple matrix of value versus effort. Such a matrix supports discussion, but it does not replace analysis of risk or dependencies. For instance, a low-value technical capability may be necessary before several high-value features can operate.

9. Risk Management

A project risk is an uncertain event or condition that may affect objectives. A risk is not the same as an issue: a risk may occur in the future, whereas an issue is already happening.

A risk register normally contains an identifier, description, cause, consequence, probability, impact, exposure or rating, owner, response, trigger, and status.

A simple qualitative risk score is often calculated as:

where R is the risk score, P is the assigned probability rating, and I is the assigned impact rating. If both are rated from 1 to 5, the score ranges from 1 to 25. This is an ordinal prioritisation aid, not a probability law or a prediction of monetary loss. The scale must be defined consistently by the organisation.

For example, if the risk “the external authentication service is unavailable during integration” has probability 4 and impact 5, then R = 4 × 5 = 20. It should receive more attention than a risk scored 6, although the team should still examine the reasoning behind each rating.

A more quantitative expected-loss model may be used when monetary estimates are credible:

where EMV is expected monetary value, p is the probability of occurrence expressed from 0 to 1, and L is the financial loss if the event occurs. This model assumes that the probability and loss estimates are meaningful and that the decision-maker is comfortable using an average expected value. It should not be used to conceal uncertainty or to compare incomparable consequences, such as financial loss and harm to individuals.

Typical response strategies are:

• Avoid: change the plan so the threat cannot occur;
• Mitigate: reduce probability or impact;
• Transfer: assign responsibility through a contract or service, while recognising that accountability may remain;
• Accept: monitor the risk without immediate action; and
• Exploit or enhance: increase the probability or benefit of a positive opportunity.

A risk owner monitors the risk and ensures that the agreed response is carried out. Risks should be reviewed at milestones, not merely created once in a spreadsheet.

10. Estimation

Estimation supports decisions about scope, staffing, release dates, and contingency. An estimate is not a promise. It is a reasoned forecast based on available information and should be revised when knowledge improves.

Relative estimation

Agile teams often estimate relative size using story points. A point is not a fixed number of hours; it represents comparative effort, complexity, uncertainty, and volume. A team may compare stories using a sequence such as 1, 2, 3, 5, 8, and 13. A story rated 8 is not necessarily twice as many hours as one rated 4. The scale communicates uncertainty and relative difficulty.

Three-point estimation

When uncertainty is significant, three-point estimates can be used. Let a be the optimistic estimate, m the most likely estimate, and b the pessimistic estimate. A PERT-style weighted estimate is:

The estimate has the same unit as the inputs, such as staff-hours or days. The method assumes that the three values are plausible estimates for the same work and that the most-likely case deserves four times the weight of each extreme. It is a planning approximation, not a guarantee.

Suppose implementing catalogue search is estimated at 2 days optimistically, 4 days most likely, and 8 days pessimistically:

The team should not round this result mechanically without considering calendars, interruptions, dependencies, and whether partial days are realistic. If a working day contains 7 productive hours, the corresponding effort estimate is approximately 30.3 productive hours, but elapsed duration may be longer because of reviews, waiting, and other tasks.

Effort and duration

Effort is the amount of labour required; duration is calendar time. They are not interchangeable. A task requiring 16 person-hours might take one person two working days, but assigning four people does not necessarily produce four hours of duration because of communication, task indivisibility, and dependencies.

A useful planning relationship is:

The division is only a rough special case when work is perfectly divisible, people are available simultaneously, and communication and dependency costs are negligible—conditions rarely met in software development.

11. Scheduling and Dependencies

A schedule translates work into an ordered plan. It should identify activities, estimates, predecessors, responsible people, milestones, deliverables, and review points. Common representations include a work breakdown structure, task list, Gantt chart, Kanban board, or iteration plan.

A work breakdown structure decomposes a deliverable into smaller work packages. For a Python or Java library system, a high-level breakdown might include requirements, domain model, persistence, authentication, loan workflows, user interface, testing, deployment, and documentation.

Dependencies may be:

• Finish-to-start: Task B cannot start until Task A finishes;
• Start-to-start: Task B cannot start until Task A starts;
• Finish-to-finish: Task B cannot finish until Task A finishes; or
• External: a supplier, approval, or service controls timing.

The critical path is the sequence of dependent activities that determines the shortest possible project duration under the stated estimates and dependencies. Delaying an activity on this path generally delays the project unless the schedule is changed. A task with no visible coding may still be critical—for example, obtaining access credentials or approving a data-protection design.

A practical academic schedule should include time for clarification, code review, integration, testing, defect correction, documentation, demonstrations, and contingency. Scheduling every hour as productive coding creates a plan that is precise but unrealistic.

12. Integrated Applied Case: Campus Equipment-Lending System

The following is an illustrative case, not a report of an actual institution.

Background and problem

A college currently records loans of cameras, microphones, and laptops in spreadsheets. Students wait while staff search records, equipment availability is sometimes inaccurate, and overdue items are difficult to track. A diploma project team is asked to build a web-based system using Java or Python.

Stakeholder analysis

The stakeholders are students, equipment-desk staff, the project sponsor, technical support staff, and the college data-protection officer. Students need rapid searching and reservations. Desk staff need reliable check-out and return workflows. The data-protection officer requires limited collection and appropriate access controls.

Initial scope

In scope: authenticated staff access, equipment catalogue, availability search, student loan records, check-out and return, overdue display, and a basic monthly report.

Out of scope: payment processing, repair management, mobile-native applications, and integration with the college finance system.

Assumptions: an institutional identity service is available; each item has a unique barcode; the team receives a test database.

Constraints: a twelve-week academic schedule, two student developers, an approved runtime, and no production access during development.

Sample requirements

• FR-01: A staff member shall search equipment by name, category, and availability.
• FR-02: A staff member shall record a loan only when the item is available and the borrower is eligible.
• FR-03: The system shall record the borrower, item, issue time, due time, and staff member.
• NFR-01: Search results shall be displayed within two seconds for 95% of test searches using 20,000 catalogue records.
• NFR-02: A user shall see only functions authorised for that user’s role.
• NFR-03: The system shall maintain an audit record for loan creation and return.

Story and acceptance criteria

As an equipment-desk staff member, I want to check out an available item to an eligible student so that the loan is recorded accurately.

Acceptance criteria:

1. Given a valid student and available item, when the staff member confirms checkout, then exactly one active loan is created.
2. The item status changes to On loan.
3. The system displays the due time and borrower.
4. Given an unavailable item, checkout is refused and no loan is created.
5. A failed attempt does not change item status or create a partial record.

The fifth criterion expresses an integrity requirement. It implies that the operation should behave transactionally: either all necessary updates succeed, or none is committed. The implementation technology—Java transaction management, Python database transaction handling, or another mechanism—should be selected during design, but the requirement is stated in user and system terms.

Risk register extract

The ratings use a 1–5 ordinal scale, so the scores guide attention but do not establish exact probabilities.

Estimate and schedule

The team uses three-point estimates for major work packages:

For requirements and prototype, E = (2 + 4×4 + 7) ÷ 6 = 25 ÷ 6 ≈ 4.17 days. The team schedules requirements first, begins the catalogue model while interface prototypes are reviewed, and starts integration only after core data rules are agreed. Testing is distributed throughout development but receives a dedicated final period.

Outcome and learning points

In the illustrative outcome, the team delivers the MVP with catalogue search, staff checkout, return, role control, and audit records. Reservation notifications are deferred because the external messaging service was not available. The explicit scope boundary allows the team to explain this decision without presenting the result as a failure.

The case demonstrates that planning is a connected system: stakeholder analysis influences requirements; requirements define acceptance tests; acceptance tests influence tasks; tasks require estimates and dependencies; risks alter the schedule; and scope decisions protect the release objective.

13. Governance, Ethics, and Contemporary Practice

Requirements often concern personal data, access privileges, accessibility, and automated decisions. Analysts should apply privacy-by-design principles: collect only necessary data, define retention, restrict access, protect credentials, log sensitive actions appropriately, and provide a process for correction or deletion where required by applicable policy or law.

Accessibility should be considered during requirements elicitation rather than added after implementation. Keyboard operation, readable contrast, screen-reader compatibility, understandable error messages, and alternatives to colour-only indicators may be relevant.

Security requirements should include authentication, authorisation, input validation, secure dependency management, logging, backup, and recovery. A requirement to “use Java” or “use Python” specifies a technology constraint, not a security strategy. Libraries and frameworks must be maintained, and secrets must not be committed to source control.

AI-assisted tools can help brainstorm questions, classify preliminary requirements, generate test-data ideas, or identify inconsistent wording. They can also produce fabricated assumptions, insecure code, biased interpretations, or disclose confidential information. Human stakeholders remain accountable for validating requirements, and sensitive project material should not be entered into an unauthorised service. AI output should be treated as a draft requiring review, traceability, and testing.

14. Challenges and Limitations

Requirements work has inherent difficulties. Stakeholders may disagree because they have different incentives. Users may describe current procedures rather than desired outcomes. Non-functional requirements can be difficult to measure. Estimates can be distorted by optimism, pressure, or lack of historical data. A schedule may become obsolete when a dependency changes.

Documentation also has costs. Excessive detail can become outdated and discourage reading, while insufficient detail causes ambiguity. The appropriate level depends on project risk, team size, regulatory obligations, and expected change. A small student project may use a concise requirements backlog and traceability table; a safety-critical system requires much stronger evidence and formal control.

The response is not to seek perfect certainty before coding. Instead, teams should make assumptions visible, validate high-risk requirements early, use prototypes, review acceptance criteria, maintain version history, and revisit estimates as evidence improves.

Best-Practice Checklist

Before implementation begins, the team should be able to answer yes to most of the following questions:

• Have all important stakeholder groups been identified?
• Does each major capability have a clear user or business value?
• Are functional and non-functional requirements distinguished?
• Are requirements testable and free from avoidable ambiguity?
• Are exceptions, permissions, data needs, and integrations documented?
• Is the project boundary explicit, including exclusions?
• Have assumptions and constraints been recorded?
• Are risks assigned owners and response actions?
• Do estimates identify uncertainty and distinguish effort from duration?
• Does the schedule include dependencies, reviews, testing, and contingency?
• Can each accepted requirement be traced to implementation and evidence?
• Is there a process for approving changes?

Chapter Summary

Requirements analysis converts stakeholder needs into clear, testable statements about system behaviour, quality, and constraints. Functional requirements describe services and rules; non-functional requirements describe qualities such as performance, security, usability, availability, and maintainability. Interviews, workshops, observation, document analysis, prototyping, user stories, and use cases provide complementary elicitation methods.

User stories express a valuable capability from a role’s perspective, while use cases describe interactions, alternatives, and exceptions. Acceptance criteria make completion observable and support testing. Good requirements are correct, complete, consistent, feasible, verifiable, traceable, and prioritised.

A scope statement defines what the project will and will not deliver, together with assumptions, constraints, deliverables, and success measures. Prioritisation supports an achievable MVP. Risk registers make uncertainty visible and support responses such as avoidance, mitigation, transfer, and acceptance. Qualitative risk scores and three-point estimates are useful planning aids when their assumptions and limitations are understood.

A realistic schedule distinguishes effort from duration, represents dependencies, includes review and testing activities, and is revised as knowledge improves. Governance, privacy, accessibility, security, and responsible use of AI must be considered during analysis rather than treated as late additions. Effective planning is therefore not paperwork separate from development; it is a foundation for building the correct Java or Python system responsibly and predictably.

Key Terms

Requirement: A need, capability, condition, or constraint that a system or project must satisfy.

Stakeholder: A person or organisation that affects, is affected by, or has an interest in a project.

Elicitation: The systematic discovery and clarification of requirements.

Functional requirement: A statement of behaviour or service that a system must provide.

Non-functional requirement: A quality attribute, constraint, or operational property of a system.

User story: A concise statement of a capability expressed from a user role’s perspective.

Use case: A structured description of interactions between an actor and a system to achieve a goal.

Acceptance criterion: An observable condition used to determine whether a requirement is accepted.

Business rule: A policy, calculation, or restriction governing organisational behaviour.

Scope: The defined boundary of project work and product capability.

Assumption: A condition treated as true for planning purposes.

Constraint: A restriction on the project, solution, resources, or schedule.

Deliverable: A tangible product, document, or result produced by the project.

MVP: Minimum viable product; the smallest release that provides meaningful value and learning.

Risk: An uncertain event or condition that may affect project objectives.

Risk register: A maintained record of risks, ratings, owners, responses, and status.

Estimate: A reasoned forecast of effort, duration, cost, or resources.

Dependency: A relationship in which one activity or component relies on another.

Traceability: The ability to connect a requirement with its origin, implementation, and verification evidence.

Scope creep: Uncontrolled expansion of agreed project work.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional requirement?
2. State the standard structure of a user story.
3. What is the purpose of acceptance criteria?
4. Distinguish a project risk from an issue.
5. Why must effort and duration be treated as different concepts?

Long Answer Questions

1. Explain how interviews, workshops, observation, document analysis, and prototyping can be combined during requirements elicitation. Discuss the strengths and limitations of each.
2. Describe the structure of a use case and illustrate how alternative flows improve the quality of a software specification.
3. Explain the role of a scope statement, including in-scope work, exclusions, assumptions, constraints, deliverables, and success measures.
4. Discuss how non-functional requirements influence the architecture and testing of a Java or Python application.
5. Explain how a requirements baseline, prioritisation, traceability, and change control work together to reduce project failure.

Analytical / Application Questions

1. A team is developing a student attendance system. Write three user stories, at least six acceptance criteria, and two non-functional requirements. Justify your choices.
2. A risk has probability rating 4 and impact rating 5 on a 1–5 ordinal scale. Calculate its qualitative score, propose a response, and explain why the score is not an exact probability of loss.
3. For a task with optimistic, most-likely, and pessimistic estimates of 3, 6, and 12 working days, calculate the PERT-style estimate and explain two reasons why the project duration may differ from this value.

Multiple Choice Questions with Answers

Question 1

Which statement is a non-functional requirement?

A. The system shall create a loan record.

B. The librarian shall search by item identifier.

C. The system shall display search results within two seconds for 95% of searches.

D. The member shall renew an eligible loan.

Correct Answer: C. The system shall display search results within two seconds for 95% of searches.

Question 2

What is the main purpose of acceptance criteria?

A. To specify the programming language

B. To define observable conditions for accepting a requirement

C. To allocate salaries to developers

D. To replace all system testing

Correct Answer: B. To define observable conditions for accepting a requirement

Question 3

Which item is normally out of scope when explicitly excluded from a project?

A. A required deliverable

B. An agreed acceptance criterion

C. A capability deliberately deferred from the release

D. A stakeholder interview

Correct Answer: C. A capability deliberately deferred from the release

Question 4

A risk has probability rating 3 and impact rating 4. Using R = P × I, what is its qualitative score?

A. 7

B. 9

C. 12

D. 34

Correct Answer: C. 12

Question 5

Which response strategy changes the plan so that a threat cannot occur?

A. Avoid

B. Accept

C. Transfer

D. Monitor

Correct Answer: A. Avoid

Question 6

In the user-story format, the phrase “so that” normally introduces the:

A. Technical implementation

B. Business or user benefit

C. Risk rating

D. Precondition

Correct Answer: B. Business or user benefit

Question 7

Using E = (a + 4m + b) ÷ 6, what is the estimate when a = 2, m = 4, and b = 8 days?

A. 3 days

B. 4 days

C. 4.33 days

D. 8 days

Correct Answer: C. 4.33 days

Question 8

Which statement best distinguishes effort from duration?

A. Effort is calendar time and duration is labour input.

B. Effort and duration are always identical.

C. Effort is labour required, while duration is elapsed calendar time.

D. Duration can never be affected by dependencies.

Correct Answer: C. Effort is labour required, while duration is elapsed calendar time.

Question 9

What is the primary purpose of a risk register?

A. To store application passwords

B. To record, assess, assign, and monitor project risks

C. To replace the project schedule

D. To list only completed tasks

Correct Answer: B. To record, assess, assign, and monitor project risks

Question 10

Which quality means that evidence can determine whether a requirement has been met?

A. Verifiable

B. Negotiable

C. Decorative

D. Informal

Correct Answer: A. Verifiable