A software project runs as a cycle: Requirement Analysis → Design → Implementation → Testing → Evolution. What does the Requirements Analyst (RA) contribute in each phase, rather than handing off after the first one?
The RA runs the analysis, specifies and gets the spec approved in design, supports developers during implementation, backs testing and arbitrates defects, and handles change requests and clean-up in evolution — because the requirements are the yardstick every later phase is measured against.
* The lifecycle cycles rather than running once; the Requirements Analyst stays connected to every phase, the standing interpreter of what the requirements mean. *
It is tempting to think the RA's job ends once the spec is written. But requirements keep being referenced long after they are authored, and only the RA can authoritatively say what they meant — so the role is continuous:
| Phase | What the RA does |
|---|---|
| Requirement Analysis | Analyse the stakeholders and the existing documents, elicit requirements through workshops and interviews, analyse business and user requirements, and list the use cases. |
| Design | Specify business processes, actors, use cases and interfaces in detail, cover GUI/interaction design, then run specification reviews and obtain approval. |
| Implementation | Walk the spec through with team leads and developers, support developers day to day, clarify newly opened points with the business, and manage changes. |
| Testing | Provide test support, clarify defects ("is this a bug or expected behaviour?" is a requirements question), clarify new open issues that surface, and manage changes. |
| Evolution | Analyse incoming change requests, support the customer, and clean up the documentation so it still matches the running system. |
The pattern across the phases is the same job seen from five angles: early on the RA creates the yardstick, and from then on the RA interprets it — first for designers, then for developers, then for testers, then for the customer. And because the cycle loops back rather than ending, evolution's change requests feed straight into the next round of analysis.
Tip: Requirements are written once but consulted continuously — that is why the analyst's role spans the whole cycle, not just its first phase.
Go deeper:
Systems development life cycle (Wikipedia) — the phase model this ring is a compact form of, with the variants that reshuffle it.