Requirements

Chapter 6

Requirements for the system are the descriptions of the services provided by the system and its operational constraints. The process of analyzing, documenting and checking services needed is called Requirements Engineering.

Requirement is quite important and widely used word in software engineering, but still it not used in industry in consistent way. In some cases requirement is some high-level, abstract statement of a service that system must provide. In some other cases – it is detailed definition of a system function. There exist two general types of requirements while developing a system:

1. User requirements are statements in natural language, of what services the system is expected to provide and the constraints under which it must operate. They should be concerned on functional and non-functional requirements from user’s point of view, describing in detail aspect of a system that are important for customer. While working on user requirements, it’s important to avoid everything related to system design.
2. System requirements is a set of system functions descriptions in detail. Also, requirement document should be precise and define exactly what it is to be implemented. System requirements for software engineers are starting point for developing system, because they describe the way system should be designed and implemented. How user requirements should be provided.

Software system requirements are often classified as functional, non-functional or domain requirements.

Functional requirements describe what system should do, how it should react to different inputs and systems behavior at different situations. Statements of functional requirement should tell exactly what should happen in which cases, still, these requirements keep pretty abstract.

Non-functional requirements are constraints on the services of functions offered by the system. They include such aspects of development as timing, development process and standards. Non-functional requirements can be related to emergent properties such as reliability, response time etc. They are rarely associated with particular system features and more often used to describe more general aspects of a system, for example “user friendly graphical user interface”.

Domain requirements come from the application domain of the system and that reflect characteristics of that domain. They come more from the system itself rather than from specific need of system users. Domain requirements are important because they often reflect fundamentals of the application domain.