Requirement Management Process

Intorduction

Feasibility study can drive your selection for projects and products, from different perspectives

In addition, the information system nature can require different skills.

Key Process Roles

Product Manager

Assure that the project/product scope meet the existing business architecture phase, that achieve organization objectives

Product Owner

Transform the customers requirements to the technical team, and clarify all details that enable the estimation, and the delivery of the solution

Team Members

Plan , Execute and deliver the solution

Requirements types

Functional Requirements

Represents the functional requirements that touches the core system functionality to achieve customers objectives.

Example:

Enable Adding/Deducting items from and to store.

Non-Functional requirements

Generic requirements that touch and govern the system behavior within the working environment.

Example:

Response, User friendly, Auditability, Security

Transformation Requirements:

Which support the solution purpose, and the improvement requirements between the old and the new states, whatever these states(system, direction)

Example:

Increase customer productivity 50% than old solution

Sample of Non-Functional Requirements

OO Analysis Process

From the OOA perspective, the process should be as follow:

Object responsibility
Object configuration
Domain generic attributes
Domain specific attributes
Object functionalities
Main scenarios
Alternative scenarios
BRM: Business rules management
BPM: Business process management
Object Views
Object states
Sender: What to send to the world
Subscribers: What to listen for from the world
Integration requirements

Cross modules
Third Parties

Reports and visualization
Object Security

Object metadata
Object data

Object characteristics in OOA

Core Procedures

01-Requirements_Elicitation

The objective of the elicitation procedure is to discover and capture candidate software requirements (both functional and non-functional) by communicating with the customer and/or end users and others who have stake in the system development. There are several techniques to elicit requirements, which include brainstorming, interviews, questionnaires and focus groups.

02-Requirements Validation

The objective of the validation procedure is to ensure that the developed SRS reflects the customer requirements. The process involves communicating SRS to all stakeholders and facilitating agreement among them.

03-Requirements Analysis

The purpose of the analysis procedure is to further understand the requirements to resolve conflicts and inconsistencies and to ensure that they meet the required quality attributes and reflect the customer needs. The procedure also involves negotiation among stakeholders to agree on a set of requirements. Tasks of this procedure will likely be repeated several times until an agreement is reached.

Procedures in depth

Tools

Enterprise Architect, CASE tool that used by all engineering team members
Microsoft Team Foundation Server

Video Library

Page updated

Google Sites

Report abuse