Archive

Archive for the ‘Requirement Management’ Category

Business Requirements Vs System Requirements

March 12, 2011 3 comments
S No Business Requirements System Requirements

1

Business requirements are criteria in order for the software to be successful in meeting the user needs. Generally they focus on the “what” not the “how”. System requirements address the “how” associated with the business requirements (the “what”).

2

Business requirements concern the business. Software requirements concern the software solution to the “problem” stated in the business requirements.

3

Business requirements defined as benefits of the business desires. Software requirements define what the solution must do (or be) to assure the business requirements.

4

Business Requirements are goals and targets the business wants to achieve.

Examples:  No: 1 jobs consultancy company

System Requirements are technical goals

 Example: Implement web based job portal.

Benefits of traceability Matrix

March 12, 2011 2 comments
  • Demonstrate the relationship between the requirements to the system.
  • To ensure the design is based on established scope, business requirement or functional requirements.
  • To ensure that the design documents are appropriately verified, and that functional requirements are appropriately validated.
  • To track the requirements changes and their impact to the system
  • To demonstrate the system built met the functionality of the customer, end users needs and expectations.
  • At faster rate can trace back to the functionality/design/test cases, if there is means of any defect/changes to the system.

Requirement Management Vs Requirement Development

July 20, 2010 Leave a comment
S.No Requirement Management Requirement Development
1 An Engineering process area at Maturity Level 2 An Engineering process area at Maturity Level 3
2 REQM is to “manage” the requirements of the project’s products and product components. RD is to “produce” customer, product, and product component requirements. 
3 REQM identifies inconsistencies between requirements and project’s plans/work products RD analyzes the customer, product and product component requirements.
4 Deals with communication between Requirements analysts and customer. RM is customer management oriented. Deals with communication between PM, domain and functional architect, designer and his team. In object oriented domain, it relates to defining services.
5 Specific GoalSG 1 Manage Requirements Specific GoalSG 1 Develop Customer Requirements

SG 2 Develop Product Requirements

SG 3 Analyze and Validate Requirements

6 GP 2.3 REQM uses requirements tracking tools, traceability tools and bi-directional matrix to manage requirement changes GP 2.3 RD uses requirements specification tools, simulators, modeling/ prototyping tools, scenario definition and management tools.
7 GP 2.5 REQM training includes:Application domain, Requirements definition, analysis, review, Configuration management and RM tools, Negotiation and conflict resolution GP 2.5 Examples of RD training includes :Application domain, Requirements definition, analysis and requirements elicitation, Requirements specification, modeling and tracking
8 GP 2.6 REQM deliverables placed under configuration management are requirements and requirements traceability matrix. GP 2.6 RD deliverables placed under configuration management are customer requirements, functionalArchitecture, product and product-component requirements and Interface requirements.
9 GP 2.9 Work products reviewed include requirements and requirements traceability matrix. Work products reviewed include product and product-component requirements, Interface requirements and functional architecture.

Requirement Management

May 2, 2008 5 comments

Requirement Management

 

Purpose

1.      To establish a common acceptance criteria between the Customer and the Project Team on the features and functionalities that are been developed and delivered.

2.      To translating the customer requirements into documented Software Requirements Specification.

 

Process Requirements:

The following are the process of the requirement management:

 

1. Elicitation – Identify the Requirements:

 

Entry Criteria: Business Proposal

 

Procedures:

  • Activity or Task: On approval of business proposal, the team will have to transform the client needs and expectations captured into formal System/ Software requirements

 

Mode of Contact:

 

By Direct Customer Interaction

Record the Customer requirements

Collect necessary materials from the customer

Get clarification on doubts

 

Customer provided requirement document

Analysis the Customer requirement

Comfortable with the requirement

 

Requirement against existing Project / Product

Arrange a demo and record the gaps

Feasibility Study

Prepare Gap Analysis document

  • Record Retention: Draft version of SRS

 

Exit Criteria: Established Requirement

 

2. Analysis

 

Entry Criteria: Established Requirement

 

Procedure:

  • Activities or Task: To identify the requirements in a complete, accurate, consistent, and unambiguous manner.
  • Record Retention: Revised version of SRS

 

Exit Criteria: Analyzed requirements

 

3. Prepare Software Requirement Specification (SRS)

 

Entry Criteria: Analyzed requirements

 

Procedure:

 

Exit Criteria: Software Requirement Specification

 

4. Validation:

 

Entry Criteria: Software Requirement Specification

 

Procedure:

  • Activity or Task

1.      The completed SRS document shall be reviewed. The details of the review shall be recorded in the Review Report-Work Product

2.      On closing all the review comments, SRS shall be approved.

  • Record Retention: Review Report (Software Requirement Review (SRR) – Work product

 

Exit Criteria: Approved Software Requirements Specification