In order to successfully evaluate and select a packaged software application you must first clearly identify the functionality that you are looking for in the product. A Software Requirements Document specifically identifies and documents the overall business purpose for the software and includes a more detailed listing of the functional modules, and the general and technology requirements for the software.

[Read the rest of this article...]

A User Requirements Capture is a research exercise that is undertaken early in a project lifecycle to establish and qualify the scope of the project. The aim of the research is to understand the product from a user’s perspective, and to establish users’ common needs and expectations. The user requirements capture is useful for projects that have a lack of focus or to validate the existing project scope. The research provides an independent user perspective when a project has been created purely to fulfil a business need. The requirements capture findings are then used to balance the business goals with the user needs to ensure the project is a success.

[Read the rest of this article...]

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

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

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

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

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

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

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

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

[Read the rest of this article...]