Friday, March 24, 2017

Entries for July 2009

23

From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

[Read the rest of this article...]

21

Common presumed best practices for determining Return on Investment (ROI), advocated by almost all apparent authorities, in reality often undermine ROI’s very purposes.

ROI is supposed to provide a valid and reliably supportable objective basis for making decisions: the quantified dollar benefits of an approach versus its quantified dollar costs.

[Read the rest of this article...]

21

A business-driven technology strategy articulates the capabilities required for the success of an organization. To align your business-technology investments with your business strategy, you should focus on the type of value you want to create

Decisions on business-technology investments require structured thinking about what the business wants to achieve. This clear understanding of business requirements dictates the business-technology plans and investments needed to execute the company’s business strategy.
 

[Read the rest of this article...]

06

Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.

However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels.

[Read the rest of this article...]

06

If requirements management practices were songs entering a popularity contest, requirements validation would hardly be a favorite contender. It's easy to understand why: validation is usually a tedious, time consuming task, and, as with nearly every quality control activity, it is supposed to reveal defects, going against our natural desire of being right, not making mistakes, and singing in tune.

[Read the rest of this article...]

06

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

[Read the rest of this article...]

Copyright 2009-2014 by Modern Analyst Media LLC