jump to navigation

RACI Chart May 20, 2008

Posted by Coolguy in Business Analysis.
Tags: ,
1 comment so far

RACI Chart describes roles and responsibilities of various people involved in a project. The acronym RACI stands for:

Responsible : Resources who complete the task

Accountable : Person responsible for completion of the task. Also called as Approver.

Consulted : People whose inputs are sought during the process of completing the task

Informed : People who are kept up-to-date on the progress of the task.

This tool is along with stakeholder matrices to identify all the stakeholders in a project and define a communication plan that is appropriate for them.

Kano Analysis February 4, 2007

Posted by Coolguy in Business Analysis, Six Sigma.
Tags: , ,
add a comment

Kano analysis is a tool which can be used to classify and prioritize customer needs. Its named after its developer Noriaki Kano.

Kano analysis is a quality measurement tool used to prioritize customer requirements based on their impact to customer satisfaction.Kano analysis is a quality measurement tool which is used to determine which requirements are important. All identified requirements may not be of equal importance to all customers. Kano analysis can help you rank requirements for different customers to determine which have the highest priority.

This is useful because customer needs are not all of the same kind, not all have the same importance, and are different for different populations. The results can be used to prioritize your effort in satisfying different customers.

Note that the Kano model can be used to help identify customer segments, based on the relative priority of each segment’s requirements. Once segments have been defined, using both needs analysis and more tradition criteria such as gender, company size, etc., the Kano model can be re-applied to each segment to further defined the segment’s priorities.

Kano Analysis Model groups customer requirements into three basic categories:

  • Dissatisfiers ~ Basic Requirements ~ Threshold ~ “Must be’s”
  • Satisfiers ~ Variable Requirements ~ Performance ~ “More is better”
  • Delighters ~ Hidden requirements ~ Excitement

A successful product should have

  • All dissatisfiers
  • Maximum Satisfiers
  • As many delighters as possible within marketable cost of product

Dissatisfiers: Attributes of a product that customers take for granted. Customer will not buy a product if it doesn’t have this basic features. E:g Picture and sound in a TV

Satisfiers: Customers uses these to rate a product against its competition. E.g: Price of a TV

Delighters: Going beyond customer expectations. Delighters are typically provided free or with limited cost. Delighters introduce novelty to the product. E.g: A TV with games etc.

Prioritisation September 19, 2005

Posted by Coolguy in Business Analysis.
add a comment
  • One problem with requirements is that there are always too many of them.
  • So there has to be some way of choosing which ones will be implemented in which versions of the product.
  • The requirements need to be put into an order of desirability, in other words they need to be prioritised
  • Decisions about prioritisation are complex because they involve many different factors and these factors are often in conflict with each other
  • Also, as there are many stakeholders with different goals, it is difficult to reach agreement about priorities

Prioritisation Factors

  • Minimise Cost of implementation
  • Value to customer
  • Time to implement
  • Ease of technical implementation
  • Ease of business implementation
  • Value to the business
  • Obligation to some external authority

Prioritisation Procedures
Requirement Priority Grading

  • You can do a rough prioritisation and give each business event response a priority rating. Something like High, Medium, Low will work fine
  • For example some people grade requirements by release or version number: R1, R2, R3…. The idea is that the R1 requirements are the highest priority and are intended to appear in the first release, the R2 in the second release and so on.
  • If your progressive prioritisation using the above ideas still leaves you with more requirements than will fit into your budget, then you need to go into much more detail.

Prioritisation Spreadsheet

  • You can use a spreadsheet to prioritise the requirements
  • The %Weight is the agreed percentage importance of a factor
  • You arrive at the percentage weight by stakeholder discussion and voting.
  • The total percentage weights for all factors must be 100%
  • In column 1 you list the requirements that you want to prioritise. These might be atomic requirements or they might be clusters of requirements represented by product use cases, product features or business event responses.
  • Then for each requirement/factor combination you give a score out of 10

Dealing with a difficult customer September 19, 2005

Posted by Coolguy in Business Analysis.
Tags: ,
add a comment
  1. Do stakeholder Analysis. Identify your Stakeholders, Prioritise Your Stakeholders, Understand your key stakeholders
  2. Do a colour coded stakeholder map
  3. Having a chat with the stakeholders before hand gives you a feeling as to how stakeholders will behave.
  4. May be you can invite another stakeholder who can neutralise.
  5. If you have to get some points across, and people are against it, the natural reaction is to win them over by paying a lot of energy to them. Instead, you should support the people who agree on the matter in convincing the disbelievers
  6. In this way you have more people to spread the word and mostly from the same environment as the ‘don’t wanna’s’. And we all have the tendency to accept something faster from someone out of the same environment, then from a total stranger.
  7. People come to defend their ground, to conquer new ones, to enhance power, to reduce influences from others, or just basically to kill time
  8. You have to fulfil everyone’s wishes today. The people in the room have their issues, their stakes, and they will project it on the topic of the day
  9. If people don’t want to be concerned with the project in the first place, they can frustrate the process of conducting the workshop
  10. You will not get them. Today. You can handle them later on. You need to be prudent enough to decide when you have to move on. You cannot tolerate them having an impact on the flow of the workshop.
  11. But you can block it by having some colleague sitting in that also feels differently about the subject. Or a senior manager, who shuts him or her up.
  12. If you cant do anything just document it in Controversy and carry on.
  13. when the other person begins to push, don’t push back
  14. When someone adamantly sets forth a position, neither reject it nor accept it. Treat is as a possible option and then look for the interest behind it (the hidden agenda is always a possibility?).

INCOSE Requirements Management Tools Survey September 13, 2005

Posted by Coolguy in Business Analysis.
add a comment

INCOSE Requirements Management Tools Survey

Requirement Quality Factors September 13, 2005

Posted by Coolguy in Business Analysis.
add a comment


  • Can you draw only one interpretation of this use case?
  • Does this use case accurately describing the functionality to be delivered?


  • Does this use case have all the details necessary to implement it? E.g: Missing postconditions
  • Identify the area you need more details on, if you have answered ‘No’ to the above question.
  • Are all of the requirements related to functionality to be provided by this use case included?
  • Are all possible entry/exit criteria for this use case specified?
  • Are all the possible error/exception conditions and strategy to handle these conditions identified?
  • Are all possible error messages included and do they indicate actual error produced?
  • Are all of these requirements related to inputs included?
  • Data type
  • Range
  • Options
  • Formats
  • Constraints (Eg: Unique)
  • Defaults
  • Sort order
  • Are all of these requirements related to Outputs included?
  • List the business terms in the use case that you do not understand.
  • Are all units of measure defined? (E.g.: Throughput, Response Time, Availability Time, User Friendly ness etc)


  • Are the relationships (extends, includes etc) with other use cases clearly identified?
  • Are there any other relationships which are haven’t been identified? (Please specify use case numbers and relationships)


  • Can you write a test case for this use case?


  • Can this requirement be implemented within known constraints?
  • Is there anything in this use case that makes you uneasy?

Necessity / Reason

  • Do you understand why customer needs this?


  • Is there a probability that this use case will cause undesired events?


  • Are there any assumptions you made or the use case makes?
  • Do you have concerns regarding the following issues for this use case:
  1. Reliability
  2. Performance
  3. Security
  4. Support
  5. Maintenance
  6. Deployment
  • Does this use case/functionality conflict with any other use case?


  • Associated information
  • Complete
  • Consistent
  • Feasible
  • Independent
  • Modifiable
  • Necessary
  • No unnecessary design
  • Non-redundant
  • Terse
  • Testable
  • Traceable
  • Understandable
  • Within scope




Automated Requirement Measurement (ARM) Tool September 13, 2005

Posted by Coolguy in Business Analysis.
add a comment

The objective of the ARM tool is to provide measures that can be used by project managers to assess the quality of a requirements specification document.

It is an aid to “writing the requirements right”, not “writing the right requirements”.

Automated Requirement Measurement (ARM) Tool

Effects of requirements of poor quality September 13, 2005

Posted by Coolguy in Business Analysis.
add a comment
  • Increase cost and schedule: Effort is spent during design and implementation trying to figure out what the requirements are
  • Decrease product quality: Poor requirements cause the wrong product to be delivered or descoping to meet schedule or cost constraints
  • Increase maintenance effort: Lack of traceability increases the effort to identify where changes are required, especially as knowledgeable personnel leave
  • Create disputes with the customer/client: Ambiguity causes differences in expectations and contractual issues
  • Are a major cause of project failure: all of the above

Requirements Traceability Matrix September 13, 2005

Posted by Coolguy in Business Analysis.
1 comment so far
  • A traceability matrix is created by associating requirements with the work products that satisfy them.
  • Tests are associated with the requirements on which they are based and the product tested to meet the requirement
  • Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher level requirements are allocated to lower level requirements
  • Traceability is also used to manage change and provides the basis for test planning.

Introduction to Requirements Management September 13, 2005

Posted by Coolguy in Business Analysis.
add a comment
  • Requirements management involves establishing and maintaining agreement between customer and developer on both technical and non-technical requirements.
  • This agreement forms the basis for estimating, planning, performing, and tracking project activities throughout the project and for maintaining and enhancing developed software
  • Key activities include:
  • Planning the requirements phase
  • Establishing the requirements process
  • Controlling requirements changes
  • Minimizing the addition of new requirements (scope creep)
  • Tracking progress
  • Resolving issues with customers and developers
  • Holding requirements reviews

Requirements Management Plan

  • A requirements management plan is a component of the project management plan.
  • Generally, the purpose of RM is to ensure customer and developer have a common understanding of what the requirements for an undertaking are
  • Depending on your project standards, a variety of sections might be included in your RM plan. Some examples are:
  1. introduction to RM and document overview
  2. document scope
  3. issues affecting implementation of the plan, such as training on the RM tool
  4. applicable documents, such as policies and standards
  5. terms and definitions used in the plan
  6. methods and tools that will be used for the RM process (or the requirements for selecting a tool if one is not selected)
  7. the RM process, including any diagrams of the process
  8. authorities and responsiblities of participants
  9. strategy for achieving requirement quality, including traceability and change control
  10. appendices usually contain a discussion of quality factors, as well as references, any forms to be used in the process, and additional details not included in the main body of the plan, such as report examples

Requirements Management Metrics

  • Requirements management can provide vital information.
  • For example, by associating costs with requirements and using the data to estimate similar work, improvements in cost estimates are possible.

Requirements Traceability Matrix

  • The purpose of the RTM is to help ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix
  • A traceability matrix is used to verify that all stated and derived requirements are allocated to system components and other deliverables (forward trace).
  • The matrix is also used to determine the source of requirements (backward trace). Requirements traceability includes tracing to things other than software that satisfy the requirements such as capabilities, design elements, manual operations, tests, etc.
  • The traceability matrix is also used to ensure all requirements are met and to locate affected system components when there is a requirements change
  • The ability to locate affected components allows the impact of requirements changes on the system to be determined, facilitating cost, benefit, and schedule determinations.

Traceability Strategy

  • The traceability strategy is devised by graphing relationships between work products
  • Software is developed in stages, each with work products that can be associated with work products of the previous stage, creating the ability to trace from the requirements through the work products and from the work products back to the requirements
  • The need (requirement) for a new system or modification to the current system is identified. The need is analyzed to further define the requirement.
  • A feasibility study should be performed to answer questions in more detail such as: what needs to be done, what is the value of doing it, what business goals are supported, how can it be done, what are the alternatives, and what are the risks. The results are documented in a business case. Requirements at this stage are insufficiently detailed to build or modify a system
  • A project may then be initiated based on the selected alternative from the business case. Ideally, the requirements traceability matrix (RTM) is started now. The high level requirements are linked to the business goals. As work products are created throughout development, the RTM will be updated to provide full traceability.
  • An Operations Concept document may be created to convey uses of the system and to set the system and project boundaries. A top-level architecture document may also be developed
  • System functional requirements are documented in three phases: identification, analysis, and baseline establishment.
  • During the identification phase, the developer/maintainer reviews the documents provided by the customer to identify the specific system functional and performance groups into which the requirements fall. The requirements may be further categorized into subgroups. Interviews, prototyping, and a variety of techniques may be used to identify requirements.
  • The requirements are analyzed to ensure they are complete, consistent, testable, and feasible within budget and technical constraints. The requirements are also reviewed to eliminate redundancy. Acceptance criteria for each requirement are developed. A draft system specification is produced.
  • After approval, the requirements and associated documentation are formalized as the functional baseline.
  • Design, code, test, manuals, and other work products are developed in accordance with the requirements.
  • As they are developed, work products in the functional baseline may be updated or modified in accordance with the organization’s configuration management process.
  • Traceability is used throughout to verify that goals and requirements are being met