The goal is to elicit, document, verify, and agree upon the scope of what is and what is not to be built. This information is used by analysts and software engineers to build the system, by testers to verify the system, and by the project manager to plan and manage the project. Requirements activities include:

• Working closely with project stakeholders to understand their needs
• Defining the scope of the system
• Exploring usage, business rules, the user interface, and technical (non-functional) requirements via appropriate modeling techniques
• Identifying and prioritizing new or changed requirements as they are identified throughout a project

Depending on the development approach taken and type of project, Requirements activity may be initiated a few (eg Enhancement) or many times (Eg Agile development). It is important not to have the requirements activity as a single activity or phase in a project as this can create a sign off gate that is difficult to get passed and creates delays. Where possible, requirements should always be signed off in stages so that technical design can start on those items agreed while requirements work continues on any outstanding issues. For this to happen effectively, it is necessary to exercise good version management and structure requirements documents such that sections or individual requirements can be agreed.

Initial customer requirements are successively refined into more and more detailed component requirements. During the build, design decisions, corrective actions, and feedback should always be analysed for their impact on the established requirements.

Frequently, user needs, expectations, constraints, and interfaces are poorly identified or conflicting in the early stages of a build. An iterative process (getting ever more detailed) should always be used to ensure all user needs, expectations, constraints, and limitations are identified and understood.

As well as recording stated requirements, it is important always to eliciting further requirements not explicitly stated by use of such tools as prototypes etc. Examples of techniques to use include:

• Technology demonstrations
• Questionnaires, interviews, and operational scenarios obtained from end users
• Operational walkthroughs and end-user task analysis
• Prototypes and models
• Brainstorming
• Beta testing
• Extraction from sources such as documents, standards, or specifications
• Observation of existing products, environments, and workflow patterns
• Use cases
• Business case analysis
• Reverse engineering (for legacy products)

Requirements also need to be assessed against the operational needs (including support and maintenance). This often produces more derived requirements, including:

• Operational Constraints
• Technological limitations
• Risks
• Factors introduced by regulations and laws

Typical operational constraints and Technological limitations include:

• Capacity considerations
• Disaster recovery considerations
• Business continuity considerations