Friday, September 22, 2017

Entries for 'Modern Analyst'

20

Given the economic downturn, "cheaper, better, faster" seems to be a universal mantra in business. To stay competitive, organizations must continually strive to be more agile and develop higher-quality solutions more quickly-despite obstacles such as geographically distributed teams, limited budgets and resources, quick delivery times, language barriers and government regulations. These challenges require teams to consider new ways of doing business so they can be more responsive to frequent business changes.

One area that businesses can optimize is their software development processes. If they want to be competitive, companies don't have the luxury of long development lifecycles. To keep timeframes short, organizations must foster a collaborative environment by making tasks and responsibilities transparent and breaking down silos across the development lifecycle.

[Read the rest of this article...]

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

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

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

Copyright 2009-2014 by Modern Analyst Media LLC