Requirements Engineering and Fact-Finding

Introduction

Requirements engineering is the disciplined process of discovering, analyzing, documenting, validating, prioritizing, and managing what stakeholders need from an information system. In system analysis and design, requirements form the connection between a business problem and a technical solution. A system can be implemented with excellent code and still fail if it solves the wrong problem, omits an important user need, or imposes unacceptable operational constraints.

Fact-finding is the evidence-gathering part of requirements engineering. Analysts investigate existing work practices, information flows, documents, rules, technologies, and stakeholder expectations. The aim is not merely to collect statements such as “the system should be fast.” The analyst must determine who needs what, under which conditions, for what business purpose, and how the requirement can be verified.

Requirements engineering is therefore both technical and social. It involves modeling processes and data, but also negotiation, communication, organizational analysis, ethics, and change management. This chapter presents a practical and academically grounded approach suitable for software and information-system projects.

Learning Objectives

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

1. Explain the purpose, characteristics, and classifications of requirements.
2. Plan and conduct interviews, observation, questionnaires, workshops, and document analysis.
3. Elicit requirements from diverse stakeholder groups and identify conflicts or omissions.
4. Analyze and model functional and non-functional requirements.
5. Write effective requirements and user stories with testable acceptance criteria.
6. Prioritize requirements using transparent criteria.
7. Validate requirements for correctness, completeness, consistency, feasibility, and testability.
8. Establish traceability and control requirements changes.
9. Evaluate ethical, accessibility, security, privacy, and governance implications.

1. The Nature of Requirements

A requirement is a documented capability, condition, constraint, or quality that a system must satisfy. It may describe a service the system provides, a limitation on operation, a business rule, or a quality attribute such as security or availability.

A requirement may be expressed at several levels:

• Business requirement: the organizational goal or benefit, such as reducing average patient-registration time.
• User or stakeholder requirement: what a particular user or external party needs to accomplish.
• System requirement: a precise statement of behavior, data, interfaces, constraints, or quality that the system must provide.
• Design or implementation constraint: a restriction on the solution, such as compliance with an approved database platform.

These levels should be related but not confused. “Reduce registration delays” is a business objective. “A receptionist shall locate a patient record using name and date of birth” is a user requirement. “The search service shall return results within two seconds for 95% of requests under the defined normal load” is a system requirement.

Functional and non-functional requirements

A functional requirement describes a service, behavior, transformation, or response. Examples include creating an account, calculating an invoice, generating a report, or rejecting an invalid transaction.

A non-functional requirement specifies a quality, constraint, or condition under which services must operate. Common categories include:

Non-functional requirements are not secondary. A function that cannot be secured, used, trusted, or operated economically may have little value.

Characteristics of a good requirement

A high-quality requirement is:

• Correct: it represents a genuine stakeholder or business need.
• Unambiguous: it has one reasonable interpretation.
• Complete: necessary conditions, responses, and exceptions are included.
• Consistent: it does not conflict with another approved requirement.
• Feasible: it can be delivered within known technology, cost, time, and legal constraints.
• Verifiable: inspection, demonstration, analysis, or testing can determine whether it is satisfied.
• Traceable: its source and relationships to design, implementation, and tests are known.
• Prioritized: its relative importance and urgency are explicit.
• Modifiable: it is structured so that changes can be made without unnecessary disruption.

Terms such as “user-friendly,” “sufficiently secure,” and “quickly” are weak unless operationally defined. A useful improvement is to identify a measurable or observable condition: “A first-time clerk, after one hour of training, shall complete a standard order without assistance in at least four out of five trials.”

2. Requirements Engineering as a Lifecycle

Requirements work is iterative rather than strictly linear. A typical lifecycle contains the following activities:

1. Inception and scope definition: establish the problem, objectives, stakeholders, boundaries, assumptions, and constraints.
2. Elicitation: gather information through interaction with stakeholders and examination of existing evidence.
3. Analysis and modeling: organize, classify, prioritize, negotiate, and represent requirements.
4. Specification: record requirements in a baseline document, product backlog, use-case model, or related repository.
5. Validation: check quality and stakeholder agreement.
6. Management: control versions, changes, dependencies, risks, and traceability throughout the project.

Activities often overlap. Validation may reveal that further elicitation is needed; a change request may expose an undocumented business rule. Agile teams may maintain requirements as a product backlog, whereas a regulated project may use a formally approved requirements specification. The underlying responsibilities remain similar.

A useful distinction is between the problem domain and the solution domain. Analysts first seek to understand the organizational problem and desired outcomes. They should avoid prematurely deciding that a requested feature is the best solution. For example, a stakeholder may request a mobile application when the underlying need is simply immediate access to delivery status. A web interface, messaging service, or process change might satisfy that need more effectively.

3. Stakeholder Identification and Analysis

Stakeholders are people, groups, or organizations that affect, are affected by, fund, operate, regulate, or depend on the system. They include direct users, managers, customers, suppliers, administrators, auditors, support staff, and people whose data is processed even if they never use the interface.

A stakeholder register can record:

Analysts should not rely only on senior managers. A manager may describe the official process, while a front-line employee knows the workarounds required to complete it. Customers, people with disabilities, temporary staff, and support personnel may reveal requirements that are invisible to project sponsors.

Stakeholder analysis also exposes conflicts. A security officer may require stronger authentication, while users want faster access. A finance department may want detailed audit records, while a privacy officer may require data minimization. Such conflicts should be made explicit and resolved through agreed business priorities, risk evaluation, legal obligations, and documented decisions.

4. Fact-Finding Techniques

No single technique reveals the whole system. Effective analysts combine methods and compare findings, a practice known as triangulation.

Interviews

Interviews are structured conversations used to discover goals, activities, rules, exceptions, problems, and expectations. They may be:

• Structured: predetermined questions and consistent order.
• Semi-structured: a prepared guide with freedom to probe.
• Unstructured: exploratory discussion used early when little is known.

A strong interview process has four stages:

1. Define the purpose and select participants.
2. Prepare neutral, open questions and relevant documents.
3. Conduct the interview, listen actively, probe examples, and distinguish facts from opinions.
4. Validate notes with the participant and record actions or unresolved issues.

Useful questions include: “Walk me through the last time you performed this task,” “What happens when the normal process fails?” and “What information do you need before you can make that decision?” Asking about a recent real case is often more reliable than asking what “usually” happens.

Leading questions should be avoided. “The current form is confusing, isn’t it?” encourages agreement; “Which parts of the current form cause difficulty?” is more neutral. Interviews can be affected by memory errors, organizational politics, status differences, and the tendency to describe prescribed rather than actual work.

Observation and contextual inquiry

Observation involves examining work as it occurs. It can reveal informal practices, interruptions, duplicated entry, undocumented decisions, and environmental constraints. The analyst should record actors, inputs, actions, outputs, tools, timing, exceptions, and dependencies.

Observation may be direct, participant-based, or supported by screen recording where permitted. It must be conducted transparently and ethically. People should know the purpose, the information being collected, and how it will be protected. The analyst should not infer that an observed workaround is a preferred requirement; it may be evidence of a defect in the current process.

Contextual inquiry combines observation with short questions at the point of work. For example, when a clerk copies a reference number into a spreadsheet, the analyst can ask what risk or limitation caused that practice. This produces richer evidence than a later general interview.

Questionnaires and surveys

Questionnaires are useful when stakeholders are numerous, geographically distributed, or require anonymity. Closed questions support comparison, while open questions capture unexpected concerns. Questions should be short, neutral, and focused on one idea. Response scales should be clearly labeled and consistently oriented.

A questionnaire does not automatically produce representative evidence. Non-response can systematically exclude busy users or dissatisfied users. A high percentage of agreement may reflect acquiescence rather than genuine support. Survey results should therefore be interpreted with information about the population, sampling, response rate, and question wording.

Workshops and facilitated sessions

A requirements workshop brings stakeholders together to develop shared understanding. Techniques include brainstorming, process mapping, story mapping, use-case modeling, priority voting, and scenario analysis. Workshops are effective for resolving differences quickly, but they require skilled facilitation.

The facilitator should establish objectives, terminology, decision rights, time limits, and behavioral rules. Dominant participants must not silence less powerful voices. A parking list can capture issues that require later research without allowing them to derail the session. Every decision should have an owner and a recorded rationale.

Document and interface analysis

Existing forms, reports, policies, manuals, contracts, spreadsheets, database schemas, support tickets, logs, and regulatory documents are valuable sources. Documents reveal official rules, data definitions, approval points, and historical constraints. They may also be outdated or inconsistent.

The analyst should ask:

• Who created and maintains the document?
• Is it authoritative or merely a local workaround?
• Which data items, rules, and exceptions does it reveal?
• Does observed practice match the written procedure?
• What legal, contractual, or retention obligations apply?

Studying current screens and interfaces can reveal usability problems and duplicated data entry, but copying an existing interface without understanding its purpose simply reproduces old weaknesses.

Prototypes and scenarios

A prototype is a partial representation of a proposed solution. Sketches, wireframes, clickable mock-ups, and executable experiments help stakeholders react to something concrete. Prototypes are particularly useful for discovering usability and interaction requirements. They can mislead stakeholders if they appear more complete than they are, so their purpose and limitations must be stated.

Scenarios and use cases describe interactions between an actor and a system to achieve a goal. A use case normally includes a goal, preconditions, trigger, main success path, alternative paths, exceptions, and postconditions. Scenarios expose missing responses and boundary conditions that abstract statements often omit.

5. Analysis, Modeling, and Specification

Elicited information is usually incomplete, repetitive, contradictory, and expressed in different vocabularies. Analysis transforms raw observations into an organized requirements model.

Functional decomposition and process analysis

The analyst identifies business events, actors, inputs, transformations, outputs, and data stores. Context diagrams, data-flow diagrams, activity diagrams, use-case diagrams, and process models can communicate these relationships. Models should have a stated purpose and scope. A diagram is not automatically correct because it is visually attractive; each process, data item, and relationship should be supported by evidence.

A useful analysis sequence is:

1. Identify the business event or user goal.
2. Define the actor and the system boundary.
3. Describe the normal flow.
4. Identify alternative and exceptional flows.
5. Identify required data and business rules.
6. Define observable outcomes and acceptance conditions.

User stories

In agile development, a user story commonly follows this form:

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

For example: “As a warehouse clerk, I want to scan an item during dispatch, so that the stock record is updated without manual re-entry.” The format emphasizes user value, but it is not a complete specification. It should be accompanied by acceptance criteria, assumptions, dependencies, and relevant non-functional requirements.

Good acceptance criteria describe observable behavior. For the story above, criteria might state that a valid scan reduces available stock by the approved quantity, an unknown item produces a clear error, and a successful update is recorded with user and time information. A common format is Given–When–Then:

• Given a valid item and an open dispatch order,
• When the clerk scans the item,
• Then the system records the quantity against that order and displays the updated balance.

The INVEST heuristic—independent, negotiable, valuable, estimable, small, and testable—can help assess stories, although it is a guide rather than a rigid law.

Rules and data requirements

Business rules express policies, calculations, permissions, or conditions. They should be separated from interface wording where possible. “A customer with overdue debt cannot place a new credit order” is a business rule; the exact warning screen is a design choice.

Data requirements identify entities, attributes, ownership, quality, retention, sensitivity, and relationships. Analysts should define terms in a shared glossary. For example, “active customer” might mean a customer with a transaction in the last twelve months, not merely a customer whose record has not been deleted. Ambiguous definitions produce inconsistent reports and faulty decisions.

6. Prioritizing and Negotiating Requirements

Resources are limited, so requirements must be prioritized transparently. A practical classification is:

• Must have: absence makes the release unacceptable or violates an obligation.
• Should have: important, but a temporary alternative exists.
• Could have: beneficial if resources permit.
• Won’t have now: explicitly deferred from the current scope.

This is commonly called the MoSCoW approach. “Won’t have now” does not mean “never”; it prevents hidden expectations from being treated as current commitments.

A more quantitative approach assigns weighted value. Suppose a team rates a requirement on value, risk reduction, and urgency, each from 1 to 5, and uses weights 0.5, 0.3, and 0.2 respectively. The priority score is:

Here, P is the score, and V, R, and U are the ratings for value, risk reduction, and urgency. The weights sum to 1 and represent the decision-makers’ agreed relative importance. This score supports discussion; it does not replace legal obligations, architectural dependencies, or professional judgment.

If a requirement receives ratings V=4, R=5, and U=3, then P=0.5(4)+0.3(5)+0.2(3)=4.1. Scores are meaningful only when the scale, criteria, and assessors are documented and applied consistently.

Prioritization should consider value, cost, risk, dependencies, compliance, frequency of use, and consequences of failure. Stakeholders should understand why a requirement was deferred. Negotiation is not simply voting; it is the structured resolution of competing interests.

7. Validation and Quality Assurance

Validation asks whether the documented requirements describe the right system and whether they are sufficiently precise to guide development and acceptance. A requirements review should examine:

• Validity: does the requirement support a genuine need?
• Completeness: are normal, alternative, exception, data, and quality conditions covered?
• Consistency: do requirements conflict in terminology, behavior, or priority?
• Feasibility: can the organization deliver and operate the requirement?
• Verifiability: can an objective test, inspection, demonstration, or analysis assess it?
• Traceability: is its source and downstream implementation known?

Inspection techniques include peer reviews, scenario walkthroughs, prototypes, test-case derivation, and automated checks for duplicate identifiers or missing fields. Deriving acceptance tests early is especially powerful: if a requirement cannot produce a plausible test, it may be ambiguous.

Validation is different from verification. Verification asks whether the specification has been written correctly according to agreed standards; validation asks whether it represents the actual need. Both are necessary.

8. Traceability and Requirements Management

Traceability is the ability to follow a requirement from its origin through analysis, design, implementation, testing, release, and change history. A requirements traceability matrix may contain:

A traceability system supports impact analysis, coverage assessment, auditability, and controlled change. Forward traceability links requirements to design and tests; backward traceability links system features back to business or stakeholder sources.

Requirements management includes version control, baselines, change requests, impact analysis, approval, communication, and monitoring. A change request should explain the proposed change, reason, affected requirements, cost or schedule implications, risks, dependencies, and decision authority. Once a baseline is approved, uncontrolled changes create scope creep and undermine accountability.

A change control board may be appropriate for a large or regulated project; an empowered product owner and backlog refinement may be sufficient for an agile team. In either case, decisions should be visible and recorded.

9. Ethical, Legal, and Governance Considerations

Requirements determine how people are represented and how decisions are made. Analysts therefore have ethical responsibilities. They should obtain informed cooperation, protect confidential information, minimize unnecessary collection, and avoid misrepresenting stakeholder views.

Privacy requirements should address purpose limitation, access control, retention, correction, disclosure, and secure disposal. Security should be considered during elicitation rather than added after implementation. Relevant requirements may include authentication, authorization, encryption, logging, backup, incident response, and separation of duties.

Accessibility is a requirements concern, not merely a visual design preference. Stakeholders with visual, auditory, motor, cognitive, or communication differences should be included. Requirements may specify keyboard operation, alternative text, captions, adequate contrast, understandable language, and compatibility with assistive technologies, subject to applicable standards and law.

Algorithmic or AI-supported systems require additional questions: What data is used? Is consent appropriate? Can decisions be explained? Who reviews errors? What happens when the model is uncertain? Are outcomes discriminatory? Requirements should define human oversight, audit records, appeal mechanisms, data governance, and performance monitoring where relevant.

Analysts must also distinguish a stakeholder request from an ethically acceptable requirement. A request to expose another person’s private information is not legitimized by its business convenience.

10. Illustrative Case: University Equipment-Lending System

The following is a fictional illustrative case.

Background

A university lends cameras, laptops, and laboratory equipment to students and staff. The current process uses paper forms, email approvals, and several spreadsheets. Students report long queues, while staff cannot reliably determine which items are overdue.

Problem

The project sponsor initially requests “a mobile lending app.” Early analysis reveals broader problems: inconsistent borrower identification, unavailable stock information, missing return records, unclear responsibility for damaged equipment, and insufficient privacy controls.

Analysis

The analyst identifies students, lecturers, store officers, faculty administrators, security staff, finance officers, and borrowers whose data is stored. Interviews reveal official policy, while observation shows that store officers maintain a personal spreadsheet to track items awaiting inspection. Document analysis identifies a requirement that high-value equipment receive faculty approval.

A workshop maps the process from request to return. Important exceptions include an unavailable item, an expired student identity, a late return, damage on inspection, and a lost item. A questionnaire identifies that most borrowers want availability information before visiting the store, while staff prioritize accurate status and audit history.

The team records requirements such as:

• A borrower shall search available equipment by category, date, and location.
• The system shall prevent a borrower from creating a loan when the borrower’s identity is invalid or an unresolved overdue item exists.
• A high-value loan shall require approval from the responsible faculty role.
• A store officer shall record condition at issue and return.
• The system shall retain an auditable history of status changes.
• Only authorized roles shall view personal and disciplinary information.
• The availability search shall return results within an agreed performance threshold under normal operating load.

The team separates business rules from interface preferences. “Students should use the mobile app” is not treated as a fundamental requirement until evidence shows that mobile access is necessary. A responsive web interface may satisfy the underlying need at lower cost.

Prioritization and solution

Identity validation, stock accuracy, approval rules, return recording, and access control are classified as Must have. Notifications are Should have, while predictive demand analysis is deferred. A prototype of the request and return flows exposes a missing exception: equipment may be returned after the store closes and placed in a secure drop box.

Acceptance tests are derived from each approved requirement. Traceability links each requirement to its source interview or policy, design component, and test. A privacy review confirms that disciplinary details are not displayed to ordinary borrowers.

Outcome

The resulting system is broader than the original “mobile app” request but more closely aligned with the actual problem. The university obtains a controlled lending process, reliable status information, and evidence for resolving disputes. The project also avoids unnecessary collection of sensitive data.

Learning points

1. The requested solution may not express the real business need.
2. Observation reveals workarounds that interviews may omit.
3. Exception paths are essential to operational requirements.
4. Non-functional, privacy, and audit requirements can determine system acceptance.
5. Traceability and acceptance tests make stakeholder agreements actionable.

11. Challenges and Contemporary Practice

Requirements work is difficult because organizations change, stakeholders disagree, and future users may not yet be known. Common failure modes include assuming that one manager represents everyone, documenting solutions instead of needs, ignoring exceptions, treating non-functional requirements as vague aspirations, and allowing requirements to grow without governance.

Distributed and hybrid teams require deliberate communication through collaborative modeling, recorded decisions, shared glossaries, and asynchronous review. Product analytics, support tickets, usage logs, and controlled experiments can supplement traditional elicitation, but data describes observed behavior rather than necessarily explaining motivation.

AI tools can assist with transcription, clustering similar statements, detecting missing fields, generating draft acceptance tests, and identifying possible conflicts. They do not replace stakeholder judgment. Analysts must verify generated content, protect confidential data, inspect for bias, and maintain human accountability. A plausible automated summary can still omit a minority concern or invent a requirement from ambiguous discussion.

Best practice is therefore evidence-based and iterative: involve representative stakeholders, triangulate methods, make assumptions visible, define measurable acceptance conditions, prioritize openly, validate continuously, and manage change throughout the system lifecycle.

Chapter Summary

Requirements engineering converts organizational needs into an agreed, testable, and manageable basis for system development. It includes inception, elicitation, analysis, specification, validation, and ongoing management. Functional requirements describe services and behavior; non-functional requirements describe qualities and constraints. Effective fact-finding combines interviews, observation, questionnaires, workshops, document analysis, prototypes, and scenarios. Stakeholder analysis prevents important or marginalized perspectives from being overlooked.

High-quality requirements are correct, unambiguous, complete, consistent, feasible, verifiable, traceable, prioritized, and modifiable. User stories communicate value but need acceptance criteria and supporting rules. Prioritization should reflect value, risk, urgency, dependencies, compliance, and cost. Validation uses reviews, scenarios, prototypes, and test derivation. Traceability connects sources to requirements, design, implementation, and tests, while change management protects scope and decision accountability. Privacy, security, accessibility, fairness, and governance must be addressed as requirements from the beginning.

Key Terms

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

Requirements engineering: The disciplined process of eliciting, analyzing, specifying, validating, and managing requirements.

Fact-finding: Systematic collection of evidence about work, information, rules, and stakeholder needs.

Functional requirement: A requirement describing a service, behavior, or response.

Non-functional requirement: A quality attribute, constraint, or operating condition.

Stakeholder: A person or group that affects, is affected by, funds, operates, regulates, or depends on a system.

Elicitation: The discovery and exploration of requirements from stakeholders and evidence.

Interview: A planned conversation used to investigate needs, practices, rules, and problems.

Observation: Examination of work as it is performed in its operational context.

Workshop: A facilitated group session for developing shared understanding and decisions.

Prototype: A partial representation used to explore requirements or solution behavior.

User story: A concise statement of a user role, desired capability, and benefit.

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

Business rule: A policy, condition, calculation, or permission governing organizational activity.

Traceability: The ability to follow a requirement through its source, development, testing, and change history.

Baseline: An approved version of requirements used as a controlled reference.

Prioritization: The process of ranking requirements according to agreed criteria.

Validation: Checking that requirements represent the right system and stakeholder needs.

Requirements management: Control of versions, changes, dependencies, priorities, and status.

Triangulation: Comparing evidence from multiple sources or elicitation techniques.

Review Questions

Short Answer Questions

1. Distinguish between a functional requirement and a non-functional requirement, giving one example of each.
2. Why should analysts combine multiple fact-finding techniques?
3. State four characteristics of a high-quality requirement.
4. What is the purpose of acceptance criteria in a user story?
5. Explain forward and backward traceability.

Long Answer Questions

1. Explain the requirements engineering lifecycle and show how its activities interact in an iterative project.
2. Compare interviews, observation, questionnaires, workshops, and document analysis, including the strengths and limitations of each.
3. Describe how stakeholder analysis can reveal conflict, exclusion, and organizational risk.
4. Explain how requirements should be validated for correctness, completeness, consistency, feasibility, and verifiability.
5. Discuss the role of privacy, security, accessibility, and ethical governance in requirements engineering.

Analytical / Application Questions

1. A hospital asks for “a faster appointment system.” Identify likely stakeholders, propose three fact-finding techniques, and rewrite the request as two functional and two measurable non-functional requirements.
2. A project team disagrees about whether automated email notifications are essential. Design a transparent prioritization and negotiation approach, including the evidence and decision criteria you would use.
3. Using the university equipment-lending case, identify three exception scenarios and derive one acceptance criterion and one traceability relationship for each.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a non-functional requirement?

A. The system shall create a new customer record.

B. The system shall calculate the invoice total.

C. The system shall return search results within two seconds for 95% of normal requests.

D. The system shall print a monthly sales report.

Correct Answer: C. The system shall return search results within two seconds for 95% of normal requests.

Question 2

What is the primary purpose of observation during fact-finding?

A. To replace all stakeholder interviews

B. To reveal work practices, exceptions, and environmental constraints as work occurs

C. To determine the project budget automatically

D. To approve the final system design

Correct Answer: B. To reveal work practices, exceptions, and environmental constraints as work occurs

Question 3

Which quality makes a requirement objectively assessable through testing, inspection, demonstration, or analysis?

A. Verifiability

B. Popularity

C. Flexibility

D. Informality

Correct Answer: A. Verifiability

Question 4

Which is the best example of a user story?

A. The database shall use indexed tables.

B. As a warehouse clerk, I want to scan an item so that stock is updated without manual re-entry.

C. The application shall be written in a specified programming language.

D. The system contains a dispatch screen.

Correct Answer: B. As a warehouse clerk, I want to scan an item so that stock is updated without manual re-entry.

Question 5

In the priority formula P = 0.5V + 0.3R + 0.2U, what is P when V = 4, R = 5, and U = 3?

A. 3.2

B. 3.8

C. 4.1

D. 4.8

Correct Answer: C. 4.1

Question 6

Which technique is most directly intended to create shared understanding and resolve differences among several stakeholders at once?

A. Workshop

B. Document archiving

C. Unit testing

D. Data backup

Correct Answer: A. Workshop

Question 7

What does backward traceability connect?

A. A requirement to its business or stakeholder source

B. A server to its network cable

C. A test result to unrelated historical data

D. A user interface to its color palette only

Correct Answer: A. A requirement to its business or stakeholder source

Question 8

Which practice best reduces ambiguity in a requirement?

A. Using broad terms such as 'quickly' and 'user-friendly'

B. Removing all exception conditions

C. Defining observable conditions and measurable thresholds

D. Allowing each developer to interpret it independently

Correct Answer: C. Defining observable conditions and measurable thresholds

Question 9

What is the main risk of relying only on a senior manager for requirements?

A. The project will necessarily become agile

B. Front-line practices and less powerful stakeholder perspectives may be missed

C. The system will contain too many acceptance tests

D. Traceability will become automatic

Correct Answer: B. Front-line practices and less powerful stakeholder perspectives may be missed

Question 10

Which activity is a central part of requirements management after a baseline has been approved?

A. Uncontrolled addition of requested features

B. Change assessment, approval, version control, and communication

C. Deleting the original requirements

D. Replacing stakeholder validation with coding

Correct Answer: B. Change assessment, approval, version control, and communication