Главная Обратная связь

Дисциплины:






Problems with requirements engineering



Requirements, seen by users as the uncomplicated bit of a new service development, are actually the most problematic aspect, and yet the time allocated is far less than for the other phases.

Tight timescales and tight budgets – both the result of constraints on the business – place pressures on the development team to deliver a service. The trouble is that without the due time to understand and define the requirements properly, the service that is delivered on time may not be the service that the business thought it was asking for.

Studies carried out into IT project failures tell a common story. Many of the projects and unsatisfactory IT services suggest the following conclusions:

  • A large proportion of errors (over 80%) are introduced at the requirements phase
  • Very few faults (fewer than 10%) are introduced at design and development – developers are developing things right, but frequently not developing the right things
  • Most of the project time is allocated to the development and testing phases of the project
  • Less than 12% of the project time is allocated to requirements.

These findings are particularly significant because the cost of correcting errors in requirements increases dramatically the later into the development lifecycle they are found.

One of the main problems with requirements engineering is the lack of detailed skill and overall understanding of the area when people use it. If accurately performed, the work can integrate requirements from numerous areas in a few questions.

Other typical problems with requirements have been identified as:

  • Lack of relevance to the objectives of the service
  • Lack of clarity in the wording
  • Ambiguity
  • Duplication between requirements
  • Conflicts between requirements
  • Requirements expressed in such a way that it is difficult to assess whether or not they have been achieved
  • Requirements that assume a solution rather than stating what is to be delivered by the service
  • Uncertainty amongst users about what they need from the new service
  • Users omitting to identify requirements
  • Inconsistent levels of detail
  • An assumption that user and IT staff have knowledge that they do not possess and therefore failing to ensure that there is a common understanding
  • Requirements creep – the gradual addition of seemingly small requirements without taking the extra effort into account in the project plan.

Another problem is an apparent inability on the part of the users to articulate clearly what it is they wish the service to do for them. Very often they are deterred from doing so because the nature of the requirement is explained in a straightforward statement.

5.1.4.1 Resolving requirements engineering problems

Defining actors

There are some participants that must take part in the requirements process. They represent three broad stakeholder groups:

  • The business
  • The user community
  • The service development team.

The user community should be represented by the domain expert (or subject-matter expert) and end-users.





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...