Requirements, Feasibility & Documentation

1. What are the characteristics of a good software requirement?

A good requirement is unambiguous — it has exactly one interpretation, so the developer, tester, and customer all understand it the same way. It is testable: you can state clearly how you will verify that it is satisfied. “The system should be fast” is not a good requirement; “the login page must respond within two seconds” is.

It must be complete, leaving no missing details or placeholder conditions, and consistent — it cannot contradict other requirements in the same document. It should be verifiable against the actual product and traceable back to a business need, so its existence is justified. A requirement should also be feasible within the project’s technology, budget, and time.

Finally, a good requirement is single-focused, stating one thing rather than bundling several. This makes it easy to prioritize, test, and change independently. The acronym people use is I-T-C-V — individual, testable, consistent, and verifiable — with complete and traceable as the wrap-around qualities.

2. What are the different requirements elicitation techniques?

Requirements elicitation is the process of gathering requirements from stakeholders, and the techniques fall into a few broad families. Interviews — structured or unstructured one-on-one sessions — extract deep, personal views. Questionnaires and surveys collect structured answers from many stakeholders cheaply. Workshops and JAD (Joint Application Development) sessions bring all stakeholders together to agree on requirements in real time.

Brainstorming generates creative ideas in a group, and document analysis mines existing systems, contracts, and process manuals for implicit requirements. Observation involves watching users work in their real environment to see what they actually do rather than what they say they do. Prototyping lets users react to a working model, surfacing requirements they could not articulate abstractly.

Use cases and user stories capture functional requirements from the user’s perspective. Finally, ethnography embeds the analyst in the user’s environment for deep, long-term understanding. In practice, no single technique is enough — effective elicitation combines several, chosen by the stakeholders’ availability and the requirements’ nature.

3. How do you handle conflicting requirements?

Conflicting requirements are inevitable when multiple stakeholders want different things. The first step is to surface the conflict openly and understand it — often the conflict is not about the feature itself but about priorities, budget, or unstated assumptions. Talk to the stakeholders involved and clarify what each side actually needs.

Next, resolve the conflict at the right level. Some conflicts are resolved by negotiation between stakeholders, others need escalation to a product owner, project sponsor, or change control board. A structured method like the MoSCoW prioritization (Must, Should, Could, Won’t) or a requirements prioritization matrix helps decide which requirement wins based on business value, cost, and risk.

The key discipline is to record the conflict and its resolution in the requirements document, so the decision is traceable. Never silently pick one side. And when a conflict genuinely cannot be resolved, escalate it rather than letting it fester — unresolved conflicts in requirements become the most expensive defects later.

4. How do you handle ambiguous requirements?

Ambiguous requirements are the leading cause of software defects, because every reader interprets them differently. The first step is to identify the ambiguity — look for vague words like “fast,” “user-friendly,” “efficient,” “some,” “etc.,” or passive constructions that hide who does what. Quantify everything: replace “fast” with a response-time target, replace “a few” with a number.

Clarify with the stakeholder directly. Ask concrete questions until every qualifier is defined, and turn the requirement into a testable statement that an independent tester could verify. Write it in a single active voice — “the system shall…” — and remove alternative interpretations.

Use structured formats that force precision: use-case templates, acceptance criteria, and state-machine or decision-table descriptions all eliminate ambiguity structurally. Finally, have someone else review the requirement before it is baselined; a fresh reader catches ambiguity the author missed. The discipline is simple: if two people could disagree on what the requirement means, it is not finished.

5. What is requirements prioritization?

Requirements prioritization is deciding which requirements matter most, so the team builds the highest-value features first and can drop the rest under schedule pressure. Every project has more requests than time; prioritization turns that list into an agreed order of work.

The most common technique is MoSCoW — Must have, Should have, Could have, Won’t have. Must requirements are essential for release; Should are important but survivable without; Could are nice-to-have; Won’t are explicitly out of scope for now. Other approaches include the Kano Model, which separates basic expectations, performance features, and delighters, and weighted scoring, which ranks requirements by business value, cost, risk, and urgency.

Prioritization is not a one-time activity. Priorities shift as the market, budget, and stakeholders change, so the list is revisited throughout the project — in Agile this happens every sprint during backlog refinement. The output is a prioritized, traceable list that guides scope, planning, and release decisions.

6. What is requirements traceability?

Requirements traceability is the ability to link every requirement to its origin on one side and its implementation on the other. It creates a chain from business need → requirement → design → code → test case, so you can answer two questions at any time: what does this requirement satisfy, and what proves it is done?

Traceability is maintained through a Requirements Traceability Matrix (RTM), which maps requirements to their design elements, code modules, and test cases. Every requirement has at least one test case proving it, and every test case traces back to a requirement, guaranteeing nothing is built without justification and nothing is built without verification.

The benefits are significant. Change management becomes safer — when a requirement changes, the RTM shows exactly which tests and code are affected. Coverage becomes measurable — untested requirements are visible at a glance. And certification and audit become possible, which is why regulators in safety-critical industries mandate traceability. Its cost is maintenance: the matrix only works if it is updated continuously, not at the end.

7. What is requirements volatility?

Requirements volatility is the degree to which requirements change after the initial baseline is set. It is measured by counting requirement changes over time — new requirements added, existing ones modified or deleted — often expressed as a percentage of the original set per month.

Volatility is a risk factor because every change has a cost. A change late in the project is far more expensive than the same change early, since it invalidates design, code, and tests that already exist. High volatility signals underlying problems: requirements were gathered too hastily, stakeholders are uncertain, or the market is genuinely unstable.

Teams manage volatility in two ways. They measure and track it, so spikes are visible early. And they control it through a change process — proposed changes are evaluated for impact, cost, and priority before being accepted. Some volatility is unavoidable, especially in Agile projects, which embrace it. The discipline is to make volatility visible and priced, not to pretend it does not exist.

8. How are requirement changes controlled?

Requirement changes are controlled through a formal change management process, often run by a Change Control Board (CCB). The idea is that no requirement changes silently — every change request goes through evaluation, approval, and documentation before it touches the work.

The flow is: someone submits a change request describing the proposed change and its rationale. The CCB or product owner evaluates the impact — what requirements, design, code, and tests are affected, what it costs, what it does to the schedule and budget. Then a decision is made to accept, reject, or defer the change. Accepted changes are documented, prioritized, and scheduled; rejected ones are recorded with their reason.

This process is what separates controlled change from chaos. In Waterfall, changes go through the CCB and update the baseline. In Agile, change is welcomed but still governed — new requirements enter the backlog through refinement and get prioritized, they do not just appear in the middle of a sprint. The key output is traceability: you can always say what changed, when, why, and who approved it.

9. What is the difference between user requirements and system requirements?

User requirements are written in the language of the user, describing what the system must do for them in business terms. For example, “the system must let a customer track their order status.” They are high-level, outcome-focused, and understandable to a non-technical stakeholder.

System requirements translate those user requirements into precise technical specifications that the development team can build and test against. The same order-tracking example becomes: “the system shall provide a GET /orders/{id}/status endpoint returning JSON with the order’s current state, updated within five seconds of a status change.”

User requirements say what and why; system requirements say how, in measurable terms. A single user requirement often expands into many system requirements covering functionality, performance, interfaces, and constraints. The SRS typically captures both levels — user requirements at the top and derived system requirements below — with traceability linking each system requirement back to the user need it serves.

10. What is the difference between business requirements and technical requirements?

Business requirements describe why the project exists and what business outcome it must achieve. They are written from the organization’s perspective and often expressed in a Business Requirements Document (BRD) or vision document — “increase online sales by 20%,” “reduce manual data entry errors to under 1%.” They are the highest-level requirements, independent of any technology choice.

Technical requirements describe how the system will satisfy those business needs at an implementation level — which platforms, interfaces, performance targets, security controls, and constraints apply. They are derived from and traceable to business requirements.

The relationship is a chain: business requirements drive technical requirements, which drive system and functional requirements. Business requirements answer “why are we doing this and what outcome do we need”; technical requirements answer “what must the system technically do and how must it behave.” A project can meet every technical requirement and still fail if the business requirements were wrong — which is why the business outcome stays the north star.

11. What is feasibility analysis and why is it performed?

Feasibility analysis is a go/no-go study performed at the very start of a project, before significant resources are committed. It asks whether the project is worth doing at all, examining it from several angles before requirements gathering even begins in earnest.

The classic framework is TELOS: Technical feasibility (do we have the technology and skills), Economic feasibility (do benefits justify costs), Operational feasibility (will it work in the organization’s routines and will users accept it), Schedule feasibility (can we finish in time), and Legal feasibility (does it comply with laws and contracts).

It is performed to prevent wasted effort. Many projects are technically possible but financially absurd, or financially sound but operationally unworkable, or simply illegal. Catching those problems before committing resources is far cheaper than discovering them mid-development. The output is a feasibility report recommending whether to proceed, reshape, or abandon the project — and it becomes a key input to the decision to start full requirement analysis.

12. What is schedule feasibility?

Schedule feasibility asks whether the project can be completed within the required time frame. It evaluates the proposed deadlines against the scope, the team’s capacity, and the realistic effort estimates for the work.

The analysis considers the critical path — the sequence of dependent tasks that determines the minimum project duration. It also checks resource availability: do we have enough people with the right skills, available when needed, and are there competing projects consuming the same resources? It factors in dependencies on external parties — vendors, clients, regulatory approvals — that could slip the schedule beyond the team’s control.

If the analysis shows the deadline is impossible, schedule feasibility fails, and the project must be reshaped — reduced scope, added resources, or a later deadline. Its value is honesty: discovering an unrealistic schedule at the start is far cheaper than discovering it three months in. A schedule that passes feasibility review becomes the basis for the detailed project plan.

13. What is legal feasibility?

Legal feasibility asks whether the project complies with all applicable laws, regulations, and contracts. It is easy to overlook and expensive to ignore.

The checks include data protection and privacy law — storing personal data may require consent, encryption, and breach-notification procedures under laws like GDPR or India’s DPDP Act. It covers licensing: using third-party libraries, code, or data must respect their licenses. It covers regulatory compliance specific to the industry — healthcare software faces HIPAA, financial software faces financial regulations, and consumer products face safety standards.

It also covers contracts — the project may be bound by existing agreements with clients, vendors, or employees that restrict what can be built or how data is used. The output is a list of legal constraints that become non-negotiable requirements. A project that passes technical and economic feasibility but fails legal feasibility must be stopped or redesigned, because the risk is not just cost — it is liability, fines, and reputation.

14. What is organizational feasibility?

Organizational feasibility asks whether the project will actually work inside the organization that must build and use it. A system can be technically perfect and still fail if the organization is not ready for it.

It examines operational fit: will the new system work within existing workflows, and will the people affected actually use it? Resistance to change is a classic failure point — a great system rejected by the staff who must operate it. It checks people and skills: does the team have the expertise, and is there training and leadership buy-in to support adoption? It also considers structure and process: does the organization’s hierarchy, decision-making, and culture support the change the project requires?

The feasibility study evaluates these dimensions and surfaces the organizational risks early — training needs, change management plans, stakeholder alignment. A project that is organizationally infeasible needs those issues addressed before development, or it will deliver software that sits unused. Technical success is meaningless if the organization cannot absorb the result.

15. What are the common problems with an SRS?

The most common problem with an SRS is ambiguity — vague words, passive voice, and alternative interpretations that let developers and customers disagree about what was agreed. A close second is incompleteness: missing requirements, unhandled edge cases, and conditions that were assumed rather than written.

Inconsistency is another frequent issue — requirements that contradict each other or duplicate conflicting statements elsewhere in the document. Then there is over-specification, where the SRS dictates design and implementation details that lock the team into a solution instead of describing the requirement. And there is non-testability: requirements stated without any way to verify them, like “the system should be user-friendly.”

Finally, many SRS documents fail on structure and maintenance — no unique identifiers, no prioritization, no traceability, so they cannot be changed, versioned, or verified against the finished product. The common thread is that a badly written SRS becomes a source of conflict and rework, because every reader interprets it differently.

16. What is requirements validation?

Requirements validation is the process of checking that the documented requirements actually reflect what the customer needs and are complete, consistent, and testable — before development locks them in. It asks, “are we building the right thing?” rather than “are we building it right?”

Validation uses structured review techniques. Requirements reviews or inspections bring stakeholders and developers together to examine each requirement for errors. Prototyping lets users validate that their needs are correctly understood by reacting to a working model. Checklists verify standard properties — testability, traceability, consistency, absence of “and/or” ambiguity. Simulation and walkthroughs trace requirements against scenarios to expose gaps.

Validation is different from verification. Verification checks that the work conforms to the SRS; validation checks that the SRS itself is right. It is performed continuously — in Agile, every backlog refinement is a form of validation. Its cost is small compared with the alternative: a requirement error found at validation time is ten to a hundred times cheaper to fix than one found in production.

17. How do you identify missing requirements?

Missing requirements are the hardest to find because you cannot inspect what is not there. The most effective technique is systematic coverage: walk through every stakeholder, every use case, and every system boundary and ask what they need, ensuring no corner of the problem is unexamined.

Use structured checklists — verify that every user role has its workflows, every functional area has its non-functional counterparts (performance, security, usability, reliability), and every interface with external systems is specified. Traceability helps too: if a design or test has no requirement behind it, something was built without justification, and if a requirement has no test, something is unverified.

Try scenario-based methods: step through realistic end-to-end flows and edge cases — what happens at midnight, at zero records, on a broken connection, with a malicious user? These surface requirements people forget to state. Prototyping and observing users also exposes implicit needs. Finally, involve the right stakeholders in review — the person who actually does the work often notices what the spec forgot.

18. What happens when requirements change after development begins?

When requirements change after development begins, the impact depends on how far the project has progressed and how the change is handled. Early changes are absorbed cheaply; late changes can be very expensive because they invalidate completed design, code, and tests.

The correct response is through change control, not improvisation. The change request is evaluated for impact — what code, tests, and documents are affected, what it costs, and what it does to schedule and budget. It is then prioritized and either accepted, deferred, or rejected by the product owner or change control board. Accepted changes are documented, and the traceability matrix is updated so the ripple effect is visible.

In Waterfall, a change means potentially revisiting earlier phases, which is why change is resisted and priced heavily. In Agile, change is expected and cheap by design — it enters the next sprint’s backlog. The worst outcome is uncontrolled change: requirements shifting silently, code being patched without updates to specs, and the project drifting toward the “requirements disease” where the final product matches nobody’s expectations.