The requirements for large software systems are always changing. One reason for
this is that these systems are usually developed to address 'wicked' problems (as
discussed in Chapter 2). Because the problem cannot be fully defined, the software
requirements are bound to be incomplete.. During the software process, the stakeholders'
understanding of the problem is constantly changing. These requirements
must then evolve to reflect this changed problem view.
Furthermore, once a system has been installed, new requirements inevitably emerge.
It is hard for users and system customers to anticipate what effects the new system
will have on the organisation. Once end-users have experience of a system, they
discove:r new needs and priorities:
1. Large systems usually have a diverse user community where users have diffen:
nt requirements and priorities. These may be conflicting or contradictory.
The final system requirements are inevitably a compromise between them and,
with experience, it is often discovered. that the balance of support given to diffen:
nt users has to be changed.
2. The people who pay for a system and the users of a system are rarely the same pe0ple.
System customers impose requirements because of organisational and budgetary
constraints. These may conflict with end-user requirements and, after delivery, new
features may have to be added for user support if the system is to meet its goals.
3. The business and technical envimnment of the system changes after installation, and
these changes must be reflected in the system. New hardware may be introduced,
it may be necessary to interface the system with other systems, business priorities
may change with consequent changes in the system support, and new legislation
and regulations may be introducl~ which must be implemented by the system.
Requirements management is the process of understanding and controlling
changes to system requirements. You need to keep track of individual requirements
and maintain links between dependent requirements so that you can assess the impact
of requirements changes. You need to establish a formal process for making change
proposals and linking these to system requirements. The process of requirements
management should start as soon as a draft version of the requirements document
is available, but you should start planning how to manage changing requirements
during the requirements elicitation process.
No comments:
Post a Comment
Your comments are welcome!