Category Archives: Reviews

White Tiger – Arvind Adiga

Books

Out of curosity, bought the book while on a trip from Bangalore to Dubai. Surprisingly couldn’t keep the book down, and completed it in one session.

Gave to my friends, but no one liked the language and the style. But I had a feeling that this book is going to be hit. And it won the Booker Prize. Now waiting for his second book. Have become a fan of Arvind Adiga.

Published by:

Great Software Debates – Requirements Management

Books

Requirement Management consists of three activities:

Requirements elicitation – is the art of understanding the needs of stakeholders, and collecting them in a repository for future analysis.

Requirements triage – is the art of deciding which features are the appropriate features to include in the product.

Requirement specification – is the art of detailing the exact external behaviour of a system that will address the features selected during the triage process.

Published by:

Great Software Debates – Feature Specification

Books

Importance: On a scale from 0 (unimportant) to 10 (critical), record how important this feature is to stakeholders. Importance will be used during the triage process to decide which features should be included and which should be omitted or delayed to a later version.
Volatility: On a scale from 0 percent (will not change) to 100 percent (guaranteed to change), record how likely this feature is to change in the near future. Volatility will be used during the triage process to decide which features to be included and which should be omitted or delayed to a later version.
Estimate of cost: Although it is impossible to be accurate because of the inherent ambiguity of the feature specification, one needs to record a ballpark estimate of effort. Do this units of person-months, person-hours, dollars or function points. Estimate of cost will be used during the triage process to decide how many features can be included in the project.
Use-dependency relationship among features: Record when a feature makes no sense without another feature. For example, it makes no sense to have billing in place for a new system function if the function itself is not available. This dependency will be used during the triage process to ensure that the included features makes sense as a whole.
Risk: On a scale from 0 percent to 100 percent, record the probability one would fail to satisfy this feature if he or she tries. Risk will be used during the triage process to decide which features will be included in the product to achieve acceptable levels of development risk.
Development-dependency relationship among features: Record when building a feature requires another feature to be built. For example, printing an accounts receivable report is not possible unless the printer-interface software is available. This dependency will be used during the triage process to generate more accurate estimates of the development cost associated with the features selected for inclusion.
Inclusion flag: Use this switch to record the decision to include or exclude the feature from the product. Do not just delete the feature’s record from the database.

Published by:

Great Software Debates – Requirements Elicitation

Books

Elicitation is the set of activities that extracts needs from customers and users and help the solution provider to better understand the problem. Elicitation techniques include:

Interviews

asking relevant questions to stakeholders about the problem to be solved and/or their needs and listening to their response

Are useful when some stakeholders hold most of the subject-matter expertise, are accessible, and are willing to spend time being interviewed.

Questionnaires

Distributing predefined questions to a statistically significant and representative sample of stake holders and tallying the results

Are useful when the population of stakeholders is extremely large. Since it assumes tthat all questions can be predetermined, it works well most effectively to ascertain opinion trends about specific requirements.

Ethnomethodological studies

Observing potential users in their natural environment.

Are useful when trying to provide automation support to an existing less-automated or non-automated function, particularly when the parties are accessible by trained observers with no preconceived notions of the problem or its solution

Brainstorming

Assembling stake holders in one location, establishing an environment that encourages participation, allowing all ideas to be stated out loud and written

Is particularly effective when many stakeholders each hold a modicum of knowledge about some aspect of the problem.

Problem-domain storyboarding

Using physical media to represent sequential states of the problem environment. Scenarios and use case, in their many representations, can be used to represent the same information

Presupposes some knowledge of the problem. Assumes once can start someplace. Unlikely to be effective if it starts with blank slates and no ideas

Prototyping

Constructing a partial implementation of a system in a quick-and-dirty manner to gain feedback for the requirement process, and then discarding the proto-type

Reduces the risks associated with inadvertently building the wrong system. It is a means of converting poorly understood requirements into well-understood requirements. Can be effective only when people can enumerate fuzzy requirements

Reading

Visiting the library or surfing the web to locate information about experts view of the problem and its potential solutions

Works when some individuals understand something already and have written about it, and other people lack that knowledge

Research

Conducting experiments, exploring technology, developing new technology, and applying solutions for one problem to new problems

Effective when the individuals are innovative, and it is appropriate when the ideas do not yet exist.

Evolutionary Development

Constructing a system that satisfies only the most understood requirements with the expectation that once customers start using it, they will think of many new requirements

Works when there are well-understood requirements. Also requires the belief that once customers see some functionality, they will think of more functions they would like to see.

Published by: