At I.T.S., requirements gathering is not treated as a phase that ends before development begins. It is a continuous discovery process involving users, analysts, architects, developers, project managers, and executives—each participating at the appropriate level.
The central element of this methodology is the identification of a super user: a person who understands the operation deeply enough to represent the real workflow and who can work directly with the technical team throughout the project.
Identifying the Right Super User
A super user is not necessarily the person with the highest title, the longest tenure, or the strongest personality. The best candidate is usually someone who understands both the formal process and the many exceptions that occur during normal operations.
During initial interviews and onsite visits, several characteristics can be identified relatively quickly.
A strong super user can explain not only what the organization does, but also why it does it. When describing a process, this person naturally mentions exceptions, dependencies, alternative paths, and the information required to make decisions.
The candidate should also be comfortable acknowledging uncertainty. A user who says, “I need to verify that,” is often more valuable than someone who provides confident but inaccurate answers.
Other important qualities include:
- Strong operational knowledge.
- Credibility among coworkers.
- The ability to explain processes clearly.
- An understanding of upstream and downstream consequences.
- Openness to questioning existing procedures.
- Availability for frequent, short interactions.
- Interest in improving the process rather than merely reproducing it.
- Willingness to test incomplete solutions and provide specific feedback.
One of the easiest ways to identify a super user is to observe who other employees consult when something unusual occurs. The real operational authority is often the person coworkers approach when the documented procedure does not provide an answer.
Why an Executive Is Usually Not the Super User
Executives are essential to the project, but they are rarely the best source for detailed operational requirements.
An executive normally understands the desired outcome, organizational priorities, financial constraints, and major risks. However, the executive may not perform the daily work or encounter the exceptions that determine whether the software will succeed.
Executives often describe how a process is expected to work. Operational users describe how it actually works.
This difference is not a criticism of leadership. It reflects the responsibilities of each role. Executives should define:
- Business objectives.
- Strategic priorities.
- Budget and resource constraints.
- Regulatory or contractual obligations.
- Acceptable risk.
- Project authority and escalation paths.
- Final measures of success.
The super user should define and validate:
- Actual workflows.
- Operational decisions.
- Data requirements.
- Exceptions.
- Dependencies.
- Usability considerations.
- Testing scenarios.
- Day-to-day consequences of design decisions.
Using an executive as the primary requirements source creates a significant risk: the development team may produce software that accurately reflects management’s conceptual model but does not support the work performed by employees.
Keeping Executives in the Loop
Not using an executive as the primary operational user does not mean excluding leadership.
Executives should remain involved through structured, concise checkpoints focused on decisions rather than implementation details. They should receive clear summaries of:
- What has been learned.
- Which workflows have been confirmed.
- Which assumptions have changed.
- Which risks have been identified.
- Which decisions require executive authority.
- Whether the project remains aligned with its original objectives.
- What will be delivered next.
Executives should not be required to attend every requirements session. Their involvement should be deliberate and efficient.
A useful governance model includes:
- An initial executive session to define objectives and constraints.
- Operational discovery sessions with the super user and other users.
- Periodic executive reviews of findings, risks, scope, and progress.
- Immediate escalation when a decision affects budget, policy, compliance, or strategic direction.
- Final validation that the resulting system supports the expected business outcome.
This keeps leadership informed without forcing executives into detailed discussions that are better handled by operational and technical participants.
The Project Manager Works Beside the Team
The project manager should not become a communication barrier between the users and the people designing the system.
At I.T.S., the project manager works alongside the analysts, architect, developers, and users. The project manager coordinates priorities, schedules, decisions, dependencies, and accountability, but does not replace direct communication.
A common project anti-pattern is the creation of a long communication chain:
User → supervisor → business analyst → project manager → architect → developer
Every handoff introduces interpretation. Details are summarized, terminology changes, assumptions are added, and important operational context disappears.
A better model is direct collaboration:
User ↔ analyst ↔ architect ↔ developer
The project manager remains involved, but as a facilitator and coordinator rather than a gatekeeper.
Developers should hear how users describe the problem. Architects should observe the workflow. Analysts should participate in design discussions. Users should be able to see how their requirements are being interpreted.
The objective is not to eliminate roles. It is to eliminate unnecessary translation layers.
The Analyst, Architect, and Developer Discover Together
Separating requirements gathering from software design creates artificial boundaries.
An analyst may document what the user requested without recognizing a technical constraint. A developer may implement the document without understanding the operational context. An architect may design an elegant structure that does not support real exceptions.
When analysts, architects, and developers participate together, each person listens from a different perspective.
The analyst identifies processes, actors, rules, and missing information.
The architect identifies boundaries, reusable patterns, integrations, security requirements, and long-term consequences.
The developer identifies implementation risks, data dependencies, ambiguous behavior, and opportunities for rapid validation.
This combined perspective allows the team to detect problems while the user is still available to clarify them.
It also prevents a damaging assumption: that a requirements document can completely replace direct interaction with users.
Documentation is essential, but it is a record of understanding—not a substitute for understanding.
Do Not Stress the User
Requirements gathering can become exhausting when users are placed in long meetings and expected to describe every aspect of their work from memory.
This approach rarely succeeds.
Users perform many tasks automatically. They may know how to complete a process without being able to explain every decision in a formal interview. Long sessions also reduce concentration and encourage users to provide simplified answers merely to finish the meeting.
I.T.S. avoids this by using short, focused interactions.
A productive session may address only one workflow, one screen, one exception, or one decision. The team then documents what was learned, creates a prototype or working increment, and returns with something concrete for the user to review.
Users usually provide better feedback when reacting to a visible example than when answering abstract questions.
Instead of asking:
“Describe every requirement for the claims-processing system.”
The team can ask:
“Show us what happens when this claim cannot be matched to a member.”
The second question is specific, observable, and connected to real work.
Observe Work Instead of Relying Only on Interviews
Users may unintentionally omit important steps because those steps have become routine.
Initial visits should therefore include observation whenever possible. The team should examine:
- The order in which tasks are performed.
- The applications and documents being used.
- Information copied between systems.
- Spreadsheets maintained outside the primary platform.
- Notes placed on paper or sent through email.
- Repeated manual calculations.
- Decisions requiring supervisor approval.
- Workarounds created because the existing system is insufficient.
- Exceptions that cause delays.
- Information users need but cannot easily access.
A spreadsheet that “is not part of the official process” may contain some of the most important requirements in the entire project.
The objective is not to automate every existing action. It is to understand why the action exists and determine whether it should be preserved, improved, or eliminated.
Accept That the First Understanding Will Be Incomplete
Even with experienced users and skilled analysts, the initial requirements will not be complete.
This is not evidence that the team failed. It is a normal characteristic of software discovery.
Users remember additional scenarios when they see the first prototype. New dependencies emerge during integration. Previously invisible business rules become obvious when the team attempts to automate them. A proposed design may reveal that two departments understand the same process differently.
A methodology that assumes all requirements can be finalized before design begins creates pressure to defend early assumptions instead of improving them.
The correct objective is not to prevent all change. It is to make change inexpensive, visible, and controlled.
At I.T.S., early designs are treated as working hypotheses. They are validated through prototypes, real data, user interaction, and incremental implementation.
Why Waterfall Feels Natural and Where It Falls Short
The waterfall model feels natural because it reflects the way planned work is commonly described: understand the need, approve the plan, design the solution, build it, test it, and deliver it. Its sequence is easy to explain and appears to make progress predictable:
- Gather requirements.
- Approve the requirements.
- Design the system.
- Develop the system.
- Test the system.
- Deliver the system.
This sequence is a useful planning model. The problem begins when it is also treated as a complete discovery model, creating the impression that uncertainty can be eliminated at the beginning of the project.
In most software projects, it cannot. Requirements, design, implementation, and validation influence one another continuously.
The problem is not planning or the natural order represented by waterfall. It is the assumption that requirements can be completely understood before users interact with the solution.
A specification may appear complete until development exposes missing rules. A workflow may seem simple until real data introduces exceptions. A user may approve a written description and later reject the implemented behavior because the document did not communicate the experience accurately.
Waterfall can still be useful for contractual milestones, infrastructure deployments, regulatory approvals, or components with stable and well-defined requirements. It should not, however, prevent iterative discovery within the software-development process.
From Spiral and RUP to Agile Delivery
The spiral model moves beyond a single sequential pass. It treats development as a continuing series of risk-driven cycles in which objectives are defined, alternatives are evaluated, solutions are developed, and the next cycle is planned. Discovery and refinement are therefore expected to continue as the system evolves.
The Rational Unified Process goes further by making development iterative and incremental while allowing its disciplines to proceed in parallel. Requirements, analysis, design, implementation, and testing do not occur only once or wait for a complete handoff; their relative emphasis changes across iterations while work continues in several areas.
These ideas anticipated important parts of agile development. However, recognizing iterations and parallel work is not sufficient by itself to create agility. As RUP was commonly implemented, prescribed roles, artifacts, phase gates, and governance could still place the process ahead of rapid feedback and working software.
Agile methodologies push the continuous-development idea further through shorter feedback cycles, adaptive planning, direct collaboration, frequent delivery, and decisions based on working software. A project does not become agile merely because traditional phases overlap or because development is divided into iterations.
Spiral and RUP can remain effective, particularly for large teams, high-risk systems, or complex enterprise programs, and both can be tailored. The problem appears when any methodology is applied rigidly and the team spends excessive time managing artifacts, roles, approvals, and compliance without obtaining proportional value.
The solution is not to reject formal methodology or assume that an agile label solves every problem. It is to preserve the practices that reduce risk, shorten the distance between discovery and validation, and remove ceremony that does not improve the result.
I.T.S. uses a practical hybrid approach:
- Executive alignment establishes objectives and constraints.
- Initial discovery identifies the super user and core workflows.
- Short sessions capture specific operational knowledge.
- Analysts, architects, and developers collaborate directly with users.
- Prototypes validate assumptions early.
- Development proceeds incrementally.
- Documentation is updated as understanding improves.
- Executives receive regular decision-oriented summaries.
- Scope, risks, and priorities remain controlled by the project manager.
- Real users validate the software using realistic scenarios and data.
This approach preserves discipline without treating the methodology as more important than the result.
Requirements Are Decisions, Not Just Documents
A requirement is not complete because it was written down.
It is complete when the team understands:
- Who performs the action.
- What information is available.
- Which decision must be made.
- Which rules apply.
- What happens when the normal process fails.
- Who needs the result.
- What downstream processes depend on it.
- How the user will know that the action succeeded.
- How the organization will measure whether the solution creates value.
The final requirements documentation should reflect these decisions. It should also identify assumptions, unresolved questions, exceptions, ownership, and acceptance criteria.
Documents should support collaboration and preserve knowledge. They should not create distance between the people who understand the work and the people who build the software.
Conclusion
Effective requirements gathering is not a sequence of long interviews followed by a signed document. It is an organized collaboration between operational knowledge, business authority, and technical judgment.
The super user brings the reality of daily operations. Executives provide direction, authority, and strategic alignment. The project manager maintains coordination and accountability. Analysts, architects, and developers convert operational knowledge into a sustainable solution.
The most important principle is simple:
Do not place unnecessary layers between the user who understands the problem and the team responsible for designing the solution.
Short interactions, direct observation, early prototypes, continuous validation, and controlled iteration produce better requirements than attempting to predict the entire system at the beginning of the project.
Software requirements are not gathered once. They are discovered, tested, refined, and converted into working behavior.