Tuesday, September 25, 2018

Entries for the 'Requirements Gathering' Category

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

14

Requirements gathering techniques include the easy to send, but sometimes hard to develop, survey method to obtain data from a wide variety of people located anywhere. Surveys, however, are notorious for many faults such as ambiguity and a lack of response.

But surveys can produce a large volume of information for the gathering parties to peruse and collate, so developing good surveys is important for both the respondents who have to understand the questions and for the collators to get useful data.

[Read the rest of this article...]

14

Your first step in the requirements gathering process should be to solicit requirements for your software development project from the stakeholders. The method and techniques you choose to employ for the purpose of requirements solicitation will require you to contact these stakeholders for the purpose of either gathering them together, meeting with them one on one, or communicating with them long distance. That first contact will require a contact list of key stakeholders.

[Read the rest of this article...]

14

The intent of this section is to offer you some insight into the various requirements gathering tools available and the factors you need to consider when choosing which to use for your project. You'll need to take training in the use of these tools before becoming proficient in their use.

The nature of the software application or web site your project will deliver will influence your decision on which requirements gathering tools to use. Other factors that will influence your decision are the number and type of business users, customer service reps, and maintenance people and their locations. We'll attempt to describe some of the tools available to you in this section and describe situations where they would be appropriate to use.

[Read the rest of this article...]

13

We mentioned previously in this section that a Statement of Work (SOW) embedded in the contract for a project will serve as the master blueprint for your requirements. Although we haven't consistently stated this disclaimer everywhere in this section it should be understood that no requirement, no matter how you gathered it, no matter who contributed it, no matter who approves it, can be a part of the required product unless it's stated or implied in the SOW! Keep this fact in mind when you identify the approvers of your requirements.

[Read the rest of this article...]

13

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). Any questions raised by your proof reader should trigger a re-write of that requirement. Clean the language up until your proof reader understands the requirement.

[Read the rest of this article...]

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