Tuesday, September 25, 2018

Entries for the 'Requirements Elicitation' Category

21

There are various ways and means by which requirements for software development projects can be gathered and documented.  Before you start documenting the requirements you might want to be sure if you have captured all the required information.
 

[Read the rest of this article...]

14

The requirements you capture must be stated in business terms, must be clearly stated, must be concise, and must be feasible. To ensure that requirements are clearly stated, you should have them proof read by someone external to the project (or at least someone not familiar with the requirements you've captured).

[Read the rest of this article...]

17

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

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

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

22

The path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.

[Read the rest of this article...]

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