Friday, March 24, 2017

Entries for 'Outside Wisdom'

03

As the process of capturing and documenting business requirements matures, there is often a watershed moment when an organization must decide whether to perform traceability of requirements as part of that process. Most companies involved with a formal methodology for software development utilize some degree of traceability; but those not familiar with it could be put off by the overhead of requirements management (RM), of which traceability is a component. Therefore, it helps to understand some of the value aspects of instituting traceability.

[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...]

30

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements.

[Read the rest of this article...]

30

This is a great presentation by Donald Firesmith covering the topic of Reusable Security Requirements.
 

[Read the rest of this article...]

30

There are many requirements elicitation methods, but we seldom see elicitation performed specifically for security requirements. One reason for this is that few elicitation methods are specifically directed at security requirements. Another factor is that organizations seldom address security requirements elicitation specifically and instead lump them in with other traditional requirements elicitation methods.

This article describes an approach for doing trade-off analysis among requirements elicitation methods. Several case studies were conducted in security requirements elicitation; the detailed results of one case study and brief results of two other case studies are presented here.

[Read the rest of this article...]

16

The cancellation of the presidential helicopter brought everyone out of the wood work. The article's key point was "failure to manage requirements on the part of the government is a key cause of the cancellation." What started out as a $6.8B program grew to a $13B program. The president was quoted as saying "The helicopter I have now seems perfectly adequate."

[Read the rest of this article...]

Page 1 of 2First   Previous   [1]  2  Next   Last   
Copyright 2009-2014 by Modern Analyst Media LLC