Requirements Elicitation

The Operational Concept Description (OCD) describes a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used.

Computer-Aided Software Engineering

Contract Data Requirements List

Computer Software Configuration Item

The purpose of Requirements Development (RD) is to elicit, analyze, and establish customer, product, and product component requirements

• Specific Practices by Goal
• 1 Develop Customer Requirements
• 1.1 Elicit Needs
• 1.2 Transform Stakeholder Needs into Customer Requirements

• 2 Develop Product Requirements
• 2.1 Establish Product and Product Component Requirements
• 2.2 Allocate Product Component Requirements
• 2.3 Identify Interface Requirements

• 3 Analyze and Validate Requirements
• 3.1 Establish Operational Concepts and Scenarios
• 3.2 Establish a Definition of Required Functionality and Quality Attributes
• 3.3 Analyze Requirements
• 3.4 Analyze Requirements to Achieve Balance
• 3.5 Validate Requirements

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

A product requirements document (PRD) is a document written by a company that defines a product they are making, or the requirements for one or more new features for an existing product.

A PRD should generally define the problems that a product (or product feature) must solve, but should avoid defining the technical solution to those problems. This distinction allows engineers to use their expertise to provide the optimal solution to the requirements defined in the PRD.

Requirements, including:

• functional requirements
• usability requirements
• technical requirements
• environmental requirements
• support requirements
• interaction requirements

Software requirements specification (SRS)

• A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints) .
• The software requirements specification document enlists all
• necessary requirements that are required for the project development.
• To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer.

In requirements engineering, requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering.

• The boundary of the system is ill-defined or
• the customers/users specify unnecessary technical detail that may
• confuse, rather than clarify, overall system objectives.

Identify the real problem, opportunity or challenge.

Identify the current measure(s) which show that the problem is real.

Identify the goal measure(s) to show the problem has been addressed and the value of meeting it.

Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly.

Define the business "whats" that must be delivered to meet the goal measure(s).

Specify a product design how to satisfy the real business requirements

Interface Requirements Specifications