What Is Upstream Process?
Key points
- Upstream process refers to the early set of stages in system development where you decide "what to build, and why."
- Its four core activities are business requirements definition, system requirements definition, basic design (external design), and estimation.
- Neglect this stage and you'll face major rework later, during implementation and testing.
Teacher Pochi uses apps like this every day, too
Where it fits in the overall development flow
System development broadly follows this flow: "requirements definition" โ "design" โ "implementation" โ "testing" โ "release & operations."
"Requirements definition" and the first half of "design" (through basic design) make up the upstream process; "detailed design and implementation" onward is called the downstream process. In home-building terms, upstream process is the stage where you decide "what kind of house do I want to live in?" and "how should the floor plan work?"
Why upstream process matters
The later a mistake or misunderstanding from the upstream process is caught, the more expensive it becomes to fix.
Teacher Pochi's hintIf you say "actually, I want another room" after the foundation and framing of a house are already done, that becomes a major, costly addition. Settle on your wishes at the blueprint stage instead, and the fix costs nothing more than a redrawn page.
The four activities that make up upstream process
"Upstream process" isn't a single task โ it's a stack of four activities, each with a different purpose.
Business requirements definition (overview)
Business requirements definition isn't about the system itself โ it's the stage where you clarify the business-side goal or problem: "what do we actually want to solve?" Through interviews with people on the ground and "business flow diagrams" that map out how work is done, you sketch out what the ideal business process should look like and capture it in a "business requirements document."
Teacher Pochi's hintIt's like telling a contractor, before any renovation begins, "our family is growing so we want more rooms" or "we want a house that's easier to keep tidy" โ communicating how you want to live, not yet the specific fixtures.
System requirements definition (overview)
System requirements definition takes the goals settled in business requirements definition and turns them into something concrete: "what should the system actually do?" It's organized into "functional requirements," which describe the features themselves, and "non-functional requirements," which cover quality conditions like performance and availability.
Teacher Pochi's hintThis corresponds to drawing up the renovation's "floor plan and specifications." A wish like "we want more storage" gets translated into a concrete spec such as "install 2 tatami-mats' worth of wall-mounted storage."
Basic design (external design) (overview)
Basic design is the stage where, building on the system requirements, you concretely design "the parts users can see." That includes screen layouts, report formats, and how the system connects with external systems. By contrast, the stage that decides the program's internal structure is called "detailed design (internal design)," which follows basic design.
Estimation (overview)
Estimation is the activity of predicting, ahead of time, how much effort (time and headcount) and cost a development project will require. Techniques include "analogous estimation," which compares against past results, and "bottom-up estimation," which breaks work into small tasks and adds them up โ and you should always build in a "buffer" for the unexpected.
Summary
Upstream process is the foundational stage of system development where you decide "what to build, and why." Any misunderstanding or corner-cutting here comes back as a much bigger cost the further downstream it's caught.
You can dig deeper into each activity in the individual topics below.
Related topics: