Requirements determination

Like để cám ơn người Viết

The information systems development project starts by information system analysis, and the requirements determination is one core phase of its. The success or the failture of the project critically depends on the quality of this phase. This assignment provides background of the importance of requirements determination phase, why it is the difficulty for the developer and how can solve the problem.
Requirements determination – The dificulty of the information systems project developer.
Requirements determination will be developed by the analysts. It is the first phase of the information system analysis, in which a research of a collection of users’ needs and the customers’ problem to be fixed by the proposed information system project (Browne, G., & Rogich, M. 2001). It is the difficulty for the developer because of 2 main reasons:
First, it is the core phase which creates “make or break” of the project. Jennerich, B. (1990) researched that more than 60% originated errors appeared in the project come from this phase, and the cost for fixing them is very high and it takes more than 80% of working time to correct all (Goodrich,V. & Olfman, L. 1990). The bad requirements determination is the most expensive errors so that it puts a great pressure on the analyst.
Second, the hard thing is good requirements should be verifiably gotten, they are very hard to achive without users’s input because of getting information from various people involved (Hooks, I. F. 1993). There are 3 main reasons for the difficulty and the solutions for them:
1. The requirements come from many sources, many people in different departments in the organization and from different profesional levels. (Stedman, C.W. 1993)
2. It takes the developer much time and money for many users’ requirements.
3. The requirements collected from the users are not understood by the analyist or not completed. (Soltys, R., Crawford, A. 1993).
Solution: The developers must determine the major users for their project. It will help them to select and pick suitable ranges of requirements. Beside that, the developer should use the good questionaires for focusing users in major requirements which can guide the project to better development. The traditional techniques could lead to this problem. Using the better techniques such as JAD can save the time and money, make the collecting information easier, more effective because of gathering information from all affected parties and the requirements are approved by all parties, not only the developer.


The bad requirements determination is the the worst situation which the developers don’t want to get but it always appears in any projects. With the analysis above, you can see that the developers will have to take as many tools as possible to sovle this problem and get the perfect phase to guide the life cycle of the project.




Browne, G., & Rogich, M. (2001). An empirical investigation of user requirements elicitation: comparing the effectiveness of prompting techniques. Journal of Management Information Systems, 17 (4), 223–249.
Goodrich,V. & Olfman, L. (1990). An Experimental Evaluation Of Task And Methodology Variables For Requirements Definition Phase Success. Proceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences. IEEE Computer Society. Pp. 201-209.
Hooks, I. F. (1993) Writing Good Requirements. Proceeding of the Third International Symposium of the INCOSE, (2).
Jennerich, B. (1990). Joint Application Design: Business Requirements Analysis For Successful Re-Engineering. UNISPHERE Publisher. Retrieved from:
Stedman, C. (1997). Gathering Their Requirements Is Key. Computerworld, Retrieved from:,1199,NAV47_STO5418,00.html
Soltys, R. & Crawford, A. (1993). JAD for Business Plans and Designs. The Retrieved from:

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>