Showing posts with label requirements management. Show all posts
Showing posts with label requirements management. Show all posts
Sunday, December 20, 2009
How does technology affects product marketing?
Increasing usage of social media and web 2.0 by companies and customers has changed and also has added many roles in organizations. My question is how product management and product marketing roles have been affected by this new wave?
Wednesday, November 25, 2009
How you build your product vision
What factors need to be considered by architects, product managers and development teams for creating product vision?
What drives the definition of a vision that leads to a successful and competitive product?
http://www.linkedin.com/redirect?url=http%3A%2F%2Fbit%2Ely%2F3Thivl&urlhash=wxr_
What drives the definition of a vision that leads to a successful and competitive product?
http://www.linkedin.com/redirect?url=http%3A%2F%2Fbit%2Ely%2F3Thivl&urlhash=wxr_
Sunday, May 24, 2009
The importance of requirements management
The following post discusses the importance of requirements management:
- The requirements management is the “technical language” that collaborates customers, marketing, development and QA
- Gathering, documenting, verifying, and managing requirements throughout the lifecycle ensures satisfying customer needs
- Requiremnts management assures finding defects earlier in the development process
- Keep product definition up-to-date and
- Communicate changes to the R&D
- Ensures that iterative refinements and unanticipated changes are adequately dealt with during the developemnt lifecycle
- Reduce communication overhead with customer and reduce number of patches delivered to customers for each release
Thursday, May 14, 2009
140 words – ALM Analytics and reports – Optimal Requirements vs. Test creation trend
This report usually generated from ALM system that contains requirements management and test management module.

1. Requirements definition - at the beginning of the application lifecycle, the requirements creation trend is higher, later on used by development team and QA team.
QA starts writing his test plan, but in lower rate.
2. End of Requirements definition - QA continues writing test cases.
3. Equation point 1- where number of tests equal to number of requirements.
4. Start QA cycles - start running tests in QA cycles. At this phase, we usually have more test cases than requirements to assure requirements coverage.
5. Next release starts - product manager submits requirements for next release.
6. Equation point 2 - Number of requirements is equal to number of test cases. The same application lifecycle occurs again.

1. Requirements definition - at the beginning of the application lifecycle, the requirements creation trend is higher, later on used by development team and QA team.
QA starts writing his test plan, but in lower rate.
2. End of Requirements definition - QA continues writing test cases.
3. Equation point 1- where number of tests equal to number of requirements.
4. Start QA cycles - start running tests in QA cycles. At this phase, we usually have more test cases than requirements to assure requirements coverage.
5. Next release starts - product manager submits requirements for next release.
6. Equation point 2 - Number of requirements is equal to number of test cases. The same application lifecycle occurs again.
Thursday, March 5, 2009
140 words - The purpose of requirements management tools
The purpose of requirements management is to maximize the likelihood that an application will function as intended and deliver its projected value to the business. Forrester defines requirements management as: The storage of requirements, the tracking of relationships among requirements, and the control of changes to individual requirements and groups of requirements.
Requirements management is both a discipline and a category of tools. Business analysts, business customers, product managers, project managers, and developers use requirements management tools to increase the efficiency of their requirements management practices. The larger the development effort and the more granular the requirements are, the more important tool support is in making proper requirements management cost-effective. For this reason, firms in industries like aerospace and defense, telecommunications, and automotive have long used requirements management tools to support their embedded systems development efforts.
Requirements management is both a discipline and a category of tools. Business analysts, business customers, product managers, project managers, and developers use requirements management tools to increase the efficiency of their requirements management practices. The larger the development effort and the more granular the requirements are, the more important tool support is in making proper requirements management cost-effective. For this reason, firms in industries like aerospace and defense, telecommunications, and automotive have long used requirements management tools to support their embedded systems development efforts.
Sunday, February 8, 2009
Useful Requirements Definition
Overview
This post describes the guidelines for a superior Requirements definition
Guidelines for requirements management:
1. Make short requirements
2. Make testable requirements
3. Make precise requirements
4. Make unique requirements
5. Manage requirements traceability in all ALM aspects (management, development, QA)
6. Define requirements workflow in order to manage requirements lifecycle effectively
7. Use hierarchy to manage a set of requirements by category (functional, security, general, safety, etc.)
8. Manage relations between requirements
9. Distribute requirements in different releases
Benefits of good requirements management:
1. Assisting in customer needs traceability. Basically, the SRS (Software Requirements Specification) will provide feedback to the customer
2. Setting clear expectation between development teams
3. Preventing scope deviations
4. Reducing development efforts
5. Providing the input for the testing team, in the validation and verification process
6. The first stage of requirements definition forms the basis for the project’s effort estimation
7. Good software management decompose the problems into component parts which are easy to understand, trace and cover by other ALM artifacts
The lifecycle of requirement definition process
Requirement first revision
“User shall be able to pay in several payment terms”
The revised requirement
“System will have a payment form, and user shall be able to enter this form and select a specific payment term”
This requirement can be broken down to several sub requirements, so we will use hierarchy to manage this set of requirements:
1. HEAD: Payment Module
1.1 REQ-112: Payment form
1.2 HEAD: Payment methods
1.2.1 HEAD: Credit card
1.2.1.1 REQ-114: Pay by Visa
1.2.1.2 REQ-115: Pay by Amex
1.2.2 REQ-116: PayPal
This post describes the guidelines for a superior Requirements definition
Guidelines for requirements management:
1. Make short requirements
2. Make testable requirements
3. Make precise requirements
4. Make unique requirements
5. Manage requirements traceability in all ALM aspects (management, development, QA)
6. Define requirements workflow in order to manage requirements lifecycle effectively
7. Use hierarchy to manage a set of requirements by category (functional, security, general, safety, etc.)
8. Manage relations between requirements
9. Distribute requirements in different releases
Benefits of good requirements management:
1. Assisting in customer needs traceability. Basically, the SRS (Software Requirements Specification) will provide feedback to the customer
2. Setting clear expectation between development teams
3. Preventing scope deviations
4. Reducing development efforts
5. Providing the input for the testing team, in the validation and verification process
6. The first stage of requirements definition forms the basis for the project’s effort estimation
7. Good software management decompose the problems into component parts which are easy to understand, trace and cover by other ALM artifacts
The lifecycle of requirement definition process
Requirement first revision
“User shall be able to pay in several payment terms”
The revised requirement
“System will have a payment form, and user shall be able to enter this form and select a specific payment term”
This requirement can be broken down to several sub requirements, so we will use hierarchy to manage this set of requirements:
1. HEAD: Payment Module
1.1 REQ-112: Payment form
1.2 HEAD: Payment methods
1.2.1 HEAD: Credit card
1.2.1.1 REQ-114: Pay by Visa
1.2.1.2 REQ-115: Pay by Amex
1.2.2 REQ-116: PayPal
Wednesday, February 4, 2009
Requirements Management - Traceability Matrix
Requirements traceability is about tracing the lifecycle of requirements in all ALM aspects. It can be established using a variety of tools including Application Lifecycle Management (ALM) software, requirements management software, databases, spreadsheets, in-house tools or even with tables or hyperlinks in a word processor.
A requirements management traceability matrix is created by associating requirements with the other ALM artifacts that satisfy them, while the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Following relationships form the traceability matrix:
A requirements management traceability matrix is created by associating requirements with the other ALM artifacts that satisfy them, while the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Following relationships form the traceability matrix:
- High level and low level requirements
- Traceability from marketing department to R&D
- Risk management – relate requirements to risks
- ALM artifact such as code, test cases, test results, defects, tasks, detailed design
The following image illustrates the different relationships valid for requirements traceability:
- Traceability from marketing department to R&D
- Risk management – relate requirements to risks
- ALM artifact such as code, test cases, test results, defects, tasks, detailed design
The following image illustrates the different relationships valid for requirements traceability:

Subscribe to:
Posts (Atom)
