2.Consider the process models, which ones give you the most flexibility to chang
ID: 670026 • Letter: 2
Question
2.Consider the process models, which ones give you the most flexibility to change in reaction to changing requirements?
3. Sometimes part of a system may be built quickly to demonstrate feasibility or functionality to a customer. This prototype system is usually incomplete; the real system is constructed after the customer and developer evaluate the prototype. Should the system requirements document be written before or after a prototype is developed? Why?
4. Discuss some of the problems that occur when requirements must be elicited from three or four different customers.
5. Find two elicitation techniques you want to apply for your project’s requirements elicitation and explain why they would be a good choice for your project.
Explanation / Answer
1. A process model describes the sequence of phases for the entire lifetime of a product. This covers everything from the initial commercial idea until the final de-installation of the product after its use.
The are different types of process models. One of the biggest factor that dictate your choice of a life cycle method is tha clarity and stability of the project requirements. Frequent changes in requirements after the project has started can derail your progress against the plan. In such cases , choose iterative approach because each provides an opportunity for you top accomodate new requirements even after the project has started. In some cases , there is a stiff rule on ensuring complete set of requirements before going on to the next phases, in such cases waterfall model will be the best.
2. Software requirements development is the part of the project during which the needs of the customer are gathered and translated into a specifications of what the system must do.
The most difficult part of requirements gathering is not the act of recording what the users want, it is the development activity of helping users figure out what they want.
Firstly, the software team should gather preliminary requirements from the end users. then a simple , interactive user interface should be built.Then show the simple user interface prototype to the end user, continue revising it, keeping it simple , showing it to the end user, and revising it again until the end users are excited about software concept. The prototype must be extended until it demonstrates every functional area of the software. It should demonstrate the functional area, not the actual implementation. The the detailed end user documentation sghould be written based on the prototype.
The point of this activity is to present many different alternatives to the users before you commit much effort to any particular approach.
3. The problems that occur when requirements must be elicitated from three or four different customers are:
The problems can be grouped into three different categories:
To avoid the problems the software development team should gather the information from the different people and should make a complete list of all the requirements. If any changes occur in the requirements that person should inform about the changes to the rest of the software development team.
4. There are two best requirement elicitation techniques:
They are:
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.