- BETA

Saturday, July 31, 2010

Analysis Resources: Premier Business/Systems Analysis Articles, Templates, Blogs - Access Today, It's free!


18

There are a lot of problems associated with IT, such as computer performance, capacity planning, security, networking, disaster recovery, but probably the biggest problem is requirements definition. In other words, accurately defining the information needs of the end-user.

[Read the rest of this article...]

17

Topics of interest include experience papers, formal methods, emerging technologies, best practices, research proposals, evaluations and comparisons that focus on visualization techniques for requirements engineering activities.

[Read the rest of this article...]

17
12th Australian Workshop on Requirements Engineering Requirements Analysis for People, Businesses and Communities http://australia.theiiba.org/index...

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

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

Modeling an enterprise is not a simple task, you have to consider different stakeholders with different requirements, but also with different preferences on how they would like to access the enterprise knowledge. This presentation outlines different solutions all based on a central repository, where your enterprise can get the most benefit out of the enterprise model.

[Read the rest of this article...]

14

The 4th International Workshop on Requirements Engineering Education and Training (REET09)

Held in conjunction with the 17th International Requirements Engineering Conference (RE09). The workshop will be held in Atlanta, Georgia, USA on
August 31, 2009.
 

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

Page 4 of 5First   Previous   1  2  3  [4]  5  Next   Last   
Copyright 2009-2010 by Modern Analyst Media LLC