Requirements and product management

Before a system can be architected or built, someone has to work out what it should do and why. Requirements and product management covers that upstream work: discovering the problem worth solving, capturing what the system must do, and planning how that work gets prioritized and delivered. It sits ahead of software architecture, which takes requirements as an input rather than producing them.

Discovering the problem

Discovery is the activity of investigating a problem space before committing to a solution, often through user research, prototyping, and testing assumptions cheaply before writing production code. Persona and user-centered design are tools for keeping that investigation grounded in real users rather than the team’s own assumptions: a persona is a composite profile representing a class of user, and user-centered design is the broader practice of designing around users' actual needs and behavior. A mashup is a lighter-weight discovery artifact in its own right, a working combination of existing services or data sources built to demonstrate an idea quickly. Prototyping is the broader practice both belong to: building a quick, rough version of something to learn about it before committing to a production implementation.

Capturing requirements

Functional requirements describe what a system must do; a system requirements specification (SRS) and a product requirements document (PRD) are two common formats for writing those requirements down, differing mainly in audience and level of formality. A use case describes a specific interaction between a user and the system in enough detail to be implemented and tested against. Whatever the format, traceability is what keeps a requirement connected to the design decisions, code, and tests that fulfill it, so that its origin and status remain visible as the system evolves.

Managing the work

Governance is the set of decision rights and processes that determine who can approve a requirement, a change, or a release, and it typically sits above any single project. Critical path analysis and the PERT chart are planning techniques for sequencing work and identifying which tasks determine the overall schedule. A crash program is the drastic response when that schedule is unacceptable: adding resources and cutting corners to compress a timeline, usually at a cost the technique itself is named for. Management information systems (MIS), enterprise application software (EAS), and enterprise resource planning (ERP) describe the large, cross-functional systems that this kind of requirements and planning work is often done in service of building or integrating.

See also