Requirements Engineering and Domain Modeling

Introduction

Requirements engineering is the disciplined process of discovering, analyzing, documenting, validating, prioritizing, and managing what a software system must do and the conditions under which it must operate. In full stack development, requirements engineering connects stakeholder needs with user interfaces, application services, databases, APIs, security controls, deployment environments, and testing activities.

A technically elegant application can still fail if it solves the wrong problem, excludes important users, performs poorly under realistic loads, or violates legal and organizational constraints. Requirements engineering reduces this risk by making expectations explicit and testable. Domain modeling complements this work by representing the important concepts, relationships, rules, and events in the problem domain.

This chapter presents an integrated approach to requirements engineering for full stack projects. It explains personas, user stories, use cases, acceptance criteria, functional and non-functional requirements, prioritization, validation, assumptions, constraints, scope management, domain models, traceability, and the responsible use of AI-supported analysis.

Learning Objectives

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

• distinguish functional requirements, non-functional requirements, assumptions, constraints, and scope;
• identify stakeholders and construct useful personas;
• write high-quality user stories, use cases, and acceptance criteria;
• elicit requirements through interviews, observation, workshops, surveys, and prototype evaluation;
• prioritize requirements transparently;
• construct a domain model containing entities, value objects, relationships, attributes, and business rules;
• validate requirements for correctness, completeness, consistency, feasibility, and testability;
• maintain traceability from stakeholder goals to implementation and tests;
• manage changes without uncontrolled scope expansion; and
• evaluate ethical, accessibility, privacy, security, and governance implications.

1. The Nature of Requirements

A requirement is a documented need, capability, condition, or constraint that a system must satisfy. Requirements exist at several levels:

1. Business requirements express organizational goals, such as reducing appointment scheduling time.
2. User or stakeholder requirements describe what a particular stakeholder needs to accomplish.
3. System requirements provide sufficiently precise statements for design, development, and testing.
4. Technical constraints restrict implementation choices, such as an institutional requirement to use a particular identity provider.

A requirement is not merely a feature idea. “Add a dashboard” is a vague solution proposal. A stronger requirement identifies the user, purpose, behavior, and success condition: “A clinic coordinator shall view all appointments for a selected day, grouped by clinician, so that overbooking can be detected before confirmation.”

Functional and non-functional requirements

Functional requirements specify services, behaviors, calculations, state changes, and interactions. Examples include:

• The system shall allow a registered customer to reset a forgotten password.
• The system shall prevent two users from booking the same seat.
• The system shall calculate an order total from item prices, quantities, discounts, taxes, and delivery charges.

Non-functional requirements (NFRs) specify qualities or constraints on the system or development process. Common categories include performance, security, usability, accessibility, reliability, maintainability, portability, legal compliance, and observability.

An NFR should be measurable where possible. “The system shall be fast” is not testable. “For 95% of authenticated product-search requests, the server shall return a response within 800 milliseconds under the defined normal load” is more useful. Such a statement must also define the measurement location, workload, data volume, and monitoring method.

NFRs should not be treated as optional decoration. A system that offers correct functions but exposes personal data, fails for keyboard users, or becomes unusable during normal demand is not a successful system.

Assumptions, constraints, dependencies, and risks

An assumption is believed to be true for planning purposes but has not been fully verified. For example, a project may assume that an external payment provider offers a sandbox environment.

A constraint is a limitation imposed by law, policy, technology, budget, schedule, infrastructure, or organizational practice. For example, a university may require all student records to remain within an approved hosting region.

A dependency is an external condition or component on which a requirement depends, such as an identity service, payment gateway, or data migration.

A risk is an uncertain event that may negatively affect objectives. Assumptions should be tracked because an invalid assumption can become a risk or require a requirement change.

A useful requirements register records the statement, source, rationale, owner, status, priority, dependencies, validation method, and revision history.

2. Requirements Elicitation

Elicitation is the process of discovering requirements from people, documents, existing systems, data, and the operating environment. No single technique is sufficient because stakeholders know different parts of the problem and may express needs indirectly.

Stakeholder identification

Stakeholders include direct users, customers, administrators, support personnel, managers, regulators, security specialists, developers, operations staff, and people affected by system decisions even if they never use the interface. A stakeholder map can classify participants by influence and impact. High-influence stakeholders require active engagement, while vulnerable or underrepresented users require deliberate inclusion even when they have little organizational power.

Questions for stakeholder analysis include:

• Who initiates, performs, approves, monitors, or receives the outcome of a process?
• Who owns the business policy?
• Who maintains the data?
• Who is harmed if the system fails or produces an incorrect result?
• Which legal, accessibility, security, or operational authorities must review the system?

Elicitation techniques

Interviews provide depth and allow follow-up questions. Open questions such as “Describe how you handle a cancellation today” reveal actual work better than leading questions such as “Would a cancellation button be useful?”

Observation and contextual inquiry reveal workarounds, interruptions, physical conditions, and informal practices that stakeholders may omit in interviews.

Workshops bring multiple roles together to resolve terminology and process differences. They are effective for mapping workflows and negotiating priorities, but require facilitation to prevent dominant participants from controlling the outcome.

Document and system analysis examines forms, policies, spreadsheets, database schemas, support tickets, logs, and existing applications. Existing artifacts often contain rules that are not documented elsewhere.

Surveys collect broad input efficiently, especially when users are geographically distributed. They are less effective for discovering complex workflows or ambiguous problems.

Prototyping makes assumptions visible. Low-fidelity sketches are useful early; interactive prototypes can test navigation, content, and workflow before expensive implementation.

Event storming and domain workshops identify important business events, commands, actors, and policies. These techniques are particularly useful for domain modeling.

Elicitation should distinguish what people request from why they request it. A stakeholder may ask for an export-to-spreadsheet feature because the current system does not provide a reliable monthly report. Solving the underlying need may require a reporting view rather than an export function.

3. Personas, User Stories, and Use Cases

Personas

A persona is a research-informed representation of a significant user group. It normally includes goals, responsibilities, capabilities, context, frustrations, and relevant accessibility or technology conditions. Personas are not fictional biographies created for decoration. They should be grounded in evidence and used to make design decisions explicit.

For example, an illustrative persona for a university equipment-booking system might be:

Maya, laboratory coordinator: manages shared equipment for several teaching laboratories; works under time pressure; needs clear availability and approval status; uses a desktop browser; must accommodate bookings made by teaching assistants.

A good persona prevents the team from designing only for the most vocal stakeholder. It also helps distinguish user goals from implementation preferences.

User stories

A user story expresses a goal from a user’s perspective:

As a laboratory coordinator, I want to approve or reject equipment requests, so that equipment use complies with laboratory policy.

A story is a planning and conversation device, not a complete specification. The team should elaborate it with conditions, rules, dependencies, and acceptance criteria. The “so that” clause is important because it communicates value and helps reject features that do not support a meaningful outcome.

Useful story-quality principles include:

• Independent: minimizes unnecessary dependence on other stories;
• Negotiable: describes value without prematurely prescribing implementation;
• Valuable: benefits a user or stakeholder;
• Estimable: provides enough clarity for effort assessment;
• Small: can be completed within an iteration or manageable delivery unit; and
• Testable: has observable conditions of satisfaction.

These principles are commonly summarized by the acronym INVEST. They are guidelines rather than rigid laws; technical dependencies sometimes make complete independence impossible.

Use cases

A use case describes a goal-oriented interaction between an actor and a system. A use-case specification commonly includes:

• name and goal;
• primary actor and supporting actors;
• trigger;
• preconditions;
• main success scenario;
• alternative and exception flows;
• postconditions; and
• business rules or special requirements.

For “Approve equipment request,” the main flow may be:

1. The coordinator selects a pending request.
2. The system displays requester, equipment, date, purpose, and policy status.
3. The coordinator chooses Approve.
4. The system verifies that the equipment remains available and the request satisfies policy.
5. The system records approval and notifies the requester.

An alternative flow occurs if availability changed: the system refuses approval, explains the conflict, and offers the coordinator an opportunity to propose another time. Explicit alternative flows expose requirements that a happy-path user story can conceal.

4. Acceptance Criteria and Requirement Quality

Acceptance criteria define the observable conditions under which a requirement is accepted. They should describe behavior and outcomes rather than internal code structure.

A common form is Given–When–Then:

• Given a pending request for equipment that is available,
• When the coordinator approves the request,
• Then the request status becomes Approved, an audit entry is recorded, and the requester receives a notification.

Additional criteria should cover invalid input, authorization, concurrency, failure, accessibility, and boundary conditions. For example:

• Given a requester is not authorized to approve bookings, when approval is attempted, then the system denies the action and records the security event.
• Given another approved booking overlaps the requested time, when approval is attempted, then the system leaves the request pending and identifies the conflict.

High-quality requirements are typically:

• correct with respect to stakeholder and domain needs;
• complete enough for the intended release;
• consistent with other requirements and policies;
• unambiguous to relevant readers;
• feasible within known technology, time, and budget;
• verifiable through inspection, test, demonstration, or analysis;
• traceable to a source and downstream work item; and
• prioritized and versioned.

A practical validation review asks: Can two competent developers interpret this differently? Can a tester determine pass or fail? What happens when the normal path fails? Which actor is authorized? What data is retained, and for how long?

5. Prioritization and Scope

Prioritization is a value judgment made under constraints. It should be transparent rather than based solely on the loudest stakeholder.

A simple classification is:

This MoSCoW approach is useful for communication, but the categories require justification. A legal accessibility requirement is not a “could have,” even if it is difficult to implement.

A more analytical approach uses weighted scoring. Suppose a team evaluates a requirement using benefit, urgency, risk reduction, and effort. A normalized score might be defined as:

Here, B, U, R, and E are stakeholder-assigned ratings on a defined scale; w_b, w_u, w_r, and w_e are non-negative weights; and P is the resulting prioritization score. The ratings must use the same declared scale, and the weights should be agreed before scoring. This formula supports discussion; it does not produce an objective truth.

For example, with ratings from 1 to 5 and weights 0.4, 0.25, 0.25, and 0.10, a requirement rated benefit 5, urgency 4, risk reduction 3, and effort 2 receives:

The score is dimensionless because the inputs are agreed ordinal ratings, not physical measurements. It should not be presented with false precision.

Scope defines what the project will and will not deliver. A scope baseline may include objectives, included capabilities, exclusions, assumptions, constraints, milestones, and acceptance boundaries. Scope control is not resistance to change; it is the practice of evaluating change deliberately.

A change request should record the proposed change, rationale, affected requirements, value, effort, risks, dependencies, schedule impact, and decision authority. Approved changes update the baseline and traceability links. Unapproved additions remain outside the committed scope.

6. Domain Modeling

A domain model is a conceptual representation of the important things, relationships, events, and rules in a problem domain. It is not necessarily a database schema, class diagram, or user-interface design. A domain model helps the team establish a shared vocabulary and identify missing requirements.

Core elements

• Entity: an object with a distinct identity that persists through changes, such as Booking or Student.
• Value object: an object defined by its attributes rather than independent identity, such as DateRange, Money, or EmailAddress.
• Attribute: descriptive data associated with an entity or value object.
• Association: a meaningful relationship between concepts.
• Multiplicity: how many instances may participate in a relationship, such as one-to-many.
• Aggregate: a consistency boundary containing a root entity and related objects managed together.
• Domain event: a significant occurrence, such as BookingApproved or PaymentFailed.
• Business rule: a condition that must hold, such as “a resource cannot have overlapping approved bookings.”

Consider an equipment-booking domain. Candidate concepts include User, Role, Equipment, BookingRequest, Approval, TimeRange, Notification, and AuditEntry. A BookingRequest may be submitted by one User, concern one Equipment item, contain one TimeRange, and have a status such as Pending, Approved, Rejected, or Cancelled. An Approval may record the approving User and time. An AuditEntry provides an accountable record of significant changes.

The model should distinguish a resource from a booking. The equipment exists independently; a booking records a claim on that equipment during a time interval. Treating both as one concept would make availability and history difficult to represent.

Business rules in a domain model

Rules should be expressed explicitly, for example:

• only authorized coordinators may approve requests;
• an approved booking must refer to an existing equipment item;
• approved bookings for the same equipment must not overlap;
• cancellation after the start time requires coordinator authorization; and
• audit entries cannot be edited by ordinary users.

Some rules are invariant: they must always hold. Others are policy rules that may change by institution, department, or release. Distinguishing these types helps identify configuration needs and governance responsibilities.

From domain model to implementation

The model informs database tables, API resources, service boundaries, validation logic, authorization policies, and test fixtures. It does not dictate a one-to-one mapping. A value object may be stored in multiple columns; an aggregate may span several tables; a domain event may be represented in an event log or message queue.

A relational design might contain Users, Equipment, BookingRequests, AuditEntries, and Notifications. The API might expose endpoints for submitting requests, reviewing pending requests, approving requests, and retrieving availability. The service layer should enforce rules that cannot safely be delegated only to the client. Database constraints and transactions should protect important invariants under concurrent requests.

For example, checking availability in the browser is insufficient because two users can submit requests simultaneously. The server must recheck the rule within an appropriate transaction or concurrency-control strategy. The requirement “no overlapping approved bookings” therefore has consequences for the domain model, service logic, database design, and integration tests.

7. Traceability and Change Management

Traceability links each requirement to its source and to downstream artifacts. A basic chain is:

Business goal → stakeholder need → persona/user story or use case → acceptance criteria → design/API/data element → implementation task → test evidence → release.

A traceability matrix may contain:

Traceability supports impact analysis. If the approval policy changes, the team can identify affected user stories, domain rules, API behavior, database fields, tests, documentation, and training. It also provides evidence for regulated or audited systems.

Traceability must be maintained economically. Excessive documentation that nobody updates creates an illusion of control. Lightweight links in an issue tracker, repository, test-management system, or requirements tool are often sufficient for a student or small professional project.

8. Validation, Verification, and Prioritization in Practice

Validation asks whether the team is building the right system. Verification asks whether the documented or implemented system satisfies its specified properties. Both are necessary.

Validation activities include stakeholder walkthroughs, prototype testing, scenario reviews, domain expert review, accessibility evaluation, and operational simulation. Verification activities include requirement inspections, static analysis, unit and integration tests, performance tests, security tests, and acceptance tests.

A requirements review should examine:

• actor and authorization clarity;
• normal, alternative, and failure flows;
• data definitions and ownership;
• privacy and retention obligations;
• accessibility and internationalization;
• performance and availability targets;
• external dependencies;
• monitoring and support needs; and
• testability and acceptance evidence.

Requirements are provisional models of a problem, not immutable facts. Iterative development should use feedback to refine them while preserving decision history and scope discipline.

9. Applied Case: Campus Equipment Booking

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

Background

A university currently manages laboratory equipment bookings through email and shared spreadsheets. Students cannot reliably see availability, coordinators spend time resolving conflicts, and there is no consistent audit trail.

Problem analysis

Interviews identify three principal user groups: students and teaching assistants who request equipment, laboratory coordinators who approve requests, and administrators who review utilization. Observation shows that coordinators manually compare date ranges and frequently receive incomplete requests. The project team also identifies privacy concerns because requests may contain course and student information.

The initial goal is to reduce avoidable scheduling conflicts and provide accountable approval workflows. The first release excludes predictive utilization analytics, mobile-native applications, and integration with every campus system.

Requirements

A representative functional set is:

• users authenticate through the university identity service;
• authorized users search equipment by date range and status;
• requesters submit a booking request containing equipment, time range, purpose, and course;
• coordinators approve or reject pending requests;
• the system prevents overlapping approved bookings;
• users receive status notifications; and
• administrators view booking history and audit records.

Representative NFRs are:

• keyboard-accessible core workflows;
• audit records retained according to university policy;
• unauthorized users cannot view restricted request details;
• search results meet the agreed response target under normal load; and
• service failures produce actionable logs without exposing sensitive data.

Domain analysis

The domain model includes User, Role, Equipment, BookingRequest, TimeRange, Notification, and AuditEntry. The BookingRequest aggregate has a lifecycle: Draft → Submitted → Pending → Approved or Rejected; an approved request may later become Cancelled according to policy. The model identifies a crucial rule: availability must be evaluated against approved bookings, not merely against requests that happen to be visible in the user interface.

Approach and solution

The team creates personas and a workflow prototype before implementation. Acceptance tests are written for successful submission, incomplete data, unauthorized approval, overlapping bookings, cancellation, and notification failure. The server revalidates authorization and availability. A database constraint or transaction strategy is selected to protect against concurrent approval attempts. Audit events record who performed significant actions and when.

A change request proposes allowing external visitors to book equipment. Impact analysis reveals new identity verification, liability, privacy, approval, and support requirements. The change is deferred from the first release rather than silently added.

Outcome

The resulting backlog is smaller but more coherent. Each committed story has acceptance criteria and links to tests. The domain model exposes terminology shared by coordinators and developers. The project has not eliminated uncertainty, but it has made uncertainty visible and manageable.

Learning points

1. The real problem was not simply the absence of a calendar; it was unreliable coordination and accountability.
2. Non-functional requirements changed architectural and testing decisions.
3. Domain rules such as non-overlapping bookings must be enforced on the server, especially under concurrency.
4. Explicit exclusions protect the first release from uncontrolled expansion.
5. Traceability allows policy changes to be assessed rather than guessed.

10. Ethical, Legal, and Governance Considerations

Requirements determine whose interests are represented and whose risks are accepted. Teams should consider fairness, accessibility, privacy, security, explainability, and accountability from the beginning.

Data minimization means collecting only information needed for a legitimate purpose. Requirements should identify lawful purpose, access roles, retention period, deletion or correction procedures, and disclosure boundaries where applicable. Sensitive data should not be copied into logs merely for debugging convenience.

Accessibility should be an acceptance concern, not a final cosmetic review. Requirements may include keyboard operation, visible focus, sufficient contrast, meaningful labels, screen-reader compatibility, captions, and understandable error messages. The precise standards depend on jurisdiction and institutional policy, but the principle is universal: users with disabilities must be included during discovery and evaluation.

Security requirements should address authentication, authorization, input validation, secrets management, secure transmission, auditability, abuse prevention, and recovery. A persona should never be used to justify collecting unnecessary personal data. Automated decisions require particular care where an incorrect outcome can affect education, employment, finance, health, or access to services.

AI tools can assist with clustering interview notes, suggesting duplicate requirements, generating preliminary acceptance-test ideas, or identifying ambiguous language. They should not be treated as authoritative analysts. AI-generated requirements may omit minority users, reproduce stereotypes, invent policies, or expose confidential information. Human stakeholders must verify interpretations, and sensitive material should only be processed in approved environments.

11. Contemporary Professional Practice and Best Practices

Modern teams increasingly combine product discovery, agile delivery, domain-driven design, continuous testing, observability, and automated deployment. These practices do not remove the need for requirements; they shorten feedback cycles and make requirements more executable.

Effective practice includes:

• maintain a shared glossary to prevent ambiguous terms;
• involve developers, testers, operations, security, accessibility specialists, and domain experts early;
• write acceptance criteria before implementation is considered complete;
• model business rules independently of interface screens;
• define measurable NFRs with workload and measurement conditions;
• review assumptions and dependencies at each iteration;
• use prototypes to test risky interaction assumptions;
• preserve a clear distinction between current scope and future ideas;
• enforce critical invariants on trusted server-side components;
• link requirements to test evidence and production monitoring; and
• record decisions, rejected alternatives, and reasons for change.

The most valuable requirements artifact is not the longest document. It is the smallest coherent set of shared, testable, traceable agreements that enables a team to build, evaluate, operate, and change the system responsibly.

Chapter Summary

Requirements engineering translates stakeholder needs into explicit, testable, and manageable agreements. Functional requirements describe system behavior, while non-functional requirements define qualities and constraints such as performance, security, accessibility, and reliability. Assumptions, constraints, dependencies, risks, and scope boundaries must be recorded because they influence feasibility and change decisions.

Personas represent evidence-based user groups. User stories communicate goals and value, use cases describe interactions and alternative flows, and acceptance criteria establish observable conditions of satisfaction. Elicitation combines interviews, observation, workshops, document analysis, surveys, prototypes, and domain-focused techniques.

Prioritization should be transparent and connected to value, urgency, risk, effort, compliance, and release objectives. Domain models provide a shared vocabulary of entities, value objects, relationships, events, aggregates, and business rules. They inform implementation without being identical to a database schema.

Validation asks whether the right system is being built; verification asks whether specified properties are satisfied. Traceability connects goals to requirements, design, implementation, tests, and release evidence. Change control protects scope while allowing justified evolution. Ethical and governance concerns—including privacy, accessibility, security, fairness, and responsible AI use—must be treated as requirements rather than afterthoughts.

Key Terms

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

Functional requirement: A statement of behavior or service the system must provide.

Non-functional requirement: A quality attribute or constraint on the system or process.

Stakeholder: A person, group, or organization that affects or is affected by the system.

Persona: An evidence-informed representation of a significant user group.

User story: A concise statement of a user goal and its value.

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

Acceptance criteria: Observable conditions used to determine whether a requirement is satisfied.

Assumption: An unverified belief used for planning or analysis.

Constraint: A limitation imposed by policy, law, technology, resources, or environment.

Scope: The agreed boundary of what a project or release includes and excludes.

Traceability: The ability to follow a requirement from source through implementation and verification.

Domain model: A conceptual representation of domain concepts, relationships, events, and rules.

Entity: A domain object distinguished by persistent identity.

Value object: A domain object defined by its attributes rather than independent identity.

Aggregate: A consistency boundary containing a root entity and related objects.

Business rule: A policy or invariant governing domain behavior.

Domain event: A significant occurrence in the domain.

Validation: Determining whether the system addresses the right needs.

Verification: Determining whether the system satisfies specified requirements.

Review Questions

Short Answer Questions

1. Distinguish a functional requirement from a non-functional requirement and give one example of each.
2. What is the purpose of a persona in requirements engineering?
3. List four elements commonly included in a use-case specification.
4. Why should assumptions be recorded and reviewed?
5. Explain the difference between an entity and a value object.

Long Answer Questions

1. Explain how interviews, observation, workshops, document analysis, surveys, and prototyping complement one another during elicitation.
2. Discuss the role of acceptance criteria in connecting user stories to software testing.
3. Explain how a domain model can influence database design, API design, authorization, and concurrency control without being identical to any of them.
4. Describe a disciplined process for evaluating and approving a scope-change request.
5. Compare validation and verification, and explain why both are necessary in a full stack project.

Analytical / Application Questions

1. A booking application allows two users to reserve the same resource when they submit requests at nearly the same time. Identify the relevant requirement, domain rule, and implementation-level concerns that should be investigated.
2. A stakeholder requests “a fast and user-friendly dashboard.” Rewrite this as at least one measurable non-functional requirement and identify the assumptions that must be clarified.
3. Using the campus equipment-booking case, propose a traceability chain from a business goal to a user story, acceptance criterion, implementation artifact, and test evidence.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The user submits a booking request.

B. The coordinator approves an eligible request.

C. The system returns 95% of searches within 800 milliseconds under defined normal load.

D. The system sends a notification after approval.

Correct Answer: C. The system returns 95% of searches within 800 milliseconds under defined normal load.

Question 2

What is the primary purpose of a persona?

A. To define database tables

B. To represent a significant user group using evidence-informed characteristics and goals

C. To replace all stakeholder interviews

D. To specify server hardware

Correct Answer: B. To represent a significant user group using evidence-informed characteristics and goals

Question 3

Which item is an acceptance criterion?

A. Build a modern booking page

B. Use a relational database

C. Given an available resource, when approval occurs, then the request status becomes Approved and an audit entry is recorded

D. Improve the user experience

Correct Answer: C. Given an available resource, when approval occurs, then the request status becomes Approved and an audit entry is recorded

Question 4

In the INVEST guidelines for user stories, the letter T refers to which quality?

A. Traceable

B. Technical

C. Testable

D. Timeboxed

Correct Answer: C. Testable

Question 5

Which concept is normally defined by its attributes rather than an independent identity?

A. Entity

B. Value object

C. Aggregate root

D. Actor

Correct Answer: B. Value object

Question 6

Why must availability be rechecked on the server during booking approval?

A. Browser interfaces cannot display dates

B. Two requests may be processed concurrently and create a conflict

C. Users cannot submit forms from browsers

D. Notifications require server-side rendering

Correct Answer: B. Two requests may be processed concurrently and create a conflict

Question 7

What does traceability primarily enable?

A. Automatic removal of all project risks

B. Impact analysis from requirements to implementation and tests

C. Elimination of stakeholder involvement

D. Replacement of acceptance testing with documentation

Correct Answer: B. Impact analysis from requirements to implementation and tests

Question 8

Using the chapter’s illustrative prioritization formula, what is P when B=5, U=4, R=3, E=2, and weights are 0.4, 0.25, 0.25, and 0.10 respectively?

A. 2.55

B. 3.05

C. 3.55

D. 4.15

Correct Answer: C. 3.55

Question 9

Which activity is most directly associated with validation?

A. Checking whether a compiler accepts the code

B. Running a stakeholder walkthrough of a prototype

C. Checking code formatting

D. Measuring database storage size only

Correct Answer: B. Running a stakeholder walkthrough of a prototype

Question 10

Which statement about AI-assisted requirements analysis is most appropriate?

A. AI output can be accepted without stakeholder review

B. AI should determine legal and privacy requirements independently

C. AI can assist with clustering and ambiguity detection, but humans must verify interpretations

D. Confidential interview data should always be uploaded to public AI tools

Correct Answer: C. AI can assist with clustering and ambiguity detection, but humans must verify interpretations