General discussion

Locked

System Analysis And Design

By sdghazi ·
How it is difficult to evaluate the user requirements?

This conversation is currently closed to new comments.

11 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

System Analysis And Design

by darryl_leong In reply to System Analysis And Desig ...

Firstly, you must understand the contraints that are on your client side and also on the developing guide. Contraints such as budget and time frame of development of the system. Issues like space, allocation of training time (resources). ALso what kind of implementation scheme you will be using. Is your team able to come up with such a product in the required time? What if the client wants changes halfway into your developement? All these have to be determined and confirmed before your team canget down to developing the product.

Collapse -

System Analysis And Design

by sdghazi In reply to System Analysis And Desig ...

The question was auto-closed by TechRepublic

Collapse -

System Analysis And Design

by Wayne M. In reply to System Analysis And Desig ...

The difficulty in analyzing user requirements is that the analyst is usually an expert in technology and not in the problem domain of the user. This is particularly true in a a consulting environment.

There are usually a lot of nuances, subtleties, and assumed information in written user requirements documents. Dr. Joseph Juran describes this process as translating from the language of the user into the language of the developer. The jump really is large enough to view it as a language translation. By the way, I would highly recommend Dr. Juran's books as a reference for user requirments analysis.

User requirements analysis is about understanding the world of the user. This is something that is very difficult to do in a short period of time.

Collapse -

System Analysis And Design

by sdghazi In reply to System Analysis And Desig ...

The question was auto-closed by TechRepublic

Collapse -

System Analysis And Design

The most succesfull and accurate URS documents in a business system, contain detailed descriptions and screen layouts of "input" and detailed descriptions and layouts of "output" (screens and reports).
The processes in between do become a lot more obvious.
This is not a 100% safe method as there is a lot more to it. However, a URS without those specifications is certainly incomplete.

Collapse -

System Analysis And Design

by sdghazi In reply to System Analysis And Desig ...

The question was auto-closed by TechRepublic

Collapse -

System Analysis And Design

by RealGem In reply to System Analysis And Desig ...

It is probably the most difficult part of system development. It is also the most critical, because a mistake in the requirements phase will only grow as that mistake is designed, programmed, and tested.

It is difficult because requirements gathering is an interactive process. Many technology people are more comfortable with the computer or feel that they are more productive when they are using the computer. Requirements workshops are seen as something that should be done as quickly as possible.

Also, requirements change. This is normal, but many people don't realize that. Requirements gathering does not stop after the requirements phase. You must keep testing and validating the requirements, and not just the code.

Collapse -

System Analysis And Design

by sdghazi In reply to System Analysis And Desig ...

The question was auto-closed by TechRepublic

Collapse -

System Analysis And Design

by MarcLipshitz In reply to System Analysis And Desig ...

As others ave stated this is a very difficult area. Having worked as both a consultant and in an internal IT area I will just post a couplke of observations:

When looking at user requirements it is important to not only look at the specific problem domain that is being addressed. There is a need to look at the overall environment as often factors outside of the specified problem domain influence the project and require action to be taken. An example of this is in a multi-project environment where you may be influenced by projects that are currently in development affecting the requirements on your project even though the specific requirements have not identified it.

Another area where problems arise is if the wrong person is doingthe specification. If only one business representative is avaialble then aeither too high or too low a view of the problem domain may result. Where possible the requirements should be specified by a combination of strategic, tactical and day to day business users to ensure requirements are met.

The issue of changing requirements is one of the most difficult to manage. The way I have generally done it is that an agreed scope and set of requirements is signed off at the end of the inception/scope phase. Any items that occur after this are introduced as change requests which result in replanning of resourcing, A methodology which supports this is the Rational Unified Process (RUP) which specifies an iterative development cycle with 6-8week iterations resulting in specific deliverables. After each iteration the project is reassessed and checked to ensure that everything is still on track. The strength behind this is that problems and delays are identified early on in the process.

Cheers
marc

Collapse -

System Analysis And Design

by sdghazi In reply to System Analysis And Desig ...

The question was auto-closed by TechRepublic

Back to IT Employment Forum
11 total posts (Page 1 of 2)   01 | 02   Next

Related Discussions

Related Forums