There is no universally accepted model of the requirements engineering process that will suit all organisations or all projects. The process will vary for many reasons but among the factors that have the most influence are:
The nature of the project. A market-driven project that is developing a software product for general sale imposes different demands on the requirements engineering process than does a customer-driven project that is developing bespoke software for a single customer. For example, a strategy of incremental releases is often used in market-driven projects while this is often unacceptable for bespoke software. Incremental release imposes a need for rigorous prioritisation and resource estimation for the requirements to select the best subset of requirements for each release. Similarly, requirements elicitation is usually easier where there is a single customer than where there are either only potential customers (for a new product) or thousands of existing but heterogeneous existing customers (for a new release of an existing product).
The nature of the application. Software requirements engineering means different things to (for example) information systems and embedded software. In the former case, a software development organisation is usually the lead or the only contractor. The scale and complexity of information systems projects can cause enormous difficulties, but at least the software developer is involved from initial concept right through to hand-over. For embedded software the software developer may be a subcontractor responsible for a single subsystem and have no direct involvement with eliciting the user requirements, partitioning the requirements to subsystems or defining acceptance tests. The requirements will simply be allocated to the software subsystem by a process that is opaque to the software contractor. A complex customer / main contractor / subcontractor project hierarchy is just one of many factors that can greatly complicate resolution of any problems that emerge as the software contractor analyses the allocated requirements.
This latter point introduces one of the most controversial aspects of software requirements engineering: the question of ownership. Is requirements engineering a task of software engineering or of systems engineering? In the case of embedded software it is clear that it is a systems engineering task to elicit the user requirements, derive a system architecture composed of appropriate technologies, and allocate the requirements accordingly. In the case of information systems, it is less clear but broadly the same activities have to be performed despite the absence of non-IT technologies. These similarities are likely to become more apparent if, as seems likely, economic imperatives force increasing use of component architectures. Here, solutions are composed of commercial off-the-shelf (COTS) software components integrated with relatively small amounts of bespoke software. The requirements engineering problem then becomes one of finding a best match between the elicited user requirements and the advertised properties of the COTS components.
Because of ambiguity about 'ownership' of the discipline and the artificiality in distinguishing between system and software requirements, we henceforth omit the word 'software' and talk about 'requirements engineering' except where it is helpful to make a distinction.
This is also reflected by the coverage of requirements engineering by standards. Requirements documentation is the only aspect of requirements engineering that is covered by dedicated standards. Wider requirements engineering issues tend to be covered only as activities of software engineering or systems engineering. Current process improvement and quality standards offer only limited coverage of requirements engineering issues despite its place at the root of software quality problems.
