This chapter discusses requirements engineering and discusses activities such as requirements gathering, requirements elicitation, requirements analysis, requirements management, and requirements verification and validation.
This is a preview of subscription content, log in via an institution to check access.
eBook EUR 42.79 Price includes VAT (France)
Softcover Book EUR 52.74 Price includes VAT (France)
Tax calculation will be finalised at checkout
Purchases are for personal use only
It is desirable that the user or system requirements describe what is to be provided rather than how it is to be provided. That is, in theory, design or implementation information should be excluded in the specification. However, in practice it is sometimes difficult to exclude all design information (e.g., consider the case where a system needs to work with an existing system).
It may involve getting end users to talk about how they currently do a certain task and brainstorming on better ways in which the proposed system can do the same task.
Conflicts are inevitable as stakeholders will have different needs, and so discussion and negotiation are required to resolve these conflicts and achieve consensus.
Essentially, the mathematical language provides the facility to prove that certain properties are true of the specification, and that certain undesirable properties are false in the specification.
This principle is named after the medieval philosopher, William of Ockham.
